STR working out of the box
David Zeuthen
davidz at redhat.com
Sun Mar 13 07:16:22 UTC 2005
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20-acpi-s3-IBM-2373HU6.fdi
Type: application/x-extension-fdi
Size: 680 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20050313/0a21b813/attachment.bin>
More information about the Fedora-maintainers
mailing list