David Zeuthen (davidz@xxxxxxxxxx) said: > 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. These files will become rapidly obsolete as the kernel fixes bugs, drivers change names, etc. How do you handle updates and verifications? Do we push a new RPM every week? (As I've stated before, I think a whitelist is crack. :) ) > 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? It's tied to the system, kernel version, hardware type, and BIOS version. > 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? No. But it keeps the kernel people on their toes. > 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. Note that vbetool is only for certain cards. There are other tools for other cards. > 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? 'Version of the code in the modules, along with the PM layer.' > 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. Read apmscript. Cry at the horror. > 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) I'd just enable it without the whitelist, personally. Bill
