panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1

[Adrian Chadd]

.. 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 at freebsd.org> wrote:
> On 2 June 2013 04:49, Kim Culhan <w8hdkim at 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