On Tue, Oct 04, 2011 at 03:58:09PM +0800, Adrian Chadd wrote:
>
> On 3 October 2011 16:48, Clemens Buchacher <drizzd@xxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
