kern/163318: [ath] ath(4) stops working

Adrian Chadd adrian.chadd at
Sun Jan 15 20:10:12 UTC 2012

The following reply was made to PR kern/163318; it has been noted by GNATS.

From: Adrian Chadd <adrian.chadd at>
To: Joel Dahl <joel at>
Cc: bug-followup at
Subject: Re: kern/163318: [ath] ath(4) stops working
Date: Sun, 15 Jan 2012 12:10:02 -0800

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

More information about the freebsd-wireless mailing list