Re: Panic with GENERIC from today

> * Bill Paul <wpaul_at_FreeBSD.ORG> [051107 06:13]:
> > > An i386 GENERIC kernel with an ndisgen'd wrapper for bcmwl5_sys driver
> > > for a Linksys WPC54G panics as it attempts to DHCP.  The back trace
> > > reads (hand transcribed):
> > > kdb_enter (c08y0b30) at kdb_enter + 0x2b
> > > panic(c08773ef,c082441,0,d52bb944,c07daf6) at panic+0x127
> > > mb_free_ext(c3737e00) at mb_free_ext +0x185
> > > m_freem(c3737e00,c34d5cf8,0,c34e2800,c3737e00) at m_freem + 0x1a
> > > ndis_rxeof(c34ec200,d511b9e8,1,c34fc7d4,d51bbb7e) at ndis_rxeof + 0xb9
> > > _end(c3785414,0,c34fc7d4,c34fc000,c34fc7d4)at 0xc333dd61
> > > BCMWL5_SYS_drv_data_start(c3652228,17,7a171200,d51bf098,0) at 0xc09ba8bb
> > > BCMWL5_SYS_drv_data_start() at BCMWL5_SYS_drv_data_start + 0x3110
> > 
> > You know, I'm constantly amazed just how many ways people find to
> > mess up a simple thing like sending in a bug report. You went to
> > so much trouble to emphasize that your system panicked, and you were
> > dilligent enough to copy down the stack trace.
> > 
> > And then you went and forgot to tell us what the panic message said.
> 
> Oops!  Message is:
> NDIS0 Link state changed to Up
> panic mb_free_ext: unknown ext type
> CPUID = 0

Aha, ok. I just committed a small change to ndis_var.h. Sync it and
try again. Alternatively, if you need the NDIS interface, you can
make this small change by hand:

- Bring up ndis_var.h in your favorite editor.
- Find the line that says:

#define EXT_NDIS                0x999

- Change it to:

#define EXT_NDIS                EXT_NET_DRV

- Recompile ndis.ko (specifically, kern_ndis.o)

This is due to an API behavior change that was introduced with the
latest mbuf code changes. It used to be you could call MEXTADD() to
add buffers to an mbuf using an arbitrary type value, and ultimately
they would be released correctly. Now, m_ext_free() will trigger a
KASSERT() if it encounters an EXT_xxx type that isn't specifically
defined in mbuf.h.

This change to ndis_var.h gets around that for now, though in my
opinion m_ext_free() should be modified to restore the old behavior,
particularly since the way the code is structured now, if you build
a non-debug kernel, you'll end up leaking the attached buffer instead
of getting a panic.

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================