freebsd stable - Jul 2012 - dell r420/r320 stable/9

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 ---

On Jul 26, 2012, at 8:50 PM, Sean Bruno wrote:
> 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
> 

On a somewhat related note: We noticed recently that you can't pet or
disable the IPMI hardware watchdog once SCHEDULER_STOPPED() is true.  This means
it can fire unexpectedly while you're dumping core or rebooting, depending
on how long the timeout was on the pet before the panic.  The ipmi driver will
need to process the command differently if the scheduler is stopped.  I
haven't had time to look at a fix yet.

-Andrew

--------------------------------------------------
Andrew Boyer	aboyer@averesystems.com