From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jouni Malinen <jouni.malinen@atheros.com>
Date: Tue, 19 May 2009 10:20:36 +0300
Subject: [ath9k-devel] EEE PC with AR9280 using N mode with WPA2
In-Reply-To: <4A11C68F.5060108@openwrt.org>
References: <BAY118-W504A562EAA1897CAA2E309B35D0@phx.gbl>
	<4A11C68F.5060108@openwrt.org>
Message-ID: <1242717636.14488.14.camel@jm-desktop>
List-Id: <ath9k-devel.lists.ath9k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: ath9k-devel@lists.ath9k.org

On Mon, 2009-05-18 at 13:35 -0700, Gabor Juhos wrote:

> I have discovered some weird crashes on various embedded (MIPS, ARM) boards with
> 2.6.30-rc5+compat-wireless-2009-05-15. I'm not sure that is the same error
> but seems similar at least. The strange thing, that i saw a '0xdeadbeef' value in
> the interrupt status register.

I have not seen that value nor a crash (AR9280 on AMD64), but the debug
log you showed looks quite familiar..

> ath9k: AWAKE -> NETWORK SLEEP
> ath9k: *** Dead beef in register 000080ec!
> Backtrace:
> [<c0524b0c>] (warn_slowpath_null+0x0/0x20) from [<bf1b7820>] (ath9k_ioread32+0xc0/0x140 [ath9k])
> [<bf1b7760>] (ath9k_ioread32+0x0/0x140 [ath9k]) from [<bf1cc5fc>] (ath9k_hw_ani_monitor+0x5c/0x454 [ath9k])
>  r7:00000000 r6:c11015d4 r5:c1100000 r4:000015d0
> [<bf1cc5a0>] (ath9k_hw_ani_monitor+0x0/0x454 [ath9k]) from [<bf1d15ec>] (ath_ani_calibrate+0x168/0x250 [ath9k])
>  r8:00000000 r7:00000000 r6:c1100000 r5:c1cba954 r4:fffc0ba8
> [<bf1d1484>] (ath_ani_calibrate+0x0/0x250 [ath9k]) from [<c052e820>] (run_timer_softirq+0x178/0x1f0)

I noticed this when debugging PS mode. The periodic ANI/calibration step
is being run here and that is not such a good idea to be done when the
chip is mostly sleeping.. I would assume it could (at least partially)
explain what you are seeing here.

I have a patch that skips the calibration step in PS mode and plan to
send that out with some other PS mode fixes after some more testing.

I'm not sure about the other cases shown in your debug log, though. If
they continue to show up, it might be useful to check whether we are
getting AR_INTR_SYNC_MAC_SLEEP_ACCESS events when in sleep mode. I think
I've now managed to resolve most, if not all, of those in my work
version.

- Jouni