On Wednesday, 11 July 2007 12:14, Nigel Cunningham wrote: > Hi. > > On Wednesday 11 July 2007 20:09:04 Rafael J. Wysocki wrote: > > On Wednesday, 11 July 2007 05:14, Nigel Cunningham wrote: > > > On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote: > > > > On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote: > > > > > > > > > Yeah, that is a bit confusing. At the moment, I'm doing the suspend > > > > > to > ram > > > > > platform dependent preparation and cleanup in this scenario. That's > > > > > definitely the right thing to do in the case where we write an image, > then > > > > > suspend to ram, wake and continue working without running running out > of > > > > > battery (writing the image is redundant in that case). Where we end > > > > > up > > > > > properly powering down after suspending to ram, I believe we don't > > > > > run > the > > > > > pm_ops->finish after doing the atomic restore when resuming the image. > > > > > > > > I'm not convinced this can work terribly well. It's not unlikely that > > > > hardware will need different state stored over different types of > > > > suspend. Can you separate out the saving of kernel memory and userspace > > > > memory, then resume/suspend/save the new kernel state without touching > > > > the userspace state? > > > > > > Yeah, we could redo and resave the atomic copy, but it doesn't seem to be > > > necessary at the moment; it has been working reliably, regardless of > > > which > > > combination of events occurs. If/when I come across a case where we have > > > problems, I'll give resaving the atomic copy a go. > > > > > > (Thinks some more). Ah, I think we're already doing the right thing, if > I'm > > > recalling the order of actions right. If I'm remembering correctly, prior > to > > > the atomic copy, we do hibernation prep, then after the atomic copy, > > > hibernation cleanup. Then, if suspending to ram, we do the > prep/enter/cleanup > > > after the image has finished writing. If we lose power from suspend to > ram, > > > it doesn't matter because we're just doing a normal resume then, with the > > > hibernation cleanup post atomic restore machine the prep that was done > prior > > > to the atomic copy. > > > > > > To summarise: > > > > > > Hibernate + STR + full wake. > > > Hibernation prep > > > (Atomic copy) > > > Hibernation cleanup > > > STR prep > > > STR enter > > > STR cleanup > > > Remove hibernation image > > > > > > Hibernate + STR + poweroff + hibernate resume: > > > > > > Hibernation prep > > > (Atomic copy) > > > Hibernation cleanup > > > STR prep > > > STR enter > > > <power out> or <STR wake + power off> (STR prep/enter no longer matters) > > > (Fresh boot) > > > Atomic restore > > > Hibernation cleanup (matching prep at start) > > > Remove hibernation image > > > > Yes, I think that this is the right ordering, but for some graphics adapters > > we need to do some tricks from the user space before 'STR prep' and after > > 'STR cleanup', which is theoretically possible with uswsusp. > > Yeah. I haven't done it yet, but intend to implement that using userui.
I thought of a hibernation daemon that could communicate with the hibernation thread via sysfs/kevent or something like this. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
