>Number:         33353
>Category:       port-i386
>Synopsis:       apm_thread spins forever after panic reboot
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 24 23:00:00 +0000 2006
>Originator:     Jed Davis
>Release:        NetBSD 3.0
>Organization:
PANIX Public Access Internet and UNIX, NYC
>Environment:
System: NetBSD l2mail1.panix.com 3.0 NetBSD 3.0 (PANIX-STD) #0: Wed Mar 22 04:49:11 EST 2006  root@trinity.nyc.access.net:/devel/netbsd/3.0/src/sys/arch/i386/compile/PANIX-STD i386
Architecture: i386
Machine: i386
>Description:

Sometimes, a host using APM will panic for whatever reason, with
ddb.onpanic=0, and get stuck trying to reboot, requiring manual
intervention.  When investigated with ddb, the system appears to be
spinning in apm_thread.  In particular, the call to tsleep returns
immediately, and nothing else save the occasional interrupt handler is
happening.

I notice a comment in ltsleep to the effect that, when the system is
shutting down, it won't actually put the calling thread to sleep, but
merely lower spl for a moment to let interrupts run, and then return.

For a kernel thread like apm_thread, this means (as I understand it)
that it can't be preempted to let anything else run, unless it exits.

>How-To-Repeat:

This doesn't always happen, but it's probably just a matter of the sleep
timeout happening to end while disks are synced, or similar.

>Fix:

Does apm_thread need to be running during sleep/reboot?  If not, it can
just test the appropriate flag and exit in that case.