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. _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
