linux-kernel - Re: [linux-pm] Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

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.0707140012290.25614@asgard.lang.hm>
Date:	Sat, 14 Jul 2007 00:13:59 -0700 (PDT)
From:	david@...g.hm
To:	Alan Stern <stern@...land.harvard.edu>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	Pavel Machek <pavel@....cz>,
	"Huang, Ying" <ying.huang@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-pm@...ts.linux-foundation.org,
	Jeremy Maitin-Shepard <jbms@....edu>
Subject: Re: [linux-pm] Re: [PATCH 0/2] Kexec jump: The first step to kexec
 base hibernation

On Fri, 13 Jul 2007, Alan Stern wrote:

> On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
>
>>> I missed this discussion. is this idea to suspend, write to disk, but
>>> leave things in ram so that if you wakeup soon enough you have everything
>>> for ram, but if you don't and the battery dies you can restore from disk?
>>>
>>> if so I think it's a mistake to mix the two. it would be better to just
>>> suspend to ram, and wake up once in a while to check the battery state and
>>> when the battery gets low enough do the suspend to disk.
>>>
>>> otherwise you end up mixing the requirements of the two types of suspend,
>>> which is how things got so ugly in the first place.
>>
>> Not necessarily.  If we don't put devices into low power states before creating
>> the image, that should work just fine (quiesce devices, create the image or
>> kexec the new kernel, reprobe devices, save the image, suspend to RAM,
>> resume from RAM, continue - or restore from the image if power failed in the
>> meantime).  Still, for this purpose, both kernels need to be able to handle the
>> same set of devices.
>
> Why?
>
> Suppose the kexec kernel can't handle some device.  The normal kernel
> has already quiesced the device, so it will remain quiescent while the
> kexec kernel runs and throughout the suspend.  When the regular kernel
> regains control the device will be ready for use.  I don't see any
> problem.

remember that during the hibernation the box may be powered off.

but there's still no reason for the hibernate kernel to know how to access 
the USB TV Tuner for example.

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/