Date: Fri, 6 May 2011 16:48:01 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Zaphod Beeblebrox <zbeeble@gmail.com> Subject: Re: Intel "em" driver sleeps with non-sleepable lock. Message-ID: <201105061648.01646.jhb@freebsd.org> In-Reply-To: <BANLkTik6Jdz3J9bp6ihhZizOG4_GBGsSgQ@mail.gmail.com> References: <BANLkTik6Jdz3J9bp6ihhZizOG4_GBGsSgQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, May 05, 2011 2:11:39 pm Zaphod Beeblebrox wrote: > The motherboard in question is made by Intel and contains a Xeon 3440 > (4 core x 2 HT per core). 16 Gig of RAM is installed and we are > installing the 64 bit FreeBSD 8.2 using the PC-BSD installer (to > install zfs root faster). The motherboard has 4 "igb" ethernet and > one "em" ethernet. The "em" ethernet is shared with an internal > "RMM3" remote management card and/or the onboard ILOM. This error > happens when rebooting after installation and is repeatable with at > least FreeBSD 8.1 and FreeBSD 8.2. > > The last boot message is "Starting devd" ... so I assume that the > active link on em0 might be making devd start dhclient. After this > last boot message, the screen reads: > > Sleeping thread (tid 100195, pid 619) owns a non-sleepable lock > panic: sleeping thread > cpuid = 2 > KDB: stack backtrace: > #0 0xffffffff805f4e03 at kdb_backtrace+0x5e > #1 0xffffffff805c2d07 at panic+0x187 > #2 0xffffffff80601a5d at propagate_priority+0x1cd > #3 0xffffffff8060278a at turnstile_wait+0x1aa > #4 0xffffffff805b34c0 at _mtx_lock_sleep+0xb0 > #5 0xffffffff8032fd97 at em_init_locked+0xce7 > #6 0xffffffff80331b8e at em_ioctl+0x5fe > #7 0xffffffff80671114 at ifioctl+0x9e4 > #8 0xffffffff806043c2 at kern_ioctl+0x102 > #9 0xffffffff806045fd at ioctl+0xfd > #10 0xffffffffff80600dd5 at syscallenter+0x1e5 > #11 0xffffffffff808aca5b at syscall+0x4b > #12 0xffffffffff80895292 at Xfast_syscall+0xe2 You need to trace the thread that owns the lock (in this case 619). I thought the kernel automatically did that actually, but maybe it only does that if certain debugging options are enabled. If you can break into KDB and do 'tr 100195' that would be ideal. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201105061648.01646.jhb>