From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-yw0-f46.google.com ([209.85.213.46]:61427 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753373Ab1JUOKW (ORCPT ); Fri, 21 Oct 2011 10:10:22 -0400 Received: by ywf7 with SMTP id 7so3899182ywf.19 for ; Fri, 21 Oct 2011 07:10:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20111021102221.GA1463@ecki.lan> References: <20111004181534.GA1502@ecki> <20111005062528.GA1403@ecki> <20111015093902.GA23520@ecki> <20111018064459.GA1442@ecki> <20111021102221.GA1463@ecki.lan> Date: Fri, 21 Oct 2011 22:10:21 +0800 Message-ID: (sfid-20111021_161025_990041_D37AD28D) Subject: Re: ath9k: irq storm after suspend/resume From: Adrian Chadd To: Clemens Buchacher Cc: Mohammed Shafi , linux-wireless@vger.kernel.org, ath9k-devel Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 21 October 2011 18:22, Clemens Buchacher wrote: > It matches AR_SREV_9285, but it does not match AR_SREV_9285E_20. Ok. Well, I've read the ar9285 host documentation that I've gotten my hands on and I can't see anything obvious. All I can think of is that something else is throwing those interrupts - whether it's the NIC throwing the error, or whether its the bus itself throwing an error and you're seeing the AR9285 because it's the only thing attached. I however know next to nothing about PCI/PCIe and the various fruity behaviour seen. I assume you have disabled the NIC power save option. Not just APSM, etc, but the powersave options in iw. I don't know what they are, sorry, only that they exist. I suggest modifying ath_intr() so if there is an interrupt storm, disable _all_ sources of interrupts (ie, set sync_cause, async_cause to 0, set imr to 0, set ier to 0) and see if it continues occuring. If the interrupt storm continue occuring, try putting the whole NIC to sleep entirely (ie, call pcipowersave to put the NIC to sleep, then make sure the NIC -stays- asleep somehow, ie so nothing else tries waking it up - I don't know how to do this, likely you'll have to clear some interface flag so the rest of the ath9k and 802.11 stack thinks the nic is actually down for the count) and see if you're still getting spurious interrupts. If you are at this point, the only other possible thing I can think of doing involves a PCIe bus analyser, and you/I don't have access to those. :-) Adrian From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Chadd Date: Fri, 21 Oct 2011 22:10:21 +0800 Subject: [ath9k-devel] ath9k: irq storm after suspend/resume In-Reply-To: <20111021102221.GA1463@ecki.lan> References: <20111004181534.GA1502@ecki> <20111005062528.GA1403@ecki> <20111015093902.GA23520@ecki> <20111018064459.GA1442@ecki> <20111021102221.GA1463@ecki.lan> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 21 October 2011 18:22, Clemens Buchacher wrote: > It matches AR_SREV_9285, but it does not match AR_SREV_9285E_20. Ok. Well, I've read the ar9285 host documentation that I've gotten my hands on and I can't see anything obvious. All I can think of is that something else is throwing those interrupts - whether it's the NIC throwing the error, or whether its the bus itself throwing an error and you're seeing the AR9285 because it's the only thing attached. I however know next to nothing about PCI/PCIe and the various fruity behaviour seen. I assume you have disabled the NIC power save option. Not just APSM, etc, but the powersave options in iw. I don't know what they are, sorry, only that they exist. I suggest modifying ath_intr() so if there is an interrupt storm, disable _all_ sources of interrupts (ie, set sync_cause, async_cause to 0, set imr to 0, set ier to 0) and see if it continues occuring. If the interrupt storm continue occuring, try putting the whole NIC to sleep entirely (ie, call pcipowersave to put the NIC to sleep, then make sure the NIC -stays- asleep somehow, ie so nothing else tries waking it up - I don't know how to do this, likely you'll have to clear some interface flag so the rest of the ath9k and 802.11 stack thinks the nic is actually down for the count) and see if you're still getting spurious interrupts. If you are at this point, the only other possible thing I can think of doing involves a PCIe bus analyser, and you/I don't have access to those. :-) Adrian