Latest working kernel version: Madwifi was unaffected, but ath5k was from the very beginning
Earliest failing kernel version:
Hardware Environment: Thinkpad T42
Software Environment: linux 2.6.28
Problem Description: When havin wpa_supplicant running, it continously (about every minute maybe? I'm not sure) emits a
As soon this happens, the computer becomes very choppy. Meaning Sound may skip, flash games come to a crawl etc. After the scan is done, resposivity is back to normal. When the scan is in progress (takes about 5 seconds here), the ath5k process takes ~30% cpu time which I find to be very high just for a scan
Steps to reproduce: Play some flash game (www.bumperball.com is an option :) ), start a scan and watch the speed of flash. Music may skip too, but that doesn't occur all the time
If you need more info or If I can assist in debugging - just let me know
The problem is that scanning changes channels, which in turn calls ath5k_hw_reset, thus reloading all the registers for the card. This is how it has pretty much always worked. This is also, I suspect, a cause for a number of bad behaviors of the card, such as noise floor timeouts and perhaps some lockups. We need to make channel changes a much simpler affair.
I just spotted that part in the code (base.c, ath5k_chan_set)
Is there any way I can help on this?
This patch *may* help, by reducing the total number of channels:
Otherwise Nick is working on "reset-light" I believe.
Well, if somebody is already working on reset-light, then I'd rather wait for that. If there are patches for that which need testing, I'd surely give them a go
Fair enough. One thing you can try in the interim is to add to your wpa_supplicant.conf "scan_freq=2412 2437 2462" -- that will limit the channels that are scanned to 1,6, and 11, which should reduce the problems by a lot.
I believe this could be the root problem for this distro bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291760 (basically, every 2min when NetworkManager does a network scan, all wireless traffic stops for ~5sec until it's done). I see channel hopping happening during the (background!) scan, to echo the comments above.
Yes, all hardware does this, ath5k just takes longer to scan since there are two bands and tons of channels (and it doesn't help that reset is pretty heavy-weight). Patches for spreading out background scans have been posted recently. There are many fewer channels in 2.6.31.
Are you still experiencing this problem with kernels versions >=2.6.31?
I still see this on Debian with their 2.6.31 and 2.6.32 kernels (most recently 2.6.32-3 on amd64). It makes interactive use very bad with NetworkManager.
I've reported it there as Bug#575229: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575229
I think this situation has been vastly improved between the original report and 2.6.35. I'm going to close this now -- please reopen if you truly believe a serious issue remains.
It doesn't! I still see some minor glyphs corruption, but that's another story.
So it took approximately 10 cycles to get this fixed... ;-)