Date: Sun, 15 Jan 2012 20:10:12 GMT From: Adrian Chadd <adrian.chadd@gmail.com> To: freebsd-wireless@FreeBSD.org Subject: Re: kern/163318: [ath] ath(4) stops working Message-ID: <201201152010.q0FKACbH090444@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/163318; it has been noted by GNATS. From: Adrian Chadd <adrian.chadd@gmail.com> To: Joel Dahl <joel@freebsd.org> Cc: bug-followup@freebsd.org Subject: Re: kern/163318: [ath] ath(4) stops working Date: Sun, 15 Jan 2012 12:10:02 -0800 Hi, So I want to establish whether the scan logic has hung, or whether the scan logic has completed but left the interface hung. How's your C? Would you mind doing some quick hacking: * add a new variable in struct ath_softc, call it "sc_in_scan"; * set it to 1 in ath_scan_start (don't add any locks) * set it to 0 in ath_scan_end (don't add any locks) * edit the 'txagg' sysctl code in if_ath_sysctl.c to print out the value of sc_in_scan; Then verify that it's working as advertised: * sysctl dev.ath.0.txagg=1 and check dmesg - sc_in_scan should be 0; * do a manual scan (ifconfig wlan0 scan) and then redo the above sysctl - it should be 1. The "normal" scan will keep the interface in "scan" mode for the duration of all channel checks. But for bgscan, it quickly brings the interface in and out of scan mode, for each channel that's being scanned. What i hope to see is: * sc_in_scan stays 0 during normal operation; * when your interface is hung, sc_in_scan is 1. Once we've established that, we can continue to go digging into the scan code. Thanks! Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201152010.q0FKACbH090444>