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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
