bridge/wifi panic

Adrian Chadd adrian at freebsd.org
Mon Nov 2 22:38:46 UTC 2015


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 called then the original
mbuf can't be returned upon error.

I'm torn as to whether to back out the mbuf API change and have the
driver consume it, or whether we want to go through the pain of fixing
things.

Let's figure this out ASAP.

Thanks,


-adrian


On 2 November 2015 at 14:35, Adrian Chadd <adrian at freebsd.org> wrote:
> Ok, yeah, I think your initial churn of ath(4) for error handling is
> way incomplete, and we're going to have to fix this stuff before it
> causes lots more issues in -HEAD.
>
>
>
> -a


More information about the freebsd-wireless mailing list