panic with em(4) in current

[Brooks Davis]

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

The device in question is in my lenovo x61s laptop and the pciconf
output is:

em0@pci0:0:25:0: class=0x020000 card=0x20de17aa chip=0x10498086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Gigabit Network Connection Interface Controller (82566MM NIC)'
class = network
subclass = ethernet

Thanks,
Brooks

[pluknet]

2009/12/11 Brooks Davis <bro...@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.

>
> The device in question is in my lenovo x61s laptop and the pciconf
> output is:
>
> em0@pci0:0:25:0: � � � �class=0x020000 card=0x20de17aa chip=0x10498086 rev=0x03 hdr=0x00
> � �vendor � � = 'Intel Corporation'
> � �device � � = 'Gigabit Network Connection Interface Controller (82566MM NIC)'
> � �class � � �= network
> � �subclass � = ethernet
>
> Thanks,
> Brooks
>

--
wbr,
pluknet
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Brooks Davis]

On Fri, Dec 11, 2009 at 01:20:08AM +0300, pluknet wrote:
> 2009/12/11 Brooks Davis <bro...@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.

If a spin mutex were actually needed here then the _LOCK and _UNLOCK
macros need to be change and the unused _TRYLOCK macro needs to be
removed.

-- Brooks

[Giorgos Keramidas]

On Fri, 11 Dec 2009 11:29:45 -0600, Brooks Davis <bro...@freebsd.org> wrote:
> On Fri, Dec 11, 2009 at 01:20:08AM +0300, pluknet wrote:
>> 2009/12/11 Brooks Davis <bro...@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.

[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

[Giorgos Keramidas]

On Fri, 11 Dec 2009 18:42:57 -0800, Jack Vogel <jfv...@gmail.com> wrote:
> 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.

No worries. I have locally patched e1000 and I will be testing em(4)
without MTX_SPIN in a few. Please take your time, and my wishes for a
speedy & full recovery to your wife.