On 2 June 2013 04:49, Kim Culhan <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "[email protected]"
