Right, this looks a bit evil. ;) 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. > 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 -- 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
