Date: Sun, 2 Jun 2013 15:31:25 -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-Vmomozv_t36FbVCTA-USREkeQThXQ1mDoN79tTejfd1va0w@mail.gmail.com> In-Reply-To: <CAJ-VmokJ9dXJX%2Bj0osE9yPB3vSbn_DhW1RqznG_9M0SsV0hg-Q@mail.gmail.com> References: <CAKZxVQUcUfxbmj2uot7fUdMei3gegX3RtPFhy3aMOSUZY0Yn1w@mail.gmail.com> <CAJ-VmokJ9dXJX%2Bj0osE9yPB3vSbn_DhW1RqznG_9M0SsV0hg-Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
.. and stupidly, my reset code does this: * wait for tx/rx to finish * bump reset counter rather than what it should be doing, which is: * bump reset counter * wait for tx/rx to finish because TX will continue if the reset flag isn't set. And I bet that's what is going on. Thanks for pointing this out Kim! I'll add this to the PR you create and push out a fix to HEAD for you to try ASAP. Adrian On 2 June 2013 15:26, Adrian Chadd <adrian@freebsd.org> wrote: > 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! > > > > Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmomozv_t36FbVCTA-USREkeQThXQ1mDoN79tTejfd1va0w>