STR working out of the box

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Users]     [Fedora Development]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux