Re: [linux-pm] Re: Hibernate after alarm wakes from STR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux