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]
Date:	Thu, 12 Jul 2007 12:14:20 -0700 (PDT)
From:	david@...g.hm
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Huang, Ying" <ying.huang@...el.com>, Pavel Machek <pavel@....cz>,
	nigel@...el.suspend2.net, Jeremy Maitin-Shepard <jbms@....edu>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:

>>>> note that what devices get put to sleep could be configurable, potentially
>>>> to the extreme of things like the OLPC (that have hardware designed for
>>>> cheap sleeping) going into a light suspend-to-ram state between keystrokes
>>>> if nothing else has a timer event scheduled before that.
>>>>
>>>> Suspend-do-disk (Hibernate) involves stopping the system, makeing a
>>>> snapshot of ram, writing the snapshot to somewhere and powering off the
>>>> box. on wakeup (power-on) a helper kernel boots, loads the snapshot into
>>>> ram and jumps to the kernel in the snapshot to resume operation.
>>>>
>>>> as I understand the proposal the thought is to do the following
>>>>
>>>> 1. system kernel does suspend-to-ram to put the devices into a known safe
>>>> state.
>>>
>>> Not necessarily suspend-to-RAM.  I'd much prefer it if devices were not put
>>> into low power states but quiesced (ie. no DMA, no interrupts).
>>
>> as I asked in another message, is it really worth having two (or more)
>> modes here?
>
> I think so.  The suspend-to-RAM mode is quite specific and on some platform
> (ie. ACPI) it requires platform support.
>
> We've already reached the conclusion that it's better to separate suspend from
> hibernation, as far as device drivers are concerned, and let's not repeat the
> discussion.

Ok, I seem to have been miscommunicating here. the old combined 
suspend/hibernate took everything to the hibernate state even if you only 
needed to suspend.

I was still seeing two diffent states involved

for suspend go to low-power mode

for hibernate go to low-power mode, kexec the new kernel, do your stuff, power off

note that this doesn't really matter as you have pointed out in other 
messages that we don't really want to put things in low-power mode, and 
Eric pointed out that kexec already handles disabling devices, so it 
sounds like this may be a solved problem if he's right and an issue to be 
solved differently if he's not.

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