Hi,
I have a Samsung N130 netbook which has
phy0: Atheros AR9285 MAC/BB Rev:2 AR5133 RF Rev:e0: mem=0xf80e0000, irq=16
and I run Debain unstable with a linux-2.6.32-rc6-166-g799dd75 kernel.
When running kismet I get a lot of
[ 2030.531809] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2030.731944] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2030.968118] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2031.169580] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2031.397604] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2031.653803] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2031.883503] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2032.092719] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2032.332719] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
[ 2032.539756] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
This is 100% reproducable. However it seems kismet is still working
(but probably missing some frames due to the issue).
Connecting to and AP via WPA2 works (but I didn't test much yet), but
when I terminate wpa_supplicant I also get one of the "DMA failed to stop"
messages (same AR_CR and AR_DIAG_SW).
Is it safe to assume that the message is caused by an invalid
RX DMA descriptor? Or hat else could cause DMA to fail to complete?
Thanks
Johannes
On Thu, Nov 12, 2009 at 04:26:00PM +0100, Johannes Stezenbach wrote:
>
> When running kismet I get a lot of
>
> [ 2030.531809] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
Update: It seems that this is only happening when kismet is hopping
channels. So it looks like an unclean shutdown of the receive
process and not a real problem -- except that the log flooding is
pretty annoying.
Johannes
On Thu, Nov 12, 2009 at 10:13 AM, Luis R. Rodriguez <[email protected]> wrote:
> On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <[email protected]> wrote:
>> On Thu, Nov 12, 2009 at 04:26:00PM +0100, Johannes Stezenbach wrote:
>>>
>>> When running kismet I get a lot of
>>>
>>> [ 2030.531809] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
>>
>> Update: It seems that this is only happening when kismet is hopping
>> channels. So it looks like an unclean shutdown of the receive
>> process and not a real problem -- except that the log flooding is
>> pretty annoying.
>
> Can you try disabling powersave before using monitor mode?
>
> sudo iwconfig wlan0 power off
That is, we shoudn't be sleeping during monitor mode. Curious if
somehow we are getting to that state.
Luis
On Thu, Nov 12, 2009 at 10:14:06AM -0800, Luis R. Rodriguez wrote:
> On Thu, Nov 12, 2009 at 10:13 AM, Luis R. Rodriguez <[email protected]> wrote:
> > On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <[email protected]> wrote:
> >> On Thu, Nov 12, 2009 at 04:26:00PM +0100, Johannes Stezenbach wrote:
> >>>
> >>> When running kismet I get a lot of
> >>>
> >>> [ 2030.531809] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
> >>
> >> Update: It seems that this is only happening when kismet is hopping
> >> channels. ?So it looks like an unclean shutdown of the receive
> >> process and not a real problem -- except that the log flooding is
> >> pretty annoying.
> >
> > Can you try disabling powersave before using monitor mode?
> >
> > sudo iwconfig wlan0 power off
>
> That is, we shoudn't be sleeping during monitor mode. Curious if
> somehow we are getting to that state.
"iwconfig wlan0 power off" doesn't make a difference.
Johannes
On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <[email protected]> wrote:
> On Thu, Nov 12, 2009 at 04:26:00PM +0100, Johannes Stezenbach wrote:
>>
>> When running kismet I get a lot of
>>
>> [ 2030.531809] ath9k: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
>
> Update: It seems that this is only happening when kismet is hopping
> channels. So it looks like an unclean shutdown of the receive
> process and not a real problem -- except that the log flooding is
> pretty annoying.
Can you try disabling powersave before using monitor mode?
sudo iwconfig wlan0 power off
Luis