panic with em(4) in current

[Jack Vogel]

Sorry all, this code was put in by someone making changes to the shared
code, odd however
that the panic was not seen in testing.

My wife had serious surgery today so I have been at the hospital all day, I
will get this
fixed first thing after the weekend.

Jack


On Fri, Dec 11, 2009 at 6:24 PM, Giorgos Keramidas <keramida at ceid.upatras.gr
> wrote:

> On Fri, 11 Dec 2009 11:29:45 -0600, Brooks Davis <brooks at freebsd.org>
> wrote:
> > On Fri, Dec 11, 2009 at 01:20:08AM +0300, pluknet wrote:
> >> 2009/12/11 Brooks Davis <brooks at one-eyed-alien.net>:
> >> > Something with the latest e1000 update in current causes a panic
> during
> >> > attach on my laptop. ?Rolling sys/dev/e1000 back to the previous
> version
> >> > fixes the problem. ?Here's the hand transcribed panic:
> >> >
> >> > panic: mtx_lock() of spin mutex &dev_spec->swflag_mutex @
> ../../../dev/e1000/e1000_ich8lan.c:651
> >> >
> >> > The back trace places me at: e1000_acquire_swflag_ich8lan()+0x30
> >>
> >> Hi, I see bug there:
> >> +#define E1000_MUTEX_INIT(mutex)         mtx_init((mutex), #mutex, \
> >> +                                        MTX_NETWORK_LOCK, \
> >> +                                        MTX_DEF | MTX_SPIN)
> >>
> >> mtx_init() first looks for MTX_SPIN flag and assign
> >> lock_class_mtx_spin class to mutex.
> >> Then mtx_lock() on spin mutex called.
> >
> > I can confirm that removing MTX_SPIN fixes the panic.  This is invalid
> > code because MTX_DEF and MTX_SPIN are exclusive flags.  Unfortunately,
> > MTX_DEF is 0x0 so there's no way to check for that error at runtime.
>
> FWIW, I see the same panic, and will be building a kernel without
> MTX_SPIN in a few minutes.
>
>