Re: shutdown hooks at panic (was Re: CVS commit: src/sys/kern)

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Fri, Jan 18, 2008 at 11:39:29AM -0600, David Young wrote:
> Do the legacy shutdown hooks hang, or do the PMF suspend routines hang?

The PMF functions hang. But they do the same things as the original
shutdown calls, so I am not sure why this issue didn't appear earlier.
Heisenbug.

> Will you give examples of the drivers that do not implement polling
> correctly, so that people can fix them?

Hangs have been reported at least for atabus and ahd.

> You have also expressed the
> desire that shutdown does not run at splhigh(); perhaps it will be easier
> to fix the MD cpu_reboot() routines than to fix the drivers?

I would like to see cpu_reboot be split into three parts. The first part
is optional and allows MD to override the desired action. Some platforms
have special rules for rebooting, but many just honour what the user
requested. The second part can be MI and implements the sync,
coredumping and calling the shutdown handlers. The third part is the MD
logic for actually turning off / rebooting the machine.

> Do the
> drivers need to be fixed, regardless, so that kernel dumps will work?

Kernel dumps use a special entry point. At some point in the future the
dump routine should actually ensure that the device is powered up (it
doesn't do that yet). This is similar to ddb optionally resetting e.g.
vga(4) on enter.

> NetBSD should not reboot the system until it is in a state where the
> BIOS can bootstrap it without interference from bus masters, memory
> write-protect units, or device interrupts.  (What else?)  The reason being
> that, if the BIOS will test RAM, you do not want for write-protection
> to stop it; if the BIOS uses some RAM to store its text/data, you do not
> want for a bus master to clobber that RAM; and if the BIOS will activate
> interrupts, you do not want for there to be an interrupt storm.

Exactly for that reason I am normally running the suspend calls. On the
other hand, after a panic you don't know much of the state the system is
in. This will be even more important when more drivers use the modern
serialisation primitives, e.g. cv and mutexes. Even kernel threads are
already a problem. I don't think you can force a power cycle at least on
x86, which should be done after a panic.

Joerg