finally fixed this issue last night. the windows host was turning on
powersaving. i had slid the "powersaving" slider over to "lowest" which i
assumed turned it off, while "highest" actually means "highest performance
/ disabled powersaving", so i had powersaving cranked to the max the
enti
On Wed, 29 Nov 2006, Sam Leffler wrote:
Is there some reason you are not just sniffing the air? Assuming
packets are being deferred because the medium is busy you might see a
reason. Otherwise it appears (though it's impossible to tell from what
you've shown so far) that the packets are hande
Lamont Granquist wrote:
>
> and ath_intr() is getting called all the time but status & HAL_INT_TX
> isn't true so the task isn't getting enqueued. this is a 5 second stutter:
>
> Nov 28 21:39:48 warez kernel: ath_tx_proc_q0123: 1
> Nov 28 21:39:48 warez kernel: ath_intr: status 0x101
> Nov 2
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
>> tr
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 pr
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.
also, "athtest 1"
and ath_intr() is getting called all the time but status & HAL_INT_TX
isn't true so the task isn't getting enqueued. this is a 5 second
stutter:
Nov 28 21:39:48 warez kernel: ath_tx_proc_q0123: 1
Nov 28 21:39:48 warez kernel: ath_intr: status 0x101
Nov 28 21:39:48 warez kernel: ath_intr:
Lamont Granquist wrote:
>
>
> On Sun, 12 Nov 2006, Sam Leffler wrote:
>> If tx stops in ap mode you need to figure out whether the h/w tx q is
>> stalled or something else "above" is blocking outbound traffic. The
>> usual things to check are:
>>
>> 1. are there resources in the driver to send a
On Sun, 12 Nov 2006, Sam Leffler wrote:
If tx stops in ap mode you need to figure out whether the h/w tx q is
stalled or something else "above" is blocking outbound traffic. The
usual things to check are:
1. are there resources in the driver to send a packet (e.g. buffers on
the queue); if th
Lamont Granquist wrote:
>
> i did the same thing with running:
>
> while(1)
> echo foo
> sleep 1
> end
>
> in a window ssh'd into the machine with the ath0 driver, but with the
> kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0x
> -- there should be packets sent every seco
On Sunday 12 November 2006 17:32, Lamont Granquist wrote:
> i saw the same behavior where tx packets would tend to
> spool up and buffer. here's the output of one second
> where a bunch of spooled up packets were sent alont with
> the previous second and following second and with a note
> on how l
i did the same thing with running:
while(1)
echo foo
sleep 1
end
in a window ssh'd into the machine with the ath0 driver, but with the
kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0x --
there should be packets sent every second while doing this.
i saw the same behav
12 matches
Mail list logo
