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
playing with 802.11p / DMCA-86P2
So Unex gave me a couple of their 802.11p NICs to play with. http://www.unex.com.tw/product/dcma-86p2 It's a NIC specifically designed for the 5.9GHz band for 802.11p deployments. Now, the NIC probes and detects fine under FreeBSD. The main issue is the lack of regulatory information for said NIC. It's calibrated for 5.8-5.9GHz; it likely will work on other 5GHz channels but: * there's lots of filtering on the front end of this thing, so it's highly attenuated outside of the 11p frequencies; * the power calibration curves for transmit power control are _only_ for 5.8/5.9GHz. So to bring this up: * I have to add a new SKU for this particular NIC, as it comes up as regdomain/SKU 0x0 (ie, they didn't bother programming in one. Grr.) * I have to add a new regulatory domain entry for it, specifically to allow 5.8/5.9GHz operation. * We have to figure out which regulatory domains these cards are actually ok to use, and what the maximum transmit power is for each. But if people want to tinker with 802.11p and have the relevant licencing to do so, they will mostly work out of the box. 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
