On Tuesday, 18 of March 2008, Eric W. Biederman wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > > On Friday, 14 of March 2008, Eric W. Biederman wrote: > > > >> > Still, it would be sufficient if we disconnected the drivers from the > > hardware > >> > and thus prevented applications from accessing that hardware. > >> > >> My gut feeling is that except for a handful of drivers we could even > >> get away with simply implementing hot unplug and hot replug. Disks > >> are the big exception here. > >> > >> Which suggests to me that it is at least possible that the methods we > >> want for a kexec jump hibernation may be different from an in-kernel > >> hibernation and quite possibly are easier to implement. > > > > I'm not sure about the "easier" part, quite frankly. Also, with our current > > ordering of code the in-kernel hibernation will need the same callbacks > > as the kexec-based thing. However, with the in-kernel approach we can > > attempt (in the future) to be more ACPI compliant, so to speak, but with the > > kexec-based approach that won't be possible. > > > > Whether it's a good idea to follow ACPI, as far as hibernation is > > concerned, is > > a separate question, but IMO we won't be able to answer it without _lots_ of > > testing on vaious BIOS/firmware configurations. Our experience so far > > indicates that at least some BIOSes expect us to follow ACPI and misbehave > > otherwise, so for those systems there should be an "ACPI way" available. > > [Others just don't work well if we try to follow ACPI and those may be > > handled > > using the kexec-based approach, but that doesn't mean that we can just > > ignore > > the ACPI compliance issue, at least for now.] > > If we do use the ACPI S4 state I completely agree we should be at > least spec compliant in how we use it. > > I took a quick skim through my copy of the ACPI spec so I could get a > feel for this issue. Hibernation maps to the ACPI S4 state. The only > thing we appear to gain from S4 is the ability to tell the BIOS (so it > can tell a bootloader) that this was a hibernation power off instead > of simply a software power off. > > It looks like entering the ACPI S4 state has a few advantages with > respect to how the system wakes up. In general using the ACPI S5 > state (soft off) appears simpler, and potentially more reliable. > > The sequence we appear to want is: > - Disconnecting drivers from devices. > - Saving the image. > - Placing the system in a low power or off state. > > - Coming out of the low power state. > - Restoring the image. > - Reconnecting drivers to devices. > (We must assume the device state could have changed here > no matter what we do) > > It is mostly a matter of where we place the code. > > Right now I don't see a limitation either with a kexec based approach > or without one. Especially since the common case would be using > the same kernel with the same drivers both before and after the > hibernation event. > > The low power states for S4 seem to be just so that we can > decide which devices have enough life that they can wake up > the system. If we handle all of that as a second pass after > we have the system in a state where we have saved it we should > be in good shape. > > My inclination is to just use S5 (soft off). > > One of the cool things about hibernation to disk was that we were > supposed to get the BIOS totally out of that path so we could get > something that was rock solid and reliable. I don't see why we should > use ACPI S4 when the BIOS doesn't seem to give us anything useful, and > causes us headaches we should even consider using S4. > > Does using the S4 state have advantages that I currently do not > see? > > Len? Rafael? Anyone?
Well, I've been saying that for I-don't-remember-how-long: on my box, if you use S5 instead of entering S4, the fan doesn't work correctly after the resume. Plain and simple. Perhaps there's a problem with our ACPI drivers that causes this to happen, but I have no idea what that can be at the moment. Thanks, Rafael _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
