ath0 issue

Sam Leffler sam at errno.com
Wed Nov 29 09:01:09 PST 2006


Lamont Granquist wrote:
> 
> 
> On Wed, 15 Nov 2006, Sam Leffler wrote:
>> Snapshots are rarely useful; try running athstats 1 and correlate what
>> you see with pauses.  Another possible reason for deferred operation is
>> something else in the system blocking the taskq threads; that's a bit
>> trickier to diagnose.
> 
> I threw in some printf()'s in the beginning of ath_start() and
> ath_tx_proc_q0123() and see this:
> 
> Nov 28 20:27:41 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 20:27:41 warez kernel: ath_start
> Nov 28 20:27:41 warez kernel: ath_start
> Nov 28 20:27:41 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 20:27:41 warez kernel: ath_start
> Nov 28 20:27:45 warez last message repeated 13 times
> Nov 28 20:27:45 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 20:27:45 warez kernel: ath_start
> Nov 28 20:27:45 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 20:27:45 warez kernel: ath_start
> Nov 28 20:27:45 warez kernel: ath_start
> 
> this was during a time where i was pinging across this interface so that
> every second it should have been transmitting at least one packet.  the
> 4 second stutter there where ath_tx_proc_q0123 wasn't being called
> correllates with actual stutters in packet transmission.
> 
> if i understand this, that's the taskq associated with transmission?
> 
> TASK_INIT(&sc->sc_txtask, 0, ath_tx_proc_q0123, sc);
> 
> 
No, that's the task q that reaps completed tx descriptors.  You can't
infer anything about when packets were transmitted from this.

	Sam



More information about the freebsd-stable mailing list