ath9k: DMA failed to stop in 10 ms

ath9k: DMA failed to stop in 10 ms

[Johannes Stezenbach]

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

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Johannes Stezenbach]

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

Re: ath9k: DMA failed to stop in 10 ms

[Johannes Stezenbach]

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

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Johannes Stezenbach]

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

Re: ath9k: DMA failed to stop in 10 ms

[Luis R. Rodriguez]

On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <js@sig21.net> 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

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Luis R. Rodriguez]

On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <js@sig21.net> 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

Re: ath9k: DMA failed to stop in 10 ms

[Luis R. Rodriguez]

On Thu, Nov 12, 2009 at 10:13 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <js@sig21.net> 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

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Luis R. Rodriguez]

On Thu, Nov 12, 2009 at 10:13 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <js@sig21.net> 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

Re: ath9k: DMA failed to stop in 10 ms

[Johannes Stezenbach]

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 <mcgrof@gmail.com> wrote:
> > On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <js@sig21.net> 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

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Johannes Stezenbach]

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 <mcgrof@gmail.com> wrote:
> > On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach <js@sig21.net> 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

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Neil Wilson]

2009/11/12 Johannes Stezenbach <js@sig21.net>:
> 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 <mcgrof@gmail.com> wrote:
>> > On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach
>> >>> 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
>> >>

I get this issue a lot in normal operation and it hangs the driver
completely. So much so that I can't reload the module after unloading
it.

For me its a real problem.


-- 
Neil Wilson

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Luis R. Rodriguez]

On Fri, Nov 13, 2009 at 08:22:57AM -0800, Neil Wilson wrote:
> 2009/11/12 Johannes Stezenbach <js@sig21.net>:
> > 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 <mcgrof@gmail.com> wrote:
> >> > On Thu, Nov 12, 2009 at 10:10 AM, Johannes Stezenbach
> >> >>> 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
> >> >>
> 
> I get this issue a lot in normal operation and it hangs the driver
> completely. So much so that I can't reload the module after unloading
> it.
> 
> For me its a real problem.

Can you compile wireless-testing and enable full debugging on ath9k?

modprobe ath9k debug=0xffffff

and see if you can capture a few lines around the "DMA failed to stop".

See:

http://wireless.kernel.org/en/users/Drivers/ath9k/debug

I'll see if I can get compat-wireless tested to enable debug if you
don't want to compile wireless-testing.

  Luis

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Neil Wilson]

2009/11/13 Luis R. Rodriguez <lrodriguez@atheros.com>:
> I'll see if I can get compat-wireless tested to enable debug if you
> don't want to compile wireless-testing.


I've brought up compat-wireless synced to today's wireless-testing to
try out the new drivers. I'm not getting the DMA failures with that
ath9k driver (srcversion:     A274B26D86317453E48E6A4), but then the
speeds the driver is syncing at are between 2.0 Mbit/sec and 11
Mbit/sec about six inches from a 40 Mhz 802.11n AP.

But hey, it's working!


 I am seeing a pause in throughput now rather than a failure when the
network is scanned.

64 bytes from 192.168.2.1: icmp_seq=762 ttl=64 time=1.95 ms
64 bytes from 192.168.2.1: icmp_seq=763 ttl=64 time=2.11 ms
64 bytes from 192.168.2.1: icmp_seq=764 ttl=64 time=4375 ms
64 bytes from 192.168.2.1: icmp_seq=765 ttl=64 time=3375 ms
64 bytes from 192.168.2.1: icmp_seq=766 ttl=64 time=2375 ms
64 bytes from 192.168.2.1: icmp_seq=767 ttl=64 time=1375 ms
64 bytes from 192.168.2.1: icmp_seq=768 ttl=64 time=357 ms
64 bytes from 192.168.2.1: icmp_seq=769 ttl=64 time=2.05 ms
64 bytes from 192.168.2.1: icmp_seq=770 ttl=64 time=2.24 ms

The pauses can be replicated by executing:

sudo iw dev wlan0 scan



-- 
Neil Wilson

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Luis R. Rodriguez]

