Just as a check, I booted to the 12.3 backup I keep and wireless
communications are rock solid so the issue appears to be 13.1 and some
recent update but I’ve had some interesting problems with wireless ever
since I updated to 13.1; this appears to be a solid problem. Dmesg reports
CODE:
1909.582560] SFW2-INext-ACC IN=eth0 OUT= MAC= SRC=192.168.100.9
DST=224.0.0.251 LEN=134 TOS=0x00 PREC=0x00 TTL=255 ID=28175 DF PROTO=UDP
SPT=5353 DPT=5353 LEN=114
1909.582654] SFW2-INext-ACC IN=eth0 OUT= MAC= SRC=192.168.100.9
DST=224.0.0.251 LEN=198 TOS=0x00 PREC=0x00 TTL=255 ID=28176 DF PROTO=UDP
SPT=5353 DPT=5353 LEN=178
1927.057380] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived
at non-free entry in the non-full queue 0
Please file bug report to http://rt2x00.serialmonkey.com
1928.048982] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived
at non-free entry in the non-full queue 0
Please file bug report to http://rt2x00.serialmonkey.com
1970.072807] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived
at non-free entry in the non-full queue 0
Please file bug report to http://rt2x00.serialmonkey.com
/CODE
Both 12.3 and 13.1 use rt2800pci as the driver for this device. The other
wierdness I see with 13.1 is that even when I get communications established
I frequently lose the connection and neither the NM scan nor iwlist scan
will see the ap. Kind of unlikely case as the router/ap sits within a foot
of the computer and the connection will usually come back after either a
reboot, especially if I boot to either Win8 or 12.3 then back to 13.1.
This is not a real show stopper as I also have a wired connection to work
from but it’s nice to be able to switch to the wireless for some testing.
The results are gennerally the same whether I use networkmanager or manual
ifup to manage the network.
On 12/14/2013 11:07 AM, Will Honea wrote:
> I just noticed a problem with the wireless adapter in my HP Envy desktop.
> Running 13.1, lspci tells me that I have:
>
> CODE:
> ----------
> 03:00.0 Network controller: Ralink corp. RT3290 Wireless 802.11n 1T/1R PCIe
> 03:00.1 Bluetooth: Ralink corp. RT3290 Bluetooth
> ----------
> /CODE
>
> Just as a check, I booted to the 12.3 backup I keep and wireless
> communications are rock solid so the issue appears to be 13.1 and some
> recent update but I’ve had some interesting problems with wireless ever
> since I updated to 13.1; this appears to be a solid problem. Dmesg reports
>
> CODE:
> ----------
> 1909.582560] SFW2-INext-ACC IN=eth0 OUT= MAC= SRC=192.168.100.9
> DST=224.0.0.251 LEN=134 TOS=0x00 PREC=0x00 TTL=255 ID=28175 DF PROTO=UDP
> SPT=5353 DPT=5353 LEN=114
> 1909.582654] SFW2-INext-ACC IN=eth0 OUT= MAC= SRC=192.168.100.9
> DST=224.0.0.251 LEN=198 TOS=0x00 PREC=0x00 TTL=255 ID=28176 DF PROTO=UDP
> SPT=5353 DPT=5353 LEN=178
> 1927.057380] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived
> at non-free entry in the non-full queue 0
> Please file bug report to http://rt2x00.serialmonkey.com
> 1928.048982] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived
> at non-free entry in the non-full queue 0
> Please file bug report to http://rt2x00.serialmonkey.com
> 1970.072807] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived
> at non-free entry in the non-full queue 0
> Please file bug report to http://rt2x00.serialmonkey.com
> ----------
> /CODE
>
> Both 12.3 and 13.1 use rt2800pci as the driver for this device. The other
> wierdness I see with 13.1 is that even when I get communications established
> I frequently lose the connection and neither the NM scan nor iwlist scan
> will see the ap. Kind of unlikely case as the router/ap sits within a foot
> of the computer and the connection will usually come back after either a
> reboot, especially if I boot to either Win8 or 12.3 then back to 13.1.
>
> This is not a real show stopper as I also have a wired connection to work
> from but it’s nice to be able to switch to the wireless for some testing.
> The results are gennerally the same whether I use networkmanager or manual
> ifup to manage the network.
>
> Any thoughts on what I may be seeing here?
As the message says, you are seeing a bug in the driver, which you should report
to the URL listed.
The difference between NM and ifup is only apparent when there is no connection.
Once a connection is made, that type of software is out of the loop. As a
result, it is not surprising that the choice makes no difference.
One possibility is that the bug might already be fixed. If so, it would be in
the backports code, which used to be called compat-wireless. If that package has
been built for 13.1, I was unable to find it. Perhaps someone else knows where
it is.
>
> As the message says, you are seeing a bug in the driver, which you should
> report to the URL listed.
>
> The difference between NM and ifup is only apparent when there is no
> connection. Once a connection is made, that type of software is out of the
> loop. As a result, it is not surprising that the choice makes no
> difference.
>
> One possibility is that the bug might already be fixed. If so, it would be
> in the backports code, which used to be called compat-wireless. If that
> package has been built for 13.1, I was unable to find it. Perhaps someone
> else knows where it is.
I’ll give it a go but that web page shows the last activity as sometime in
2010. I’ll have a look at the backport - this box came with Atheros AR8161
Gigabit ethernet so I got fairly proficient at building network drivers
prior to 13.1
On 12/14/2013 02:58 PM, Will Honea wrote:
> Larry Finger wrote:
>
>>
>> As the message says, you are seeing a bug in the driver, which you should
>> report to the URL listed.
>>
>> The difference between NM and ifup is only apparent when there is no
>> connection. Once a connection is made, that type of software is out of the
>> loop. As a result, it is not surprising that the choice makes no
>> difference.
>>
>> One possibility is that the bug might already be fixed. If so, it would be
>> in the backports code, which used to be called compat-wireless. If that
>> package has been built for 13.1, I was unable to find it. Perhaps someone
>> else knows where it is.
>
> I’ll give it a go but that web page shows the last activity as sometime in
> 2010. I’ll have a look at the backport - this box came with Atheros AR8161
> Gigabit ethernet so I got fairly proficient at building network drivers
> prior to 13.1
So I found. The url pointed to for bug reports was the one that looked
stale. So far, the latest backports code looks to be OK but this whole
problem is so flakey it will take a day or two to fully ring it out. At
present, the new driver hasn’t lost the local ap - yet… That’s progress!
