Description of problem: Since the resolution of bug 731672 https://bugzilla.redhat.com/show_bug.cgi?id=731672 (causing a kernel panic when power saving was enabled for this wireless controller) I've found that with power saving enabled wireless connections often drop and cannot be restarted without stopping NM, removing the module (modprobe -r rt2500pci), then reloading the module and NM. When NM is unable to establish a connection it attempts to connect before coming back to query the wireless password. Disabling power saving mode via adding this line in somewhere in /etc/udev/rules.d as in bug 731672 appears to prevent this happening: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="rt2500pci", KERNEL=="wlan*", RUN="/sbin/iw $name set power_save off" Version-Release number of selected component (if applicable): 2.6.40.8-3.bz731672.fc15.x86_64 (test fix for bz731672) How reproducible: Seems to happen inevitably. Steps to Reproduce: 1. Connect to wireless 2. Wait 3. Actual results: 1. Connection drops eventually. 2. Cannot reconnect without reloading module. Expected results: 1. Connection doesn't drop. 2. If connection drops NM can reconnect without touching module. Additional info: Might just be noise or unrelated NM bugs, but: 1. It's maybe my imagination, but the connection seems slower (e.g. more pauses during loading pages, internet radio has dropouts) even before complete disconnection with PM on. 2. NM queries for a password for my AP SSID, but entries are getting created in /etc/sysconfig/network-scripts/ for ifcfg-Auto_XXX with XXX SSIDS other than my SSID, however their ESSID= line is still mine. Could be an unrelated NM problem.
Created attachment 533413 [details] wpa_supplicant.log Attaching wpa_supplicant.log from an affected session. Dmesg reported lots of these: [ 339.466106] phy0 -> rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 0. [ 340.306115] phy0 -> rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 0. [ 340.714119] phy0 -> rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 0. [ 345.748104] phy0 -> rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 0. 00:1D:68:E7:7A:05 O2wirelessD9C5A1 is the correct AP.
Just to confirm, I'm also seeing this behaviour since re-enabling power-saving, including (I think) the slowness. Gareth
Is this still an issue with 2.6.43/3.3?
It's still an issue for me with Fedora 17 (Linux 3.3.4-5 at least). I haven't tested 3.3.7-1 without the work-around though.
Just to confirm, though it seems to take longer to show itself, this bug is still present in 3.4.3-1.fc17.x86_64 too.
I'm seeing the same issue on mine. 3.4.3-1 (although I might need to verify the kernel since I'm at work now.)
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This issue happen on very old hardware, we will not fix it , sorry.