STR working out of the box

[Dave Jones]

On Sun, Mar 13, 2005 at 02:16:22AM -0500, 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?

Bwahahahaha! ACPI is sadly probably one of the worst areas of the
kernel wrt regressions. Every time a new point release comes out
it's a case of 'some bugs got fixed, a bunch of new ones appeared'.
Unfortunatly, I don't see any way forward without making the same
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.

One day when the kernel does proper arbitration for the video
resources hopefully we won't need this, but that's way way off
in the future.

 >  4. ditto for rmmod; modules should never never be unloaded or
 >     so the core kernel guys says.

Well.. that depends.  There's no excuse for buggy modules, and
where bugs are found, we should fix them.
A lot of the issues like "I need to rmmod foo before I suspend"
are possibly just drivers lacking suspend/resume methods to
save/restore state.

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

Very likely. Annoyingly, upstream have this habit of renaming modules
gratuitously every so often.

 >  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

All network drivers should be rmmod'able, even if the interface
is up. (It sometimes does crazy things though, like immediately
reloading the module and firing up dhclient)

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

There are *lots* of 'suspend broke' bugs in bugzilla against the kernel.
As no-one has been doing any work on this aside from upstream (and even there
it's not really a priority, as the ACPI folks are buried alive in fixing
ACPI bugs related to configuration issues, and everyone else seems to
think swsusp is the best thing since sliced bread).

I'll warn you now, that there will be kernel bugs. Whether anyone
gets to fixing them in any short amount of time is something that
I wouldn't like to place odds on.  I'd love it if suspend/resume
worked on more systems, however it's something of a black art
chasing down problems related to this issue. My laptop for instance
suspends just fine. Resume however looks just like I powered it on
for the first time. I've written this off as 'BIOS bug', and don't
ever expect it to work. Some of our users however won't see things
the same way because "Windows works fine".

		Dave