On Sat, Nov 14, 2009 at 7:41 AM, Neil Wilson <neil@aldur.co.uk> wrote:
> 2009/11/13 Luis R. Rodriguez <lrodriguez@atheros.com>:
>> I'll see if I can get compat-wireless tested to enable debug if you
>> don't want to compile wireless-testing.
>
>
> I've brought up compat-wireless synced to today's wireless-testing to
> try out the new drivers. I'm not getting the DMA failures with that
> ath9k driver (srcversion: ? ? A274B26D86317453E48E6A4),

Great to hear.

>  but then the
> speeds the driver is syncing at are between 2.0 Mbit/sec and 11
> Mbit/sec about six inches from a 40 Mhz 802.11n AP.

Distance and room distortion actually helps with dual stream devices,
try at farther distances. If you want to try up close you can try
hacked up concoctions like my little copper-taped bag:

http://bombadil.infradead.org/~mcgrof/images/copper-tape-on-bag.jpg

> But hey, it's working!
>
>
> ?I am seeing a pause in throughput now rather than a failure when the
> network is scanned.
>
> 64 bytes from 192.168.2.1: icmp_seq=762 ttl=64 time=1.95 ms
> 64 bytes from 192.168.2.1: icmp_seq=763 ttl=64 time=2.11 ms
> 64 bytes from 192.168.2.1: icmp_seq=764 ttl=64 time=4375 ms
> 64 bytes from 192.168.2.1: icmp_seq=765 ttl=64 time=3375 ms
> 64 bytes from 192.168.2.1: icmp_seq=766 ttl=64 time=2375 ms
> 64 bytes from 192.168.2.1: icmp_seq=767 ttl=64 time=1375 ms
> 64 bytes from 192.168.2.1: icmp_seq=768 ttl=64 time=357 ms
> 64 bytes from 192.168.2.1: icmp_seq=769 ttl=64 time=2.05 ms
> 64 bytes from 192.168.2.1: icmp_seq=770 ttl=64 time=2.24 ms
>
> The pauses can be replicated by executing:
>
> sudo iw dev wlan0 scan

If you leave your home channel you cannot be present for data on it.
One way to address this is to scan on each target channel and come
back the home channel, and repeat this for every channel you have to
scan. This is only done with nl80211 though which you would have to
enable manually through a wpa_supplicant configuration file or by
editing your wpa_supplicant dbus service file and enabling new
git-version wpa_supplicant options which are documented on the
wireless wiki [1]. Let us know if that helps.

  Luis

[1] http://bombadil.infradead.org/~mcgrof/images/copper-tape-on-bag.jpg

  Luis

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Luis R. Rodriguez]

On Sat, Nov 14, 2009 at 9:42 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Sat, Nov 14, 2009 at 7:41 AM, Neil Wilson <neil@aldur.co.uk> wrote:

>> ?I am seeing a pause in throughput now rather than a failure when the
>> network is scanned.
>>
>> 64 bytes from 192.168.2.1: icmp_seq=762 ttl=64 time=1.95 ms
>> 64 bytes from 192.168.2.1: icmp_seq=763 ttl=64 time=2.11 ms
>> 64 bytes from 192.168.2.1: icmp_seq=764 ttl=64 time=4375 ms
>> 64 bytes from 192.168.2.1: icmp_seq=765 ttl=64 time=3375 ms
>> 64 bytes from 192.168.2.1: icmp_seq=766 ttl=64 time=2375 ms
>> 64 bytes from 192.168.2.1: icmp_seq=767 ttl=64 time=1375 ms
>> 64 bytes from 192.168.2.1: icmp_seq=768 ttl=64 time=357 ms
>> 64 bytes from 192.168.2.1: icmp_seq=769 ttl=64 time=2.05 ms
>> 64 bytes from 192.168.2.1: icmp_seq=770 ttl=64 time=2.24 ms
>>
>> The pauses can be replicated by executing:
>>
>> sudo iw dev wlan0 scan
>
> If you leave your home channel you cannot be present for data on it.
> One way to address this is to scan on each target channel and come
> back the home channel, and repeat this for every channel you have to
> scan. This is only done with nl80211 though which you would have to
> enable manually through a wpa_supplicant configuration file or by
> editing your wpa_supplicant dbus service file and enabling new
> git-version wpa_supplicant options which are documented on the
> wireless wiki [1]. Let us know if that helps.
>
> ?Luis
>
> [1] http://bombadil.infradead.org/~mcgrof/images/copper-tape-on-bag.jpg

