Re: ath9k: irq storm after suspend/resume

From: Adrian Chadd <adrian@freebsd.org>
To: Clemens Buchacher <drizzd@aon.at>
Cc: Mohammed Shafi <shafi.wireless@gmail.com>,
	linux-wireless@vger.kernel.org
Subject: Re: ath9k: irq storm after suspend/resume
Date: Tue, 4 Oct 2011 15:58:09 +0800	[thread overview]
Message-ID: <CAJ-Vmo=sE4KeOp1CKAR5v+Rzm1bm0R=ZvtMvJaE_8Sjn1dOdsw@mail.gmail.com> (raw)
In-Reply-To: <20111003084823.GA1521@ecki.lan>

Right, this looks a bit evil. ;)

On 3 October 2011 16:48, Clemens Buchacher <drizzd@aon.at> wrote:

> for 1, 2, ..., 99, 128, 256:
> AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
> AR_IMR: 0xdeadbeef, AR_ISR: 0xdeadbeef

.. that says some part of the MAC is very asleep. But no interrupt
cause bits are set. So I bet it's a shared interrupt.

> for 512:
> AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
> AR_IMR: 0x00000000, AR_ISR: 0x00000208

That looks valid, but why are you receiving an interrupt here? Is it
some other device on a shared irq? Or a non-acked interrupt?
Ie - there's no sync/async cause bits set and IMR is 0, the status
bits are no tx pkt / no rx pkt. So that looks fine. You shouldn't have
received an interrupt.

> for 1024:
> AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
> AR_IMR: 0x81800964, AR_ISR: 0x00000008

.. hm,  why'd you receive an interrupt here? the ISR bits aren't set that way.
Again, I think this is another shared or non-acked interrupt coming in.

> for 2048:
> AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
> AR_IMR: 0xdeadbeef, AR_ISR: 0xdeadbeef
>
> for 2^12, 2^13, ..., 2^16
> AR_INTR_SYNC_CAUSE: 0x00020000, AR_INTR_ASYNC_CAUSE: 0x00000000
> AR_IMR: 0xdeadbeef, AR_ISR: 0xdeadbeef
>
> The last ones indeed correspond to AR_INTR_SYNC_MAC_SLEEP_ACCESS
> that you mentioned. Note that this output is interleaved with
> device initialization. So I don't know if that causes the register
> contents to become valid, or if it changes the contents.
>
> If I suspend/resume first, then load the module, then wait for 500
> ms after request_irq I get only zeroes, repeated 109 times:
>
> for 1, 2, ..., 99, 2^7, 2^8, ..., 2^16:
> AR_IMR: 0x00000000, AR_ISR: 0x00000000
> AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000

Would you mind also printing the contents of AR_IER there? I wonder if
AR_IER is incorrectly being enabled.

I think this may be a shared interrupt. What else is using the same
IRQ line? What about only printing out those lines if the interrupt is
actually generated by the NIC? There's a function further down in the
isr routine which checks whether the NIC itself posted the interrupt
(it checks SYNC_CAUSE/ASYNC_CAUSE.) That should cut down the spam
quite a bit and only log the relevant entries for ath9k.

Adrian