Re: ath9k: irq storm after suspend/resume

[Clemens Buchacher <drizzd@aon.at>]

On Tue, Oct 04, 2011 at 03:58:09PM +0800, Adrian Chadd wrote:
> 
> 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.

Unfortunately, that's not it. From /proc/interrupts:

            CPU0       CPU1       CPU2       CPU3       
  17:      24958      25047      25012      24984   IO-APIC-fasteoi   ath9k
  
This is right after the IRQ is disabled because of too many
unhandled interrupts.

> > 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.

Not much more helpful, I'm afraid:

AR_IMR: 0x00000000, AR_ISR: 0x00000000, AR_IER: 0x00000000
AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
(repeated 109 times)

It seems that at this point the device is in a bad state.

Clemens