lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0709211540100.5816-100000@iolanthe.rowland.org>
Date:	Fri, 21 Sep 2007 15:45:06 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Jeremy Maitin-Shepard <jbms@....edu>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	<nigel@...pend2.net>,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Huang, Ying" <ying.huang@...el.com>,
	<linux-pm@...ts.linux-foundation.org>,
	huang ying <huang.ying.caritas@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3:
 kexec jump

On Fri, 21 Sep 2007, Rafael J. Wysocki wrote:

> > > Well, the problem is that apparently some systems (eg. my HP nx6325) expect us
> > > to execute the _PTS ACPI global control method before creating the image _and_
> > > to execute acpi_enter_sleep_state(ACPI_STATE_S4) in order to finally put the
> > > system into the sleep state.  In particular, on nx6325, if we don't do that,
> > > then after the restore the status of the AC power will not be reported
> > > correctly (and if you replace the battery while in the sleep state, the
> > > battery status will not be updated correctly after the restore).  Similar
> > > issues have been reported for other machines.
> > 
> > Suppose that instead of using ACPI S4 state at all, you instead just
> > power off.  Yes, you'll lose wakeup event functionality, and flashy
> > LEDs, but doesn't this take care of the problem?
> 
> Nope.
> 
> > The firmware shouldn't see the hibernate as anything other than a shutdown
> > and reboot.
> 
> Actually, this assumption is apparently wrong.

One gets the impression that the hibernation image includes a memory 
area used by the firmware.  That could explain why devices need to be 
in a low-power state when the image is created -- so that when the 
image is restored, the firmware doesn't get confused about the device 
states.

It would also explain why the firmware sees
resume-from-power-off-hibernation as different from a regular reboot:
because its data area gets overwritten as part of the resume.

In reality it's probably more complicated than this, with weird 
interactions between the firmware and the various ACPI methods.  
Nevertheless, the main idea seems valid.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