[...description of APM suspend-to-disk woes elided...]
> I may be totally wrong, but AFAIK the HP and IBM way to do it is to
> use the BIOS to dump stuff to a file on the FAT filesystem you're
> supposed to have as C: ;) Very DOS/Windows specific.
Well, there are 32-bit interfaces defined for the APM entry, and the new
APM 1.2 spec defines a separate 'hibernation partition' and id code (a0 on
my machine, but I think the standard is different).
This is much more general than the early HP/IBM hacks, and was
standardized particularly to allow multi-os/filesystem compatibility (not
even MS wants APM to write FAT information blindly -- they've recently
moved to FAT32, recall, and their 'evolutionary' product uses NTFS). You
*can* use the BIOS disk routines without trouble as long as you drop back
into a mode where they're accessible, and since the kernel's suspended and
all writes happen on their own happy partition, there *should* be no
problems. This is APM 1.2, mind you.
But some APM 1.2 BIOSes still die. I suspect something sneaky, like they
assume we've mapped the old BIOS routines at a certain location or
somesuch. We can workaround this if I can identify exactly what their
assumptions are. We conform to the spec, of course. But it's the
undocumented stuff that breaks systems.
[for more info, see the APM 1.2 spec; the URL is in the comments at the
head of linux/drivers/char/apm_bios.c]
C. Scott Ananian: firstname.lastname@example.org / Declare the Truth boldly and
Laboratory for Computer Science/Crypto / without hindrance.
Massachusetts Institute of Technology /META-PARRESIAS AKOLUTOS:Acts 28:31
-.-. .-.. .. ..-. ..-. --- .-. -.. ... -.-. --- - - .- -. .- -. .. .- -.
PGP key available via finger and from http://www.pdos.lcs.mit.edu/~cananian
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com