Return-path: Received: from mail-yw0-f46.google.com ([209.85.213.46]:43096 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754909Ab1JDH6J (ORCPT ); Tue, 4 Oct 2011 03:58:09 -0400 Received: by ywb5 with SMTP id 5so202488ywb.19 for ; Tue, 04 Oct 2011 00:58:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20111003084823.GA1521@ecki.lan> References: <20110830064137.GA4719@ecki> <14be9f3b-4c91-481d-9e52-f3119659fd59@email.android.com> <20110927214245.GA1416@ecki> <20111003084823.GA1521@ecki.lan> Date: Tue, 4 Oct 2011 15:58:09 +0800 Message-ID: (sfid-20111004_095813_775148_4C3FB1E1) Subject: Re: ath9k: irq storm after suspend/resume From: Adrian Chadd To: Clemens Buchacher Cc: Mohammed Shafi , linux-wireless@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: Right, this looks a bit evil. ;) On 3 October 2011 16:48, Clemens Buchacher 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