[Debian-eeepc-devel] Bug#603430: Bug#603430: eeepc-acpi-scripts: Suspend to RAM takes several minutes since switch to acpi-support

[Ben Armstrong]

On 13/11/10 10:19 PM, Ben Hutchings wrote:
> Well, first Axel should check that the kernel itself does the right
> thing:
> 
>     echo mem > /sys/power/state
> 
> I agree with Ben's judgement that eeepc-acpi-scripts should be
> minimised, though I would go further and say that ACPI quirks should
> generally be handled in the kernel.

Ben,

Thanks for that tip.

Oh. Ignore what I said about the quirk. That is gone from
eeepc-acpi-scripts 1.1.11.  It has been years since that quirk was
identified and has been handled in the kernel since some time ago.

Axel,

I have tested and re-tested with 1.1.11 on a model 701 and cannot
reproduce your results.  I'm using 2.6.32-27 (current version in
squeeze/sid).  I have tested both with and without gnome-power-manager
running.  In both cases, pm-suspend is handling the suspension just fine
with no delays.  Also, "echo mem > /sys/power/state" as Ben suggested
above works fine.

The ACPI implementation in the model 701 is pretty brain-dead and has
had to be worked around in the kernel since many versions ago. If you
generate enough of them at once*, it is still possible to have ACPI
events "pile up" and not be handled until much later because the
workaround is not perfect.  But that has nothing to do with whether
eeepc-acpi-scripts handles the events or acpi-support does.  It's just
one of those things you suffer with if you have this hardware.  And yes,
"don't do that" is the only way to deal with it.

Ben
* I tried very hard to make this happen on my 701 and couldn't. Before
the workaround was applied in the kernel (as I said, many versions ago)
the way I used to make this happen was to press and hold some Fn-key
like volume up/down or brightness up/down until a long enough stream of
events caused the kernel to choke.