I should note roaming is not yet implemented with nl80211.

  Luis

[ath9k-devel] ath9k: DMA failed to stop in 10 ms

[Johannes Stezenbach]

On Fri, Nov 13, 2009 at 09:35:07AM -0800, Luis R. Rodriguez wrote:
> 
> Can you compile wireless-testing and enable full debugging on ath9k?
> 
> modprobe ath9k debug=0xffffff
> 
> and see if you can capture a few lines around the "DMA failed to stop".

Here it comes:

Nov 16 17:26:10 x kernel: [  259.330436] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
Nov 16 17:26:10 x kernel: [  259.330456] ath: (2437 MHz) -> (2412 MHz), conf_is_ht40: 0
Nov 16 17:26:10 x kernel: [  259.330474] ath: NF calibrated [ctl] [chain 0] is -111
Nov 16 17:26:10 x kernel: [  259.330486] ath: NF calibrated [ext] [chain 0] is 0
Nov 16 17:26:10 x kernel: [  259.333511] ath: PDADC (0,   0): a280 01000000
Nov 16 17:26:10 x kernel: [  259.333529] ath: PDADC: Chain 0 | PDADC   0 Value   0 | PDADC   1 Value   0 | PDADC   2 Value   0 | PDADC   3 Value   1 |
Nov 16 17:26:10 x kernel: [  259.333581] ath: PDADC (0,   0): a284 05040302
Nov 16 17:26:10 x kernel: [  259.333593] ath: PDADC: Chain 0 | PDADC   4 Value   2 | PDADC   5 Value   3 | PDADC   6 Value   4 | PDADC   7 Value   5 |
Nov 16 17:26:10 x kernel: [  259.333610] ath: PDADC (0,   0): a288 09080706
Nov 16 17:26:10 x kernel: [  259.333620] ath: PDADC: Chain 0 | PDADC   8 Value   6 | PDADC   9 Value   7 | PDADC  10 Value   8 | PDADC  11 Value   9 |
Nov 16 17:26:10 x kernel: [  259.333637] ath: PDADC (0,   0): a28c 0e0d0b0a
Nov 16 17:26:10 x kernel: [  259.333647] ath: PDADC: Chain 0 | PDADC  12 Value  10 | PDADC  13 Value  11 | PDADC  14 Value  13 | PDADC  15 Value  14 |
Nov 16 17:26:10 x kernel: [  259.333664] ath: PDADC (0,   0): a290 14131110
Nov 16 17:26:10 x kernel: [  259.333675] ath: PDADC: Chain 0 | PDADC  16 Value  16 | PDADC  17 Value  17 | PDADC  18 Value  19 | PDADC  19 Value  20 |
Nov 16 17:26:10 x kernel: [  259.333690] ath: PDADC (0,   0): a294 1b191716
Nov 16 17:26:10 x kernel: [  259.333699] ath: PDADC: Chain 0 | PDADC  20 Value  22 | PDADC  21 Value  23 | PDADC  22 Value  25 | PDADC  23 Value  27 |
Nov 16 17:26:10 x kernel: [  259.333714] ath: PDADC (0,   0): a298 2724211e
Nov 16 17:26:10 x kernel: [  259.333723] ath: PDADC: Chain 0 | PDADC  24 Value  30 | PDADC  25 Value  33 | PDADC  26 Value  36 | PDADC  27 Value  39 |
Nov 16 17:26:10 x kernel: [  259.333738] ath: PDADC (0,   0): a29c 38332e2a
Nov 16 17:26:10 x kernel: [  259.333748] ath: PDADC: Chain 0 | PDADC  28 Value  42 | PDADC  29 Value  46 | PDADC  30 Value  51 | PDADC  31 Value  56 |
Nov 16 17:26:10 x kernel: [  259.333765] ath: PDADC (0,   0): a2a0 4b46413d
Nov 16 17:26:10 x kernel: [  259.333776] ath: PDADC: Chain 0 | PDADC  32 Value  61 | PDADC  33 Value  65 | PDADC  34 Value  70 | PDADC  35 Value  75 |
Nov 16 17:26:10 x kernel: [  259.333793] ath: PDADC (0,   0): a2a4 5f5a5550
Nov 16 17:26:10 x kernel: [  259.333804] ath: PDADC: Chain 0 | PDADC  36 Value  80 | PDADC  37 Value  85 | PDADC  38 Value  90 | PDADC  39 Value  95 |
Nov 16 17:26:10 x kernel: [  259.333820] ath: PDADC (0,   0): a2a8 0f0e0d64
Nov 16 17:26:10 x kernel: [  259.333831] ath: PDADC: Chain 0 | PDADC  40 Value 100 | PDADC  41 Value  13 | PDADC  42 Value  14 | PDADC  43 Value  15 |
Nov 16 17:26:10 x kernel: [  259.333848] ath: PDADC (0,   0): a2ac 15131210
Nov 16 17:26:10 x kernel: [  259.333858] ath: PDADC: Chain 0 | PDADC  44 Value  16 | PDADC  45 Value  18 | PDADC  46 Value  19 | PDADC  47 Value  21 |
Nov 16 17:26:10 x kernel: [  259.333876] ath: PDADC (0,   0): a2b0 1c1a1816
Nov 16 17:26:10 x kernel: [  259.333886] ath: PDADC: Chain 0 | PDADC  48 Value  22 | PDADC  49 Value  24 | PDADC  50 Value  26 | PDADC  51 Value  28 |
Nov 16 17:26:10 x kernel: [  259.333903] ath: PDADC (0,   0): a2b4 2422201e
Nov 16 17:26:10 x kernel: [  259.333913] ath: PDADC: Chain 0 | PDADC  52 Value  30 | PDADC  53 Value  32 | PDADC  54 Value  34 | PDADC  55 Value  36 |
Nov 16 17:26:10 x kernel: [  259.333930] ath: PDADC (0,   0): a2b8 312d2a26
Nov 16 17:26:10 x kernel: [  259.333940] ath: PDADC: Chain 0 | PDADC  56 Value  38 | PDADC  57 Value  42 | PDADC  58 Value  45 | PDADC  59 Value  49 |
Nov 16 17:26:10 x kernel: [  259.333957] ath: PDADC (0,   0): a2bc 423c3834
Nov 16 17:26:10 x kernel: [  259.333968] ath: PDADC: Chain 0 | PDADC  60 Value  52 | PDADC  61 Value  56 | PDADC  62 Value  60 | PDADC  63 Value  66 |
Nov 16 17:26:10 x kernel: [  259.333985] ath: PDADC (0,   0): a2c0 59534d48
Nov 16 17:26:10 x kernel: [  259.333995] ath: PDADC: Chain 0 | PDADC  64 Value  72 | PDADC  65 Value  77 | PDADC  66 Value  83 | PDADC  67 Value  89 |
Nov 16 17:26:10 x kernel: [  259.334012] ath: PDADC (0,   0): a2c4 716b655f
Nov 16 17:26:10 x kernel: [  259.334023] ath: PDADC: Chain 0 | PDADC  68 Value  95 | PDADC  69 Value 101 | PDADC  70 Value 107 | PDADC  71 Value 113 |
Nov 16 17:26:10 x kernel: [  259.334039] ath: PDADC (0,   0): a2c8 7d7d7d77
Nov 16 17:26:10 x kernel: [  259.334050] ath: PDADC: Chain 0 | PDADC  72 Value 119 | PDADC  73 Value 125 | PDADC  74 Value 125 | PDADC  75 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334066] ath: PDADC (0,   0): a2cc 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334076] ath: PDADC: Chain 0 | PDADC  76 Value 125 | PDADC  77 Value 125 | PDADC  78 Value 125 | PDADC  79 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334093] ath: PDADC (0,   0): a2d0 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334103] ath: PDADC: Chain 0 | PDADC  80 Value 125 | PDADC  81 Value 125 | PDADC  82 Value 125 | PDADC  83 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334119] ath: PDADC (0,   0): a2d4 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334129] ath: PDADC: Chain 0 | PDADC  84 Value 125 | PDADC  85 Value 125 | PDADC  86 Value 125 | PDADC  87 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334145] ath: PDADC (0,   0): a2d8 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334154] ath: PDADC: Chain 0 | PDADC  88 Value 125 | PDADC  89 Value 125 | PDADC  90 Value 125 | PDADC  91 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334172] ath: PDADC (0,   0): a2dc 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334182] ath: PDADC: Chain 0 | PDADC  92 Value 125 | PDADC  93 Value 125 | PDADC  94 Value 125 | PDADC  95 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334198] ath: PDADC (0,   0): a2e0 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334208] ath: PDADC: Chain 0 | PDADC  96 Value 125 | PDADC  97 Value 125 | PDADC  98 Value 125 | PDADC  99 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334224] ath: PDADC (0,   0): a2e4 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334235] ath: PDADC: Chain 0 | PDADC 100 Value 125 | PDADC 101 Value 125 | PDADC 102 Value 125 | PDADC 103 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334251] ath: PDADC (0,   0): a2e8 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334262] ath: PDADC: Chain 0 | PDADC 104 Value 125 | PDADC 105 Value 125 | PDADC 106 Value 125 | PDADC 107 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334280] ath: PDADC (0,   0): a2ec 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334290] ath: PDADC: Chain 0 | PDADC 108 Value 125 | PDADC 109 Value 125 | PDADC 110 Value 125 | PDADC 111 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334306] ath: PDADC (0,   0): a2f0 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334316] ath: PDADC: Chain 0 | PDADC 112 Value 125 | PDADC 113 Value 125 | PDADC 114 Value 125 | PDADC 115 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334334] ath: PDADC (0,   0): a2f4 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334344] ath: PDADC: Chain 0 | PDADC 116 Value 125 | PDADC 117 Value 125 | PDADC 118 Value 125 | PDADC 119 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334362] ath: PDADC (0,   0): a2f8 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334372] ath: PDADC: Chain 0 | PDADC 120 Value 125 | PDADC 121 Value 125 | PDADC 122 Value 125 | PDADC 123 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334389] ath: PDADC (0,   0): a2fc 7d7d7d7d
Nov 16 17:26:10 x kernel: [  259.334399] ath: PDADC: Chain 0 | PDADC 124 Value 125 | PDADC 125 Value 125 | PDADC 126 Value 125 | PDADC 127 Value 125 |
Nov 16 17:26:10 x kernel: [  259.334437] ath: Getting spur idx 0 is2Ghz. 1 val 8000
Nov 16 17:26:10 x kernel: [  259.334449] ath: Getting spur idx 1 is2Ghz. 1 val 8000
Nov 16 17:26:10 x kernel: [  259.334459] ath: Getting spur idx 2 is2Ghz. 1 val 8000
Nov 16 17:26:10 x kernel: [  259.334469] ath: Getting spur idx 3 is2Ghz. 1 val 8000
Nov 16 17:26:10 x kernel: [  259.334478] ath: Getting spur idx 4 is2Ghz. 1 val 8000
Nov 16 17:26:10 x kernel: [  259.336168] ath: Reset TX queue: 0
Nov 16 17:26:10 x kernel: [  259.336182] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
Nov 16 17:26:10 x kernel: [  259.336197] ath: Reset TX queue: 1
Nov 16 17:26:10 x kernel: [  259.336206] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
Nov 16 17:26:10 x kernel: [  259.336220] ath: Reset TX queue: 2
Nov 16 17:26:10 x kernel: [  259.336230] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
Nov 16 17:26:10 x kernel: [  259.336244] ath: Reset TX queue: 3
Nov 16 17:26:10 x kernel: [  259.336253] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
Nov 16 17:26:10 x kernel: [  259.336267] ath: Reset TXQ, inactive queue: 4
Nov 16 17:26:10 x kernel: [  259.336276] ath: Reset TXQ, inactive queue: 5
Nov 16 17:26:10 x kernel: [  259.336284] ath: Reset TXQ, inactive queue: 6
Nov 16 17:26:10 x kernel: [  259.336293] ath: Reset TXQ, inactive queue: 7
Nov 16 17:26:10 x kernel: [  259.336302] ath: Reset TX queue: 8
Nov 16 17:26:10 x kernel: [  259.336318] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
Nov 16 17:26:10 x kernel: [  259.336333] ath: Reset TX queue: 9
Nov 16 17:26:10 x kernel: [  259.336350] ath: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0
Nov 16 17:26:10 x kernel: [  259.336408] ath: ah->misc_mode 0x4
Nov 16 17:26:10 x kernel: [  259.337714] ath: Running PA Calibration
Nov 16 17:26:10 x kernel: [  259.338364] ath: enabling ADC Gain Calibration.
Nov 16 17:26:10 x kernel: [  259.338374] ath: enabling ADC DC Calibration.
Nov 16 17:26:10 x kernel: [  259.338383] ath: enabling IQ Calibration.
Nov 16 17:26:10 x kernel: [  259.338394] ath: starting ADC Gain Calibration
Nov 16 17:26:10 x kernel: [  259.343041] ath: Enable MIB counters
Nov 16 17:26:10 x kernel: [  259.343100] ath: ANI parameters:
Nov 16 17:26:10 x kernel: [  259.343110] ath: noiseImmunityLevel=0, spurImmunityLevel=0, ofdmWeakSigDetectOff=0
Nov 16 17:26:10 x kernel: [  259.343123] ath: cckWeakSigThreshold=0, firstepLevel=0, listenTime=0
Nov 16 17:26:10 x kernel: [  259.343135] ath: cycleCount=0, ofdmPhyErrCount=0, cckPhyErrCount=0
Nov 16 17:26:10 x kernel: [  259.343143] 
Nov 16 17:26:10 x kernel: [  259.343159] ath: Writing ofdmbase=12582412   cckbase=12582712
Nov 16 17:26:10 x kernel: [  259.343186] ath: 0x81800964 => 0xf0000071
Nov 16 17:26:10 x kernel: [  259.343196] ath: disable IER
Nov 16 17:26:10 x kernel: [  259.343210] ath: new IMR 0x918004b4
Nov 16 17:26:10 x kernel: [  259.343223] ath: enable IER
Nov 16 17:26:10 x kernel: [  259.343237] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:10 x kernel: [  259.391939] ath: 0xf0000071 => 0x0
Nov 16 17:26:10 x kernel: [  259.391960] ath: disable IER
Nov 16 17:26:10 x kernel: [  259.391978] ath: new IMR 0x0
Nov 16 17:26:10 x kernel: [  259.392062] ath: 0x0 => 0xf0000071
Nov 16 17:26:10 x kernel: [  259.392071] ath: new IMR 0x918004b4
Nov 16 17:26:10 x kernel: [  259.392083] ath: enable IER
Nov 16 17:26:10 x kernel: [  259.392094] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:10 x kernel: [  259.418408] ath: 0xf0000071 => 0x0
Nov 16 17:26:10 x kernel: [  259.418426] ath: disable IER
Nov 16 17:26:10 x kernel: [  259.418444] ath: new IMR 0x0
Nov 16 17:26:10 x kernel: [  259.418516] ath: 0x0 => 0xf0000071
Nov 16 17:26:10 x kernel: [  259.418527] ath: new IMR 0x918004b4
Nov 16 17:26:10 x kernel: [  259.418543] ath: enable IER
Nov 16 17:26:10 x kernel: [  259.418558] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:10 x kernel: [  259.423448] ath: 0xf0000071 => 0x0
Nov 16 17:26:10 x kernel: [  259.423461] ath: disable IER
Nov 16 17:26:10 x kernel: [  259.423474] ath: new IMR 0x0
Nov 16 17:26:10 x kernel: [  259.423519] ath: 0x0 => 0xf0000071
Nov 16 17:26:10 x kernel: [  259.423527] ath: new IMR 0x918004b4
Nov 16 17:26:10 x kernel: [  259.423538] ath: enable IER
Nov 16 17:26:10 x kernel: [  259.423550] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:10 x kernel: [  259.430085] ath: 0xf0000071 => 0x0
Nov 16 17:26:10 x kernel: [  259.430100] ath: disable IER
Nov 16 17:26:10 x kernel: [  259.430115] ath: new IMR 0x0
Nov 16 17:26:10 x kernel: [  259.430176] ath: 0x0 => 0xf0000071
Nov 16 17:26:10 x kernel: [  259.430186] ath: new IMR 0x918004b4
Nov 16 17:26:10 x kernel: [  259.430200] ath: enable IER
Nov 16 17:26:10 x kernel: [  259.430213] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:10 x kernel: [  259.494366] ath: 0xf0000071 => 0x0
Nov 16 17:26:10 x kernel: [  259.494386] ath: disable IER
Nov 16 17:26:10 x kernel: [  259.494404] ath: new IMR 0x0
Nov 16 17:26:10 x kernel: [  259.494474] ath: 0x0 => 0xf0000071
Nov 16 17:26:10 x kernel: [  259.494482] ath: new IMR 0x918004b4
Nov 16 17:26:10 x kernel: [  259.494494] ath: enable IER
Nov 16 17:26:10 x kernel: [  259.494505] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:11 x kernel: [  259.520840] ath: 0xf0000071 => 0x0
Nov 16 17:26:11 x kernel: [  259.520860] ath: disable IER
Nov 16 17:26:11 x kernel: [  259.520878] ath: new IMR 0x0
Nov 16 17:26:11 x kernel: [  259.520949] ath: 0x0 => 0xf0000071
Nov 16 17:26:11 x kernel: [  259.520963] ath: new IMR 0x918004b4
Nov 16 17:26:11 x kernel: [  259.520979] ath: enable IER
Nov 16 17:26:11 x kernel: [  259.520994] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:11 x kernel: [  259.521268] ath: Set channel: 2437 MHz
Nov 16 17:26:11 x kernel: [  259.521285] ath: tx chmask: 1, rx chmask: 1
Nov 16 17:26:11 x kernel: [  259.521301] ath: 0xf0000071 => 0x0
Nov 16 17:26:11 x kernel: [  259.521314] ath: disable IER
Nov 16 17:26:11 x kernel: [  259.521331] ath: new IMR 0x0
Nov 16 17:26:11 x kernel: [  259.521441] ath: Disable MIB counters
Nov 16 17:26:11 x kernel: [  259.536370] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x00000020
Nov 16 17:26:11 x kernel: [  259.536405] ath: (2412 MHz) -> (2437 MHz), conf_is_ht40: 0


