.. 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 <[email protected]> wrote: > 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]"
