Bug 753648

Summary: rt2500 power save causes disconnection
Product: [Fedora] Fedora Reporter: Ian Malone <ibmalone>
Component: kernelAssignee: Stanislaw Gruszka <sgruszka>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: gansalmon, gareth.k.jones, itamar, jonathan, kernel-maint, madhu.chinakonda, mark.haney, sgruszka, urilabob
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: first=2.6.40.8 tested=3.3.4 wireless rt2500pci power
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-20 10:20:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
wpa_supplicant.log none

Description Ian Malone 2011-11-13 23:36:41 UTC 
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.
Comment 1 Ian Malone 2011-11-13 23:43:08 UTC 
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.
Comment 2 Gareth Jones 2011-12-15 17:55:01 UTC 
Just to confirm, I'm also seeing this behaviour since re-enabling power-saving, including (I think) the slowness.

Gareth
Comment 3 Josh Boyer 2012-06-07 15:11:43 UTC 
Is this still an issue with 2.6.43/3.3?
Comment 4 Gareth Jones 2012-06-07 19:23:38 UTC 
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 16:53:04 UTC 
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 12:36:44 UTC 
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-04 03:22:36 UTC 
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 10:20:15 UTC 
This issue happen on very old hardware, we will not fix it , sorry.