re: pmf(9) clarifications

[matthew green <mrg%eterna.com.au@localhost>]

> > documentation does not mention this, but it seems that shutting down
> > cleanly might involve a flush of some kind. (I see that
> > pmf_system_suspend() does flush disk caches specifically before the
> > suspend, which sidesteps the issue a little)
> 
> I think the idea is that by the time pmf_system_suspend() calls
> do_sys_sync(), no more buffers can be queued on the filesystems, and
> after do_sys_sync(); bus_syncwait(), no more buffers can be queued on
> the drivers except by pseudo-disks such as cgd, dk, and raid.  Disk
> drivers will ordinarily stop servicing their buffer queue and will order
> the hardware to flush its cache.

i recently fixed a bug in amd64 shutdown that was exactly like this.

  http://mail-index.netbsd.org/source-changes/2012/03/03/msg032480.html

there is too much done in cpu_reboot() (in all just over 100 copies,
i think) currently, but right now it should be OK for x86.  i've been
meaning to audit the rest of them.

there's still a bug in sd@umass and XS_CLT_POLL for the case i was
hitting, the above change does not fix it (that has to do with the
usb code doing too much in a softint(9) handler, and eventually
trying to sleep on a cv -- quite illegal) but it does not come to
pass anymore.


.mrg.