Date: Thu, 26 Jul 2012 17:50:38 -0700 From: Sean Bruno <seanbru@yahoo-inc.com> To: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: dell r420/r320 stable/9 Message-ID: <1343350238.12294.10.camel@powernoodle.corp.yahoo.com>
next in thread | raw e-mail | index | archive | help
For the time being I had to revert the following from my stable/9 tree. Otherwise I would get a kernel panic on shutdown from ipmi(4). http://svnweb.freebsd.org/base?view=revision&revision=237839 http://svnweb.freebsd.org/base?view=revision&revision=221121 I suspect that the ipmi device isn't detatching early or properly in this configuration, but I have only just now discovered these changesets as a clue to what's going on here. The panic looks like this when you see it: Sleeping thread (tid 100107, pid 9) owns a non-sleepable lock KDB: stack backtrace of thread 100107: sched_switch() at sched_switch+0x19f mi_switch() at mi_switch+0x208 sleepq_switch() at sleepq_switch+0xfc sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x3f6 ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97 ipmi_set_watchdog() at ipmi_set_watchdog+0xb1 ipmi_wd_event() at ipmi_wd_event+0xaa kern_do_pat() at kern_do_pat+0x10f sched_sync() at sched_sync+0x1ea fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff869b177bb0, rbp = 0 ---
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1343350238.12294.10.camel>