Re: 2.6.0 swsusp

[Norman Diamond]

Pavel Machek replied to me:

> > 2.  When I forgot to say either "resume" or "noresume", the kernel detected
> > that it could not use the swap partition, but it did not offer the
> > possibility to resume.  Surely it could detect early enough that the swap
> > partition is not usable for swap but is usable for resume, and could ask the
> > user whether to do a "resume" or "noresume".
>
> At *that* point, it is no longer possible to resume safely.

Yes and no.  Junio C. Hamano explained the same thing to me, but he ALSO
explained a trick that he uses.  He ALWAYS tells the kernel to do a resume.
Then the kernel detects sufficiently early if a resume is really possible or
not.

Hmm, I guess I still see that if we wait for the kernel to mount / and read
/etc/fstab to find where the swap partition is then it will already be too
late to try resuming from the image in the swap partition.  But
theoretically it must be possible, because a certain famous monopoly
software maker can resume from an image stored in a FILE after starting its
boot sequence.

> > 3.  When swsusp completed its writing, it decided that my ACPI BIOS could
> > not power off automatically.  I wonder why.  No other OS has trouble
> > powering off this machine.  Also on machines with older APM BIOSes, no OS
> > had trouble powering off the machines, not even Linux with APM drivers.  So
> > I could hold the power switch for 4 seconds and the BIOS beeped a warning
> > before powering off, but I wonder why it was necessary.
>
> If regular halt is also unable to power off machine, fill the bug in
> ACPI bugzilla.

Exactly the opposite.  Regular halt works.  For some reason I hadn't tested
regular halt under Linux on this particular machine before first writing the
above (many reboots and suspends but not plain shutdowns).  But I tested a
regular halt later and it powered down automatically.  Only swsusp refuses
to power it down.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/