panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1
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. thanks -kim ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1
hi, Can you please provide the backtrace? thanks, adrian 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. thanks -kim ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1
Hi, So this is yet another instance of the MAC being tickled slightly wrong/racy, which could lead to hardware lockups or general craziness. It's happening during a stuck beacon whilst in AP mode. I'll go and review the transmit/receive/reset path again and ensure it's all shut down right during this reset. Thanks! adrian 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. thanks -kim ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1
Oh, and please file a PR. With that core.txt file. It's fine. adrian On 2 June 2013 10:18, Adrian Chadd adr...@freebsd.org wrote: Hi, So this is yet another instance of the MAC being tickled slightly wrong/racy, which could lead to hardware lockups or general craziness. It's happening during a stuck beacon whilst in AP mode. I'll go and review the transmit/receive/reset path again and ensure it's all shut down right during this reset. Thanks! adrian 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. thanks -kim ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1
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 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 ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1
.. 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 adr...@freebsd.org wrote: 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 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 ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