It does not happen on every frequency hop, sometimes it looks like this:


Nov 16 17:26:13 x kernel: [  261.600077] ath: Enable MIB counters
Nov 16 17:26:13 x kernel: [  261.600106] ath: ANI parameters:
Nov 16 17:26:13 x kernel: [  261.600115] ath: noiseImmunityLevel=0, spurImmunityLevel=7, ofdmWeakSigDetectOff=1
Nov 16 17:26:13 x kernel: [  261.600127] ath: cckWeakSigThreshold=0, firstepLevel=0, listenTime=0
Nov 16 17:26:13 x kernel: [  261.600138] ath: cycleCount=0, ofdmPhyErrCount=0, cckPhyErrCount=0
Nov 16 17:26:13 x kernel: [  261.600146] 
Nov 16 17:26:13 x kernel: [  261.600162] ath: Writing ofdmbase=12582412   cckbase=12582712
Nov 16 17:26:13 x kernel: [  261.600190] ath: 0x81800964 => 0xf0000071
Nov 16 17:26:13 x kernel: [  261.600200] ath: disable IER
Nov 16 17:26:13 x kernel: [  261.600215] ath: new IMR 0x918004b4
Nov 16 17:26:13 x kernel: [  261.600229] ath: enable IER
Nov 16 17:26:13 x kernel: [  261.600243] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:13 x kernel: [  261.653893] ath: 0xf0000071 => 0x0
Nov 16 17:26:13 x kernel: [  261.653905] ath: disable IER
Nov 16 17:26:13 x kernel: [  261.653917] ath: new IMR 0x0
Nov 16 17:26:13 x kernel: [  261.653960] ath: 0x0 => 0xf0000071
Nov 16 17:26:13 x kernel: [  261.653967] ath: new IMR 0x918004b4
Nov 16 17:26:13 x kernel: [  261.653996] ath: enable IER
Nov 16 17:26:13 x kernel: [  261.654007] ath: AR_IMR 0x918004b4 IER 0x1
Nov 16 17:26:13 x kernel: [  261.854631] ath: Set channel: 2412 MHz
Nov 16 17:26:13 x kernel: [  261.854653] ath: tx chmask: 1, rx chmask: 1
Nov 16 17:26:13 x kernel: [  261.854671] ath: 0xf0000071 => 0x0
Nov 16 17:26:13 x kernel: [  261.854684] ath: disable IER
Nov 16 17:26:13 x kernel: [  261.854702] ath: new IMR 0x0
Nov 16 17:26:13 x kernel: [  261.854813] ath: Disable MIB counters
Nov 16 17:26:13 x kernel: [  261.854842] ath: (2457 MHz) -> (2412 MHz), conf_is_ht40: 0


Johannes