Return-path: Received: from bsmtp4.bon.at ([195.3.86.186]:55475 "EHLO bsmtp.bon.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753750Ab1JEG2N (ORCPT ); Wed, 5 Oct 2011 02:28:13 -0400 Date: Wed, 5 Oct 2011 08:28:43 +0200 From: Clemens Buchacher To: Adrian Chadd Cc: Mohammed Shafi , linux-wireless@vger.kernel.org Subject: Re: ath9k: irq storm after suspend/resume Message-ID: <20111005062528.GA1403@ecki> (sfid-20111005_082816_913540_468E52B4) References: <20110927214245.GA1416@ecki> <20111003084823.GA1521@ecki.lan> <20111004181534.GA1502@ecki> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, Oct 05, 2011 at 05:11:00AM +0800, Adrian Chadd wrote: > > Well, the question now is whether the device itself is actually firing > off interrupts. > > From what you've shown there, the device _isn't_ firing off interrupts > the normal way. > So I wonder if it's the card or whether it's something else (eg the > PCI bus glue.) > > Here, you could try inserting this in the SC_OP_INVALID bit, right > after you do some logging. I'm still assuming your AR9285 is somehow > firing off interrupts. > At this point however I'm all just guessing here. It'd be nice to know > whether the device is _really_ sending interrupts or not. No change with the code below, except that the timing is slightly different. > /* Mark _all_ async interrupts as serviced */ > REG_WRITE(ah, AR_INTR_ASYNC_CAUSE, 0xffffffff); > REG_READ(ah, AR_INTR_ASYNC_CAUSE); > > /* Disable sync interrupt sources */ > REG_WRITE(ah, AR_INTR_SYNC_ENABLE, 0); > /* Mark _all_ sync interrupts as serviced */ > REG_WRITE(ah, AR_INTR_SYNC_CAUSE, 0xffffffff); > REG_READ(ah, AR_INTR_SYNC_CAUSE); > > /* Do a reset of the AHB and host interface */ > REG_WRITE(ah, AR_RC, AR_RC_AHB | AR_RC_HOSTIF); > DELAY(100); Since I could not find a suitable DELAY macro, I used this instead: int delay = 100; DO_DELAY(delay); > REG_WRITE(ah, AR_RC, 0); For the record, instead of going to full sleep, I can reproduce the issue with echo devices >/sys/power/pm_test echo mem >/sys/power/state but not with echo freezer >/sys/power/pm_test echo mem >/sys/power/state So it could still be a different device that's causing the issue? I can try unloading all kinds of modules. Or is there an option to suspend just one device? Clemens