Date: Mon, 2 Jan 2012 06:20:12 GMT From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@FreeBSD.org Subject: Re: kern/163759: [at] ath(4) "stops working" in hostap mode Message-ID: <201201020620.q026KCxU005014@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/163759; it has been noted by GNATS. From: Adrian Chadd <adrian@freebsd.org> To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/163759: [at] ath(4) "stops working" in hostap mode Date: Sun, 1 Jan 2012 22:16:21 -0800 A little more digging has shown at least one source of these: software retries are sneaking onto the list. Ie: * force 11n aggregation up - do a whole bunch of traffic; * enabled debugging - sysctl dev.ath.1.debug=0x7c002000 - that's the SW TX handling bits and the TX_PROC debugging; * ping -i 0.3 <ip> in one screen * scan in the other (ifconfig wlan1 scan) * notice the tid_drain things being logged. What I've seen: * frame is queued via ath_start() or ath_raw_xmit() * .. it makes it out to the hardware * ath_tx_processq() is called in the flush routine, with dosched=0 * .. and it requires a retry, for reasons I haven't yet figured out. Since aggregation is up, the frame is retried in software. * .. so the frame is replaced on the software queue, but sched isn't called for it, so it sits on the software queue. * .. then drain is called, with a software-queued frame in the queue. So now, what should I do here? Hum. adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201020620.q026KCxU005014>