Bug 12635

Summary:	ath5k scanning makes system choppy
Product:	Networking	Reporter:	Benjamin Schindler (bschindler)
Component:	Wireless	Assignee:	networking_wireless (networking_wireless)
Status:	CLOSED PATCH_ALREADY_AVAILABLE
Severity:	normal	CC:	kernel-bugzilla, linville, mcgrof, me, nick, vickieharmstrong
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.28 (and earlier - have not tried 2.6.29-rcX)	Subsystem:
Regression:	No	Bisected commit-id:

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.

Comment 11 Helen Allred 2017-06-29 02:53:49 UTC

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... ;-)

http://www.kizifan.com/action/friv-monster-hordes