STR working out of the box

[Warren Togami]

David Zeuthen wrote:
> 
>  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?

After the whitelist format stabilizes, upstream needs a database driven 
testing matrix of kernels versions, hardware, and tested drivers, and 
userspace stuff that interferes.  This kind of thing is the only way to 
spot trends to identify when regressions began (for LART targeting), 
which drivers seem to work, which hardware seems to work, which drivers 
need fixing, which userspace stuff needs fixing/workarounds.

A relatively simple XML-RPC-like reporting tool would make it possible 
to submit uniform and accurate data to such a database.

But I don't volunteer to organize this. =)

> 
>  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)

More ugly hacks...

/sbin/hwclock --systohc     /sbin/hwclock --hctosys

Would it be appropriate to include these pair of commands in the 
suspend.sh in order to avoid time clock screwage?

At least on my Thinkpad T41 it seems that the time clock goes twice as 
fast while suspended.  Don't know how many other machines are affected 
in this way.

> 
>  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.
> 
> 

Is it possible to stop mDNSResponder manually without uninstalling it? 
It seems that service mDNSResponder stop always fails, as does kill -9.

One more question...
suspend-checklid.sh assumes that all users *always* wants suspend if the 
LID is closed.  I am assuming this will eventually be configurable 
easily from the desktop, but will it default this way?

Warren Togami
wtogami at redhat.com