Date: Sun, 2 Jun 2013 15:26:05 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Kim Culhan <w8hdkim@gmail.com> Cc: FreeBSD-wireless@freebsd.org Subject: Re: panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1 Message-ID: <CAJ-VmokJ9dXJX%2Bj0osE9yPB3vSbn_DhW1RqznG_9M0SsV0hg-Q@mail.gmail.com> In-Reply-To: <CAKZxVQUcUfxbmj2uot7fUdMei3gegX3RtPFhy3aMOSUZY0Yn1w@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 2 June 2013 04:49, Kim Culhan <w8hdkim@gmail.com> wrote: > Been seeing panics as in the Subject for a few weeks. > > Now running (and seeing the panics) with r251078M. > > Please let me know if additional info is needed. So, just to brain dump what the story is here. I changed the TX DMA code to implement exactly what the hardware guys want - I touch TxDP once, then I just use the link pointer in the last descriptor in the list to restart DMA. This fix is designed to catch if DMA is being restarted _after_ we've already started DMA and written a TxDP to the hardware. So, either: * I've screwed up the stuck beacon reset path and the hardware isn't being fully stopped before DMA is restarted (which I've done some simple testing of; it doesn't seem like that); * There's some parallel transmission going on that's managed to queue a frame to the transmit queue _and_ start DMA before the reset has completed. Now, in days gone past (read pre FreeBSD-10) this kind of stuff would happen all the time and well, it may explain a lot of why things can get very unhappy. I'm trying to eliminate these, which means adding KASSERT()s to the kernel as I find conditions that must not occur, and .. Kim found one. So I'll go chase this one down. Thanks Kim! Adrianhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokJ9dXJX%2Bj0osE9yPB3vSbn_DhW1RqznG_9M0SsV0hg-Q>