Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 753648 - rt2500 power save causes disconnection
rt2500 power save causes disconnection
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Stanislaw Gruszka
Fedora Extras Quality Assurance
first= tested=3.3.4 wireless ...
Depends On:
  Show dependency treegraph
Reported: 2011-11-13 18:36 EST by Ian Malone
Modified: 2013-11-20 05:20 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-20 05:20:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
wpa_supplicant.log (8.46 KB, application/octet-stream)
2011-11-13 18:43 EST, Ian Malone
no flags Details

  None (edit)
Description Ian Malone 2011-11-13 18:36:41 EST
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):
(test fix for bz731672)

How reproducible:
Seems to happen inevitably.

Steps to Reproduce:
1. Connect to wireless
2. Wait
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.
Comment 1 Ian Malone 2011-11-13 18:43:08 EST
Created attachment 533413 [details]

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.
Comment 2 Gareth Jones 2011-12-15 12:55:01 EST
Just to confirm, I'm also seeing this behaviour since re-enabling power-saving, including (I think) the slowness.

Comment 3 Josh Boyer 2012-06-07 11:11:43 EDT
Is this still an issue with 2.6.43/3.3?
Comment 4 Gareth Jones 2012-06-07 15:23:38 EDT
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.
Comment 5 Gareth Jones 2012-06-28 12:53:04 EDT
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.
Comment 6 Mark Haney 2012-07-17 08:36:44 EDT
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.)
Comment 7 Fedora End Of Life 2013-07-03 23:22:36 EDT
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.
Comment 8 Stanislaw Gruszka 2013-11-20 05:20:15 EST
This issue happen on very old hardware, we will not fix it , sorry.

Note You need to log in before you can comment on or make changes to this bug.