On 2 June 2013 04:49, Kim Culhan <w8hd...@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

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!

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to