Bug 33882 - rt2800pci bad performance in 2.6.38
rt2800pci bad performance in 2.6.38
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: network-wireless
All Linux
: P1 normal
Assigned To: drivers_network-wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks: 27352
  Show dependency treegraph
 
Reported: 2011-04-23 14:35 UTC by Ricardo Graça
Modified: 2012-08-20 15:53 UTC (History)
10 users (show)

See Also:
Kernel Version: 2.6.38.3
Tree: Mainline
Regression: Yes


Attachments

Description Ricardo Graça 2011-04-23 14:35:10 UTC
Since the update to kernel 2.6.38 my wifi connection looses huge amounts of packets, making it unusable. This seems to only happen when my laptop is on battery power. I'm using Arch Linux with all packages up to date. The system in question is an Asus Eee PC 1000h with a Ralink RT2860 adapter using the rt2800pci driver since at least kernel 2.6.35.
Comment 1 Ricardo Graça 2011-04-25 11:31:58 UTC
It seems to affect RT3090 as well, according to this ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/769504
Comment 2 Ricardo Salveti de Araujo 2011-04-25 22:40:17 UTC
Can you check if it gets better if you disable power management?

Run as root:
$ iwconfig wlan0 power off

At least for me it improves quite a lot.
Comment 3 Ricardo Graça 2011-04-25 22:55:52 UTC
Yes, by disabling power management the connection is back to normal again. Still, this is a regression because it used to work fine with power management activated.
Comment 4 Timothy Mayoh 2011-05-01 21:01:41 UTC
I am the person who posted the bug report on Launchpad against Ubuntu, and I can confirm that "iwconfig wlan1 power off" fixes the problem temporarily.
Comment 5 Ricardo Graça 2011-05-06 13:08:31 UTC
The "iwconfig wlan0 power off" trick no longer works with version 2.6.38.4
Comment 6 Gertjan van Wingerde 2011-05-07 13:25:11 UTC
What do you mean with that the trick no longer works?

Does the command no longer work (i.e. it fails) or is executing the command no longer a fix for the performance issues?
Comment 7 Ricardo Graça 2011-05-07 13:50:46 UTC
Sorry, I should have been more specific. I mean it no longer fixes the performance issue.
Comment 8 Ricardo Graça 2011-05-15 18:39:19 UTC
I got an email asking if this is still a regression, and so I'm confirming it is still present.
Comment 9 Timothy Mayoh 2011-05-16 16:36:24 UTC
The issue still seems to be present in Ubuntu with the RT3090 chipset, and it has been confirmed as a bug on Launchpad.

It seems to affect some Realtek chipsets as well, and running "iwconfig wlan0 power off" on the Realtek chipset I tried (I can't remember the exact model number, but it's internal) only fixes the problem for a short amount of time (usually under 10 minutes) and then restarting is the only simple way of making the command work again as it has no effect on following attempts.
Comment 10 Ted Howard 2011-06-01 03:00:20 UTC
On Asus Eee PC 1000 running Kernel 2.6.38-8 which by default is using rt2800pci.
Have invariably had issues with the kernel driver for several kernel upgrades under Ubuntu and each time wound up compiling the driver from the source code at RaLink and using it instead and sometimes having to blacklist drivers like this:
blacklist rt2800pci
blacklist rt2800lib
blacklist rt2x00usb
blacklist rt2x00pci
blacklist rt2x00lib

Back around 9.04 Ubuntu I had to change a few variables dealing with WPA_SUPPLICANT in the driver via a fix I found online back then.  Ever since on kernel upgrades I have blacklisted the above and used the driver I compiled back then.

Each time it has been a slightly different problem. Early on with the constant disconnects which I think the supplicant change had helped, and later on with random disconnects where the validation box pops up asking for the Network Password. (Sometimes with other network interference and other times not)Please let me know if I can provide any more hardware, OS, or log data to help fix this.  I have been dealing with this for several years, Ubuntu versions, and kernel versions. Wish I had kept better track but I was too busy getting to work each time that I didn't record my steps every time.  There are at least 10 other network connected devices here and none seem to have trouble like this has.

I am trying the 'iwconfig wlan0 power off' suggestion above because lately it has been disconnecting and prompting for password only while on battery power and after several hours. So I was thinking it might be a power management issue as well. This is the stablest it has run with the kernel driver and not blacklisting.  Do I need to run the iwconfig statement at each boot or will one time suffice?
Comment 11 Ted Howard 2011-06-01 03:09:43 UTC
Also I meant to say the only way I have been able to renegotiate a connection with the AP after one of these disconnects was either a reboot, sometimes which didn't work and other times a shutdown and boot.  Disabling wireless in the Network Manager would usually not work.  Sometimes turning off the wireless via the hardware control hot key and/or EEEControl panel which I have been using to control the fan speed issue would cause a successful renegotiation.   I also forgot to say that in the past 2-3 kernel upgrades the kernel driver(rt2800pci) was working but the speeds were horrendous 1Mbps or less.  Either blacklisting the above drivers and or using the personally compiled driver or a combination(not sure at this point) would boost the speed back up to reasonable 10-30Mbps.
Comment 12 Ted Howard 2011-06-03 01:59:43 UTC
First disconnect happened in 24 hours or so where it prompted for network password instead of reconnecting on its own.  Had just switched to battery power and changed rooms and this appeared in the syslog: 
nm_setting_802_1x_get_pkcs11_engine_path: assertion `NM_IS_SETTING_802_1X (setting)' failed
Comment 13 Timothy Mayoh 2011-09-03 19:24:19 UTC
This problem no longer seems to exist in testing on Ubuntu 11.10 Beta 1 (Linux 3.0.0-9-generic):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/769504/comments/25
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/769504/comments/26

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