Re: bridge/wifi panic

Ok, I've dug into it a bit more. The root bits here were more exposed from the ifnet changes that were made, but the TL;DR is that if the driver starts to transmit the frame and fails, we can't return an error. We have to free the buffer ourselves. So for ath, and maybe iwn too, we can't return

[Bug 204228] wlan interface cannot connect to AP if_iwm driver - Intel Dual Band Wireless AC 3160

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204228 Bug ID: 204228 Summary: wlan interface cannot connect to AP if_iwm driver - Intel Dual Band Wireless AC 3160 Product: Base System Version: 11.0-CURRENT Hardware:

Re: bridge/wifi panic

Actually, this is more annoying than I'd thought. There's a whole bunch of places where mbufs can change during processing in ath(4) and yeah, we can't guarantee the original mbuf is available. I wonder how many other drivers are doing this - stuff like m_collapse(), m_defrag(), etc. If this is

Re: bridge/wifi panic

Tue, 03 Nov 2015 00:38:45 +0200 було написано Adrian Chadd : Actually, this is more annoying than I'd thought. There's a whole bunch of places where mbufs can change during processing in ath(4) and yeah, we can't guarantee the original mbuf is available. I wonder how many

Re: bridge/wifi panic

On 2 November 2015 at 14:49, Andriy Voskoboinyk wrote: > Tue, 03 Nov 2015 00:38:45 +0200 було написано Adrian Chadd > : > >> Actually, this is more annoying than I'd thought. There's a whole >> bunch of places where mbufs can change during processing in