From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from bsmtp4.bon.at ([195.3.86.186]:52854 "EHLO bsmtp.bon.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751151Ab1JOJic (ORCPT ); Sat, 15 Oct 2011 05:38:32 -0400 Date: Sat, 15 Oct 2011 11:39:02 +0200 From: Clemens Buchacher To: Mohammed Shafi Cc: Adrian Chadd , linux-wireless@vger.kernel.org Subject: Re: ath9k: irq storm after suspend/resume Message-ID: <20111015093902.GA23520@ecki> (sfid-20111015_113838_028184_7F5723D6) References: <20111003084823.GA1521@ecki.lan> <20111004181534.GA1502@ecki> <20111005062528.GA1403@ecki> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-wireless-owner@vger.kernel.org List-ID: Hi Mohammed, On Wed, Oct 12, 2011 at 06:40:06PM +0530, Mohammed Shafi wrote: > > please try this in case it helps anything > to debug the issue. With this, the previous instaces of 0xdeadbeaf are replaced with zeroes, and I do not get any non-zero traces for SYNC_CAUSE or ASYNC_CAUSE any more. > this should avoid dead beef and the interrupt when we access MAC > registers when the MAC is asleep. also i did not see MAC irq being not > triggerred in your case(AR_INTR_ASYNC_CAUSE should be 0x2) or may be > its not an interrupt triggered by the chip itself. thanks If it's not triggered by ath9k, I do wonder why it works if I suspend in connected mode, and why reloading the driver usually fixes the issue. Maybe there is something in the driver unloading code that we could look at? Clemens