Date: Fri, 16 Jun 2006 20:14:05 -0700 From: Sam Leffler <sam@errno.com> To: Reid Linnemann <lreid@a.cs.okstate.edu> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: atheros 'device timeout' Message-ID: <4493737D.80704@errno.com> In-Reply-To: <20060615225419.D0494A0631@a.cs.okstate.edu> References: <20060615225419.D0494A0631@a.cs.okstate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Reid Linnemann wrote: > On 6/14/2006, "Sam Leffler" <sam@errno.com> wrote: >> Reid Linnemann wrote: >>> Thanks Sam, I've disabled power save mode in both wireless windows >>> clients and I'll see if the problem lightens up. Also, do you know why >>> device timeouts would be spat out by the driver when no stations are >>> associated with the AP? The device timeouts persisted after my clients >>> were shut down, and no other stations appear to be in the area. >> No idea. The problem with buffered mcast frames is because the h/w xmit >> queue for the frames stops running and blocks the lower priority queues >> causing the watchdog timer to fire (and generate the device timeout >> msg). I'm pretty sure this is a race between ath_tx_start and >> ath_beacon_proc but I've not had time to rework the code and test (this >> problem does not exist in the linux version but it's structured very >> differently). If no clients are associated (or associated w/ power save >> enabled) then no frames should be buffered and this problem should not >> occur. To debug you can enable reset msgs in the driver (athdebug >> reset) and look to see what h/w q the frame(s) were on when the reset >> was done. Note that to do that you must enable ATH_DEBUG. >> >> Sam > > Sam, > Today I got a device timeout with reset messages enabled, does this > offer any clues? > > ath0: device timeout > ath_draintxq: beacon queue 0x3e672440 > ath_tx_stopdma: tx queue [0] 0, link 0 > ath_tx_stopdma: tx queue [1] 0x3e9ff0a8, link 0xed0dc0d4 > ath_tx_stopdma: tx queue [2] 0, link 0 > ath_tx_stopdma: tx queue [3] 0, link 0 > ath_tx_stopdma: tx queue [8] 0, link 0 > T0 (0xed0db130 0x3e9fe130) 3e9fe15c 30d58436 01240110 01001020 03320000 > 00006f6c 00000000 00000000 > T1 (0xed0db15c 0x3e9fe15c) 3ea02280 30f3b80e 00000000 000000ec 03320000 > 00006f6c d3190001 000203c1 > T0 (0xed0df280 0x3ea02280) 3ea022ac 3e433936 0124016c 01001020 03320000 > 00006f6c 00000000 00000000 > T1 (0xed0df2ac 0x3ea022ac) 3e9ff0a8 3139e016 00000000 00000148 03320000 > 00006f6c 0f790001 00011707 > T0 (0xed0dc0a8 0x3e9ff0a8) 3e9ff0d4 10ad1236 0124016c 01001020 03320000 > 00006f6c 00000000 00000000 > T1 (0xed0dc0d4 0x3e9ff0d4) 00000000 3148f016 00000000 00000148 03320000 > 00006f6c 1ae30001 0000d709 > ath_stoprecv: rx queue 0x21a82c, link 0xc4ba682c ... This doesn't look like the msgs the code in RELENG_6 would generate. Please provide some context. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4493737D.80704>