On Friday, 4 May 2007 16:57, Alan Stern wrote: > On Fri, 4 May 2007, Pavel Machek wrote: > > > Hi! > > > > > > > Well... the powerdown during hibernation... does not have _anything_ > > > > > to do with snapshot/restore. It is really a very deep sleep; similar > > > > > to soft powerdown, but not quite. > > > > > > Is this really a good idea? > > > > We have no other choice. ACPI spec says we should use S4. > > I haven't checked the spec, but I find it hard to believe. What could > possibly be wrong with using S5? It works just fine for normal poweroff, > with no wakeup devices enabled. Provided you don't enable the wakeup > devices during hibernation, why not use S5? I think the problem is the "reinitialize from scratch after the resume" part. If we're waking up from the hibernation, device drivers should reinitialize their devices, but if we're waking up from a suspend (eg. s2ram), it would be wrong to reinitialize, for example, the ACPI subsystem from scratch. Now, the problem is that the drivers (including ACPI drivers) cannot tell whether the resume is from hibernation or from suspend so they try to do something "generic". This may lead to having the system not fully functional after the resume from hibernation if we don't tell the ACPI BIOS that we're hibernating (by entering the S4 state instead of S5). > > Unfortunately if we do normal powerdown, we'll confuse ACPI BIOS. > > We do normal powerdown whenever someone shuts off his computer without > hibernating. I haven't noticed any ACPI BIOS confusion from that... In fact, I think, the BIOS isn't confused, but it may preserve some state information that the OS can use later on. By entering S4 we tell the BIOS to tell the "next" kernel that we've hibernated and to preserve some configuration information for it. If this information is not present, our own ACPI drivers get confised during the resume. To prevent this from happening, we need a separate set of hibernation callbacks in device drivers. Greetings, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm