I ran into a very similar problem on stable/9.  During a reboot, the
system paniced because the watchdog slept when called from the syncer.
 I solved it by dropping the sync mutex in the syncer before patting
the watchdog.  It might be a more general solution that would also
solve your problem.  My patch and stack trace below.

Syncing disks, vnodes remaining...7 7 7 5 Sleeping thread (tid 100145,
pid 23) owns a non-sleepable lock
KDB: stack backtrace of thread 100145:
sched_switch() at 0xffffffff8091086d = sched_switch+0x13d
mi_switch() at 0xffffffff808ee276 = mi_switch+0x196
sleepq_wait() at 0xffffffff80929672 = sleepq_wait+0x42
_sleep() at 0xffffffff808eeae8 = _sleep+0x3a8
ipmi_submit_driver_request() at 0xffffffff80c0df6f =
ipmi_submit_driver_request+0xbf
ipmi_set_watchdog() at 0xffffffff80c0e571 = ipmi_set_watchdog+0xb1
ipmi_wd_event() at 0xffffffff80c0e6bf = ipmi_wd_event+0x8f
kern_do_pat() at 0xffffffff807d763f = kern_do_pat+0x9f
sched_sync() at 0xffffffff8098779f = sched_sync+0x1df
fork_exit() at 0xffffffff808b21af = fork_exit+0x11f
fork_trampoline() at 0xffffffff80bd9ebe = fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff88ce6a4bb0, rbp = 0 ---
panic: sleeping thread

==== //SpectraBSD/stable/sys/kern/vfs_subr.c#3 (text) ====

@@ -1869,8 +1869,15 @@
                 continue;
             }

-            if (first_printf == 0)
+            if (first_printf == 0) {
+                /*
+                 * Drop the sync mutex, because some watchdog
+                 * drivers need to sleep while patting
+                 */
+                mtx_unlock(&sync_mtx);
                 wdog_kern_pat(WD_LASTVAL);
+                mtx_lock(&sync_mtx);
+            }

         }
         if (!LIST_EMPTY(gslp)) {

On Tue, Sep 17, 2013 at 4:21 AM, Gleb Smirnoff <gleb...@freebsd.org> wrote:
>   Hi!
>
>   When system is writing a kernel core dump, it issues watchdog
> pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers
> ipmi_wd_event() as event for watchdog. Thus ipmi_wd_event() is
> called in dumping context.
>
> The problem is that ipmi_wd_event() calls into ipmi_set_watchdog(),
> that calls into ipmi_alloc_request(), which uses M_WAITOK and
> thus sleeps. This is a smaller problem, since can be converted to
> M_NOWAIT. But ipmi_set_watchdog() then calls into
> ipmi_submit_driver_request(), which calls msleep() any time.
>
>   The attached patch allows me to successfully write cores in
> presence of IPMI.
>
> --
> Totus tuus, Glebius.
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to