>>>>> "fc" == Florian Cramer <cantsin@zedat.fu-berlin.de> writes:

    fc> Hi, I probably was the one who first report "sync" as a
    fc> workaround 

interesting.

On a tangent, suspend really needs to imply sync to DTRT.  The Unix
way is that dirty buffers will get committed to stable storage a few
minutes after the user program writes to the file.  There's no way of
knowing how long the machine will be suspended, so the buffers need to
get written before the uspend.

I think maybe suspend is tken too flippantly so far.  Another problem
I had was sometimes a MicroDrive would be locked spinning during the
whole suspend, rather than spinning down after a few seconds like
usual.  Presumably the suspend occurred in the middle of sending some
command to the drive or something.  Many device drivers will have
latency requirements and timeouts and such that matter in wall time,
and such drivers need to make sure these devices are idling rather
than in one of these locked states that they're supposed to be taken
out of within some small latency before the suspend goes through.

Then there is the insertion and especially the removal of detachable
devices like PC Card, USB, FireWire, ADB, SCSI :' during suspend,
which shows that some of this suspend-related stuff is MI.  IIRC this
is one of those things that used to crash my machine.  Ultimately it'd
be nice to have a softweare hibernation feechur like Solaris and Win2k
except one which would actually work.  This would clean up traditional
suspend-to-RAM if it worked, because all state would be constrained to
the memory image (which could _optionally_ be written to disk for a
real hibenation)---while now there is state in all these little
attached devices like the video controller and such, so you get things
like the z50 bars problem.

One problem with this abstract MI hibernation concept is, like i said
before, removable devices.  Usually we know a removable device is the
same one we had before because we keep our finger on it constantly,
and analagously userland and filesystems and such is assured that if
it keeps a device inode open, it will always be the same
device---names are recycled only if nobody references the device, or
if all the references are force-closed because of an unexpected
removal or something.  but if we hibernate we have to let go of it in
the kernel, take our finger off itl.  When we reboot, how do we know
this is the same wd0 we had before, so we can keep the
fixed-identity-of-open-devices promise to the userland and
filesystems?

You can often power-cycle a SCSI disk without upsetting NetBSD too
much.  It'd be nice if jiggling the USB cable on my external hard
drive didn't crash the machine, all suspending business aside.  There
are a variety of ways to cultivate the ability to make such a
distinction, tricks for guessing, u.s.w., but right now there's no
clear thinking on this stuff built into the
detachable-device-mataphor.

Anyway it's a tangent, but I just wanted to point out that (1) our
suspend stuff totally sucks, and (2) many of the problems with it are
MI.