Hey, As ACPI suspend-to-ram (S3) seems to work for more and more people as the kernel improves, I've written some code/scripts to make it work better out of the box as, ideally, this should be zero configuration, e.g., if it's supported, it should "Just Work". We're pretty far from that goal right now, we don't have an easy-to-edit configuration file (and we certainly shouldn't be relying users on being able to edit configuration files either), and suspend-to-ram just doesn't work on enough boxes to enable it per default. On http://people.redhat.com/davidz/suspend/ you should find SRPMs and i386 RPMS for vbetool-0.2 - Tool for run real-mode video BIOS code to alter hardware state powermgmt-001 - ACPI S3 suspend script, configuration file and lid event script for acpid hal-0.5.0.cvs20050312 - new version of hal to cope with whitelist data (see below) Out of the box, this does nothing, if you run /usr/sbin/suspend.sh (which is also invoked by acpid when the lid is closed) the following is printed: [root@daxter ~]# /usr/sbin/suspend.sh Checking whether system is whitelisted error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.can_suspend on device with id /org/freedesktop/Hal/devices/computer error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.suspend.method on device with id /org/freedesktop/Hal/devices/computer error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.suspend.vbetool_post on device with id /org/freedesktop/Hal/devices/computer error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.suspend.vbetool_dpms on device with id /org/freedesktop/Hal/devices/computer error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.suspend.modules on device with id /org/freedesktop/Hal/devices/computer Suspend enabled: No Using vbetool to POST on resume: No Using vbetool to turn off backlight: No Kernel modules to unload: (none) Suspend method: mem Suspend not enabled; Follow instructions in /etc/suspend.conf So, we need to configure this stuff in /etc/suspend.conf (Q: wait, didn't he just tell me users shouldn't edit config files? A: keep reading!). Open this file and change SUSPEND_ENABLED to "true" and also SUSPEND_GENERATE_HAL_FDI to "true". Now, save all your work (since your box may not come up!), cross your fingers and run /usr/sbin/suspend.sh again. Depending on your video card, you may need to set SUSPEND_VBETOOL_POST and/or SUSPEND_VBETOOL_DPMS to "true". You may also need to add kernel modules (lsmod is useful here) to SUSPEND_MODULES, e.g. SUSPEND_MODULES= "ehci_hcd uhci_hcd" depending on your box. When and if your system finally resumes you should see a blurb similar to this: Generating HAL device information file.. Generated HAL device information file for whitelist ==== BEGIN CUT ==== <?xml version="1.0" encoding="UTF-8"?> <!-- -*- xml -*- --> <!-- suggested name: 20-acpi-s3-IBM-2373HU6.fdi --> <deviceinfo version="0.2"> <device> <match key="power_management.acpi.linux.version" compare_ge="20050211"> <match key="system.kernel.version" compare_ge="2.6.11-1.1177_FC4"> <match key="smbios.system.manufacturer" string="IBM"> <match key="smbios.system.product" string="2373HU6"> <merge key="policy.acpi.linux.can_suspend" type="bool">true</merge> <merge key="policy.acpi.linux.suspend.method" type="string">mem</merge> </match> </match> </match> </match> </device> </deviceinfo> ==== END CUT ==== TODO: Prompt user to interactively submit this file to RH Bugzilla This is a hal device information file that should be submitted upstream so other users, that use the same hardware, can suspend out of the box too (<-- that's the answer to the Q above :->). As it should be evident from the XML, we match on - ACPI version must be as new as on the test box - kernel must be as new as on the test box - The manufacturer name (from dmidecode) - The product name (from dmidecode) and if this matches, we put the same values in the hal device information as the ones that worked in the /etc/suspend.conf file (If you study /usr/sbin/suspend.sh, you will see that this script queries HAL for these properties and replaces them if appropriate. (Ideally, we should have a mechanism for automatically allowing users to post this to our Bugzilla) So, for me, if I put the device information file that was given to me above (see attached for the file) in /etc/hal/fdi/information, reboot the box (I could restart services, sure, but it's easier to write "reboot the box"), then I've got suspend-on-lid working. No configuration, no command line, no config files. Out of the box. Similarly, if we ship these RPM's and this very device information file other users of instances of this particular version of IBM Thinkpad T41 would be easily well of. Or would they? Here are fairly difficult questions/issues: 1. I've assumed that "ACPI S3 sleep works" is tied to what kind of system it is; I use SMBIOS values (and the SMBIOS may lie!) as keys; are there better keys (such as `md5sum /proc/acpi/dsdt`) or is the assumption totally wrong? 2. I've assumed that there are no regressions in the kernel; e.g. if ACPI S3 sleep works in kernel X for a system Y then it also works in kernel Z for system Y given that Z >= X. I don't really know enough linux-acpi history if this is a good assumption? 3. vbetool is kind of evil; it's a workaround for broken video drivers and the mess that is X.org / kernel interaction wrt. to video hardware (so, vbetool becomes the 3th or 4th player directly touching hardware. Yay!). I expect we need to add radeontool at some point too. Also, for fun, go look at the /usr/sbin/suspend.sh script to see the wonderful hacks switching virtual terminals (most of these tricks are taken from looking at what other distros/ upstream scripts does) 4. ditto for rmmod; modules should never never be unloaded or so the core kernel guys says. 5. I've assumed that the list of modules to unload is also tied to the system, but isn't it more tied to the current kernel version? 6. Sometimes suspend fails for me because the mDNSResponder service wasn't stopped: Mar 13 01:33:32 daxter kernel: stopping tasks failed (1 tasks remaining) Mar 13 01:33:32 daxter kernel: Restarting tasks...<6> Strange, mDNSResponder not stopped Some of the other distro/upstream scripts have a list of services to stop. I've seen mysql there too. Euhw. 7. There is a TODO to shutdown networking completely as some network drivers refuse to be unloaded otherwise - even if the drivers were to be fixed we'd probably want this anyway in a NetworkManager world 8. This is a very first cut; in time all policy will be controlled from the desktop (thus respecting per-user policy / lock down etc.) - see http://live.gnome.org/ProjectUtopia_2fPowerManagement for details 9. Support for non-ACPI power-manegement, e.g. PMU for Apple hardware, should be easy to add along the way. In light of this: is it too dangerous, at this point, to enable this per default given we use the white lists as discussed above? Should we rather wait for the kernel/X.org to get fixed? (no, I'm not trolling here, I'm being serious actually) (and no, I'm not asking for hal device information files either just yet, so please don't send / bugzilla them) Cheers, David
Attachment:
20-acpi-s3-IBM-2373HU6.fdi
Description: application/extension-fdi
