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.64.0707162137220.19248@asgard.lang.hm>
Date:	Mon, 16 Jul 2007 21:45:23 -0700 (PDT)
From:	david@...g.hm
To:	Alan Stern <stern@...land.harvard.edu>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Huang, Ying" <ying.huang@...el.com>,
	Jeremy Maitin-Shepard <jbms@....edu>,
	Kyle Moffett <mrmacman_g4@....com>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Pavel Machek <pavel@....cz>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Al Boldi <a1426z@...ab.com>
Subject: Re: Hibernation considerations

On Mon, 16 Jul 2007, Alan Stern wrote:

> On Sun, 15 Jul 2007 david@...g.hm wrote:
>
>> then we need a third mode of operation.
>>
>> mode 1: Suspend-to-ram
>>
>>    the system is paused and put into a low-power mode but data remains in
>> memory and the system stays awake enough to keep the memory refreshed.
>>
>> mode 2: new
>>
>>    the system is paused, data is stored to permanent media, and the system
>> is put into a ultra-low power mode.
>>
>> mode 3: hibernate
>>
>>    the system is paused, data is stored to permanent media, and the system
>> is powered off
>>
>> with mode 3 there are no requirements or limitations about what can be
>> done with the hardware before a resume (the resume could even take place
>> on a different piece of identical hardware)
>>
>> mode 2 could be what you are talking about doing, although I don't see any
>> advantage of creating it in additon to mode 3, it doesn't use any less
>> power and it locks the system so that it can't be used for anything else
>> in the meantime. I guess if it was significantly faster to do then mode 3
>> there may be _some_ reason to consider it, but I don't see the speed
>> difference.
>
> Part of the problem here is that ACPI already has its own terminology,
> and you're trying to invent a new one instead of using the existing
> one.
>
> I agree, it would be good to have a non-ACPI-specific hibernation mode,
> something which would look to ACPI like a normal shutdown.  But I'm not
> so sure this is possible.

why would it not be possible?

> You have to understand that the ACPI spec is weird and complex.  The
> mere fact that you have written a system image to disk changes the way
> ACPI regards the shutdown procedure.  Even though you may treat all the
> devices and the rest of the hardware exactly the same, it's a different
> operation as far as ACPI is concerned, with different requirements.
>
> Yes, it's bizarre.  Why do you think so many people have complained so
> vehemently about ACPI for all these years?

so let's act as if ACPI doesn't exist and make a suspend-to-disk that 
works without it and looks to ACPI like a complete power off/on cycle (but 
looks to the user like a suspend/resume cycle)

this should avoid all the headaches about ACPI completely becouse you just 
don't make any ACPI calls at all.

this will also work on any type of system, and it will work in the 
presence of dead batteries, failed components, booting other OS's, moveing 
the image to different hardware, etc.

I can't think of anything much more frustrating then thinking that I 
suspended a system and then discovering that becouse the battery went dead 
(a complete power loss) that the system wouldn't boot up properly. to me 
this would be a fairly common condition (when I'm mobile I use the machine 
until I am out of battery, then stop and it may be a long time (days) 
before I can charge the thing up again) this would not be a reliable 
suspend as far as I'm concerned.

for suspend-to-ram you have to worry about ACPI states and what you are 
doing with them, for suspend-to-disk you can ignore them and completely 
power the system off instead.

David Lang
-
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