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
