Ok, try updating to the latest -HEAD. I /think/ I fixed the ath(4)
transmit issue.
Thanks!
-a
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-u
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 an
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 ath(4) and
>> yeah, we can't guarantee the o
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 other drivers are do
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 ca
