Maxim Levitsky <maximlevitsky@gmail.com> writes:

quoted text
> First of all S4 ACPI code turns some leds on some systems,
> cosmetic thing, but still nice.
>
> Secondary, what about wakeup devices?
> Hardware can disable some devices in S5 while leave them running in S4
> on my system for example network card will do WOL in S4,
> but to make it WOL in S5 I have to turn a specific option in BIOS.
>
> While my system doesn't have this, it isn't uncommon for system to leave USB
> ports
> running so one can turn the PC with keyboard/mouse even in S4.
> in S5 those ports  will probably  be disabled.
> My system on have this for S3 only.
>
> On laptops we can expect even more ACPI functionality, so some more differences
> between
> S4 and S5 can happen.
>
> Last thing that I want to say is that, when linux puts PC in S? state, on top of
> executing
> _PTS, _GTS acpi functions, it writes the destination S state to a fixed
> register, thus the hardware
> can (and does) behave differently.

Yes.

S4 looks interesting.  Especially the weird fans don't work on restore
from S5 case.

S4 still appears to be a premature optimization, that ads lots of
complexity and reduces the reliability of the code.

Software hibernation to disk should be a rock solid proposition, that
needs little if any cooperation from drivers, and it should work on
every box, because fundamentally it is hardware agnostic.  The only
cooperation we need from drivers is for devices that we can't tolerate
at upper layers an unplug and replug event like block devices because
we would loose our filesystems.

All of the reports say hibernation is not rock solid reliable.
Things like S4 support keep us from being hardware agnostic.
Therefore it appears to me we have a design bug.

Which is why I'm not at all happy with S4 support.



It actually occurs to me that the first mode we should really support
is the mode where the user hits the power button themselves.  That
totally removes the hibernation path from any weird hardware
interactions.

Then S5 is an optimization upon that (just a little more work on the
shutdown path).

Then ultimately S4 reusing and refactoring the work for S3? suspend to
ram to allow us to leave very specific devices on.  But that is lot
of complexity, for a little bit of gain.

We should have code that works by design. Code that practically
every time.  Something that is easy to diagnose.


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