|Summary:||ath5k scanning makes system choppy|
|Product:||Networking||Reporter:||Benjamin Schindler (bschindler)|
|Severity:||normal||CC:||kernel-bugzilla, linville, mcgrof, me, nick, vickieharmstrong|
|Kernel Version:||2.6.28 (and earlier - have not tried 2.6.29-rcX)||Tree:||Mainline|
Description Benjamin Schindler 2009-02-05 04:07:34 UTC
Latest working kernel version: Madwifi was unaffected, but ath5k was from the very beginning Earliest failing kernel version: Distribution: gentoo 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 CTRL-EVENT-SCAN-RESULTS 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
Comment 1 Bob Copeland 2009-02-09 11:35:25 UTC
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.
Comment 2 Benjamin Schindler 2009-02-09 11:57:15 UTC
Hi I just spotted that part in the code (base.c, ath5k_chan_set) Is there any way I can help on this?
Comment 3 Bob Copeland 2009-04-02 11:29:01 UTC
This patch *may* help, by reducing the total number of channels: http://marc.info/?l=linux-wireless&m=123841474910111&w=2 Otherwise Nick is working on "reset-light" I believe.
Comment 4 Benjamin Schindler 2009-04-02 12:19:22 UTC
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
Comment 5 Bob Copeland 2009-04-02 18:49:08 UTC
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.
Comment 6 Nicholas J Kreucher 2009-08-27 09:24:37 UTC
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.
Comment 7 Bob Copeland 2009-08-27 09:51:24 UTC
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.
Comment 8 John W. Linville 2010-02-26 16:48:31 UTC
Are you still experiencing this problem with kernels versions >=2.6.31?
Comment 9 Chris Chiappa 2010-03-24 15:04:22 UTC
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
Comment 10 John W. Linville 2010-08-11 18:16:43 UTC
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.