On Tuesday, 24 July 2007 16:00, Huang, Ying wrote:
> >From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
> >This is not the point. There are memory regions that you should not
> _restore_,
> >because that will cause harm.
> >
> >> On x86_64, there is another usage of nosave during processing E820
>
>From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
>This is not the point. There are memory regions that you should not
_restore_,
>because that will cause harm.
>
>> On x86_64, there is another usage of nosave during processing E820
>> memory map. But I don't know why the memory region other than
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
On Tuesday, 17 July 2007 14:48, Huang, Ying wrote:
On Tue, 2007-07-17 at 01:13 -0700, [EMAIL PROTECTED] wrote:
however, since the resume designed for ACPI won't work would the following
approach work
1. boot one kernel
2. setup a kexec the same wa
On Tuesday, 17 July 2007 14:48, Huang, Ying wrote:
> On Tue, 2007-07-17 at 01:13 -0700, [EMAIL PROTECTED] wrote:
> > however, since the resume designed for ACPI won't work would the following
> > approach work
> >
> > 1. boot one kernel
> > 2. setup a kexec the same way you would for hibernate
>
On Tue, 2007-07-17 at 01:13 -0700, [EMAIL PROTECTED] wrote:
> however, since the resume designed for ACPI won't work would the following
> approach work
>
> 1. boot one kernel
> 2. setup a kexec the same way you would for hibernate
> 3. kexec to the new kernel
> 4. overwrite the memory of the fir
On Tuesday, 17 July 2007 10:13, [EMAIL PROTECTED] wrote:
> Ying, as the kexec guru in this thread I have a question for you about how
> kexec works (and possibly where you are going with this)
>
> for the power-off hibernate with ACPI disabled the hibernation seems
> fairly straightforward (alth
On Tuesday, 17 July 2007 06:18, [EMAIL PROTECTED] wrote:
> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Monday, 16 July 2007 16:42, Huang, Ying wrote:
> >> On Mon, 2007-07-16 at 14:17 +0200, Rafael J. Wysocki wrote:
> is this a matter of running some test to find out, or is this a
Ying, as the kexec guru in this thread I have a question for you about how
kexec works (and possibly where you are going with this)
for the power-off hibernate with ACPI disabled the hibernation seems
fairly straightforward (although there are still some missing pieces)
however, since the res
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
On Monday, 16 July 2007 16:42, Huang, Ying wrote:
On Mon, 2007-07-16 at 14:17 +0200, Rafael J. Wysocki wrote:
is this a matter of running some test to find out, or is this a question
for the kexec implemantors?
Actually, I'd like someone to tell
On Monday, 16 July 2007 16:42, Huang, Ying wrote:
> On Mon, 2007-07-16 at 14:17 +0200, Rafael J. Wysocki wrote:
> > > is this a matter of running some test to find out, or is this a question
> > > for the kexec implemantors?
> >
> > Actually, I'd like someone to tell me. ;-)
> >
> > I've browse
On Mon, 2007-07-16 at 14:17 +0200, Rafael J. Wysocki wrote:
> > is this a matter of running some test to find out, or is this a question
> > for the kexec implemantors?
>
> Actually, I'd like someone to tell me. ;-)
>
> I've browsed the kexec code, but haven't found anything related to the devi
On Monday, 16 July 2007 01:22, [EMAIL PROTECTED] wrote:
> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Sunday, 15 July 2007 21:23, [EMAIL PROTECTED] wrote:
> >> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
> >>
> >> I think this is far more complicated then it needs to be.
> >>
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
On Sunday, 15 July 2007 21:33, [EMAIL PROTECTED] wrote:
On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
On Saturday, 14 July 2007 23:34, [EMAIL PROTECTED] wrote:
On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
On Saturday, 14 July 2007 09:51, [EMAI
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
On Sunday, 15 July 2007 21:23, [EMAIL PROTECTED] wrote:
On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
I think this is far more complicated then it needs to be.
it sounds like it should be possible to do the following
1. figure out what pages sho
On Sunday, 15 July 2007 21:33, [EMAIL PROTECTED] wrote:
> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Saturday, 14 July 2007 23:34, [EMAIL PROTECTED] wrote:
> >> On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
> >>
> >>> On Saturday, 14 July 2007 09:51, [EMAIL PROTECTED] wrote:
> On
On Sunday, 15 July 2007 21:23, [EMAIL PROTECTED] wrote:
> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
>
> I think this is far more complicated then it needs to be.
>
> it sounds like it should be possible to do the following
>
> 1. figure out what pages should be backed
On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
On Saturday, 14 July 2007 23:34, [EMAIL PROTECTED] wrote:
On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
On Saturday, 14 July 2007 09:51, [EMAIL PROTECTED] wrote:
On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
Ok, now we need a data channel from
On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
I think this is far more complicated then it needs to be.
it sounds like it should be possible to do the following
1. figure out what pages should be backed up (creating a data structure to
hold them)
That should be done after step 2, because the
On Sunday, 15 July 2007 11:30, Huang, Ying wrote:
> On Sat, 2007-07-14 at 21:16 +0200, Rafael J. Wysocki wrote:
> > > The devices should be quiesced and the state of devices should be saved
> > > in kexec_jump, before relocate_kernel is called. This needs the
> > > implementation of device hibernat
On Saturday, 14 July 2007 23:34, [EMAIL PROTECTED] wrote:
> On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Saturday, 14 July 2007 09:51, [EMAIL PROTECTED] wrote:
> >> On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
> >>
> Ok, now we need a data channel from the old kernel to the hiberna
On Saturday, 14 July 2007 23:13, [EMAIL PROTECTED] wrote:
> On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Saturday, 14 July 2007 22:34, [EMAIL PROTECTED] wrote:
> >> in the past, Rafael J. Wysocki wrote:
> >>
> >>> BTW, please read this message and tell me what you think:
> >>>
> >>> http
On Sat, 2007-07-14 at 21:16 +0200, Rafael J. Wysocki wrote:
> > The devices should be quiesced and the state of devices should be saved
> > in kexec_jump, before relocate_kernel is called. This needs the
> > implementation of device hibernating as you mentioned before.
>
> Hmm, at which point devi
On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
On Saturday, 14 July 2007 09:51, [EMAIL PROTECTED] wrote:
On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
Ok, now we need a data channel from the old kernel to the hibernate
kernel, to the restore kernel. and the messier the memory layout the
larger
On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
On Saturday, 14 July 2007 22:34, [EMAIL PROTECTED] wrote:
in the past, Rafael J. Wysocki wrote:
BTW, please read this message and tell me what you think:
http://lkml.org/lkml/2007/7/13/265
Greetings,
Rafael
since I've deleted this message h
On Saturday, 14 July 2007 22:34, [EMAIL PROTECTED] wrote:
> in the past, Rafael J. Wysocki wrote:
>
> > BTW, please read this message and tell me what you think:
> >
> > http://lkml.org/lkml/2007/7/13/265
> >
> > Greetings,
> > Rafael
> >
> >
> >
>
> since I've deleted this message here's the rel
in the past, Rafael J. Wysocki wrote:
BTW, please read this message and tell me what you think:
http://lkml.org/lkml/2007/7/13/265
Greetings,
Rafael
since I've deleted this message here's the relavent portion of it
Okay, I have thought it through and I think that, as an initial step, we
On Saturday, 14 July 2007 09:51, [EMAIL PROTECTED] wrote:
> On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
>
> >> Ok, now we need a data channel from the old kernel to the hibernate
> >> kernel, to the restore kernel. and the messier the memory layout the
> >> larger this data channel needs to be (
On Saturday, 14 July 2007 12:55, Huang, Ying wrote:
> On Sat, 2007-07-14 at 11:59 +0200, Rafael J. Wysocki wrote:
> > > Hibernating process:
> > >
> > > 1. Normal kernel running
> > > 2. Hibernating is triggered, sys_kexec_load is used to load
> > > hibernating kernel and initramfs into m
On Sat, 2007-07-14 at 11:59 +0200, Rafael J. Wysocki wrote:
> > Hibernating process:
> >
> > 1. Normal kernel running
> > 2. Hibernating is triggered, sys_kexec_load is used to load
> > hibernating kernel and initramfs into memory. Then
> > sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invo
On Saturday, 14 July 2007 07:48, Huang, Ying wrote:
> On Fri, 2007-07-13 at 10:43 -0600, Eric W. Biederman wrote:
> > > Why a assembly stub is necessary? Is it not sufficient that just
> > > continue to complete a normal boot (hot add the reset of memory) or load
> > > the hibernated kernel (hibern
On Saturday, 14 July 2007 10:33, [EMAIL PROTECTED] wrote:
> by the way, a data point on kernel sizes
>
> -rw-r--r-- 1 root root 864648 Jul 14 00:53 vmlinuz.2.6.22.1.hibernate
> -rw-r--r-- 1 root root 659496 Jul 14 01:17
> vmlinuz.2.6.22.1.hibernate.stripped
> -rw-r--r-- 1 root root 3948168 Jul
by the way, a data point on kernel sizes
-rw-r--r-- 1 root root 864648 Jul 14 00:53 vmlinuz.2.6.22.1.hibernate
-rw-r--r-- 1 root root 659496 Jul 14 01:17 vmlinuz.2.6.22.1.hibernate.stripped
-rw-r--r-- 1 root root 3948168 Jul 14 01:10 vmlinuz.2.6.22.1.running
the running one matches the config
On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
Ok, now we need a data channel from the old kernel to the hibernate
kernel, to the restore kernel. and the messier the memory layout the
larger this data channel needs to be (hmm, what's the status on the memory
defrag patches being proposed?) if thi
On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
remember release early, release often (with something that functions)
fo rthe current stage where we are trying to make things work don't worry
about packaging everything tight with initrd and re-useing partitions or
kernel images. once everything
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 fr
Huang, Ying wrote:
>
> Hibernating process:
>
> 1. Normal kernel running
> 2. Hibernating is triggered, sys_kexec_load is used to load
> hibernating kernel and initramfs into memory. Then
> sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
> 3. In sys_reboot, kexec_jump is called to s
On Fri, 2007-07-13 at 10:43 -0600, Eric W. Biederman wrote:
> > Why a assembly stub is necessary? Is it not sufficient that just
> > continue to complete a normal boot (hot add the reset of memory) or load
> > the hibernated kernel (hibernated image) and jump to it?
>
> I was thinking the assembly
On Friday, 13 July 2007 18:48, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > Okay, I have thought it through and I think that, as an initial step, we
> > can do
> > something like this:
>
> > - preload the image-saving kernel before hibernation
On Friday, 13 July 2007 20:15, Alan Stern wrote:
> On Fri, 13 Jul 2007, Eric W. Biederman wrote:
>
> > > I doubt that re-probing devices will work. The probe routine won't
> > > expect there to be any registered children, so it will try to
> > > re-register them.
> >
> > So really unregister t
On Friday, 13 July 2007 17:50, Alan Stern wrote:
> On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
>
> > Okay, I have thought it through and I think that, as an initial step, we
> > can do
> > something like this:
> >
> > - preload the image-saving kernel before hibernation
> > - in the hibernatio
On Fri, 13 Jul 2007, Eric W. Biederman wrote:
> > I doubt that re-probing devices will work. The probe routine won't
> > expect there to be any registered children, so it will try to
> > re-register them.
>
> So really unregister the children. All we really need to do is disassociate
> the dr
Alan Stern <[EMAIL PROTECTED]> writes:
> On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
>
>> Okay, I have thought it through and I think that, as an initial step, we can
> do
>> something like this:
>>
>> - preload the image-saving kernel before hibernation
>> - in the hibernation code path replac
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
[snip]
> Okay, I have thought it through and I think that, as an initial step, we can
> do
> something like this:
> - preload the image-saving kernel before hibernation
> - in the hibernation code path replace device_suspend() with the shutting do
"Huang, Ying" <[EMAIL PROTECTED]> writes:
> On Thu, 2007-07-12 at 10:32 -0600, Eric W. Biederman wrote:
>> >
>> > 1. Separate device suspend from device hibernate.
>>
>> Actually in some very practical sense we already have two copies of
>> this in the kernel. device_shutdown and the hotunplug/m
On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
> Okay, I have thought it through and I think that, as an initial step, we can
> do
> something like this:
>
> - preload the image-saving kernel before hibernation
> - in the hibernation code path replace device_suspend() with the shutting
> down of
On Friday, 13 July 2007 17:28, Al Boldi wrote:
> Rafael J. Wysocki wrote:
> > We have quite an efficient restoration code in the kernel right now. It's
> > able to upload big images (something like total RAM minus the size of the
> > boot kernel, initrd and, optionally, the resume application), wh
On Friday, 13 July 2007 17:12, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > 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
> > k
Rafael J. Wysocki wrote:
> On Friday, 13 July 2007 19:32, Huang, Ying wrote:
> > On Thu, 2007-07-12 at 20:06 -0700, [EMAIL PROTECTED] wrote:
> > > >> I agree, a stipped down hibernate kernel can be very small, not
> > > >> allocating this memory until it's needed is a step for the final
> > > >> po
Rafael J. Wysocki wrote:
> We have quite an efficient restoration code in the kernel right now. It's
> able to upload big images (something like total RAM minus the size of the
> boot kernel, initrd and, optionally, the resume application), which is
> much more than we're able to save. :-)
>
> It
On Friday, 13 July 2007 16:37, 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 b
On Thu, 2007-07-12 at 10:54 +0200, Pavel Machek wrote:
> > Sorry, I should have re-checked the mail before sending out.
>
> Were your patches enough to get hibernation working? I got kexec to
> work here, so I guess I'm one step closer...
Yes, it is just the first step. There are still many steps
On Thu, 2007-07-12 at 10:32 -0600, Eric W. Biederman wrote:
> >
> > 1. Separate device suspend from device hibernate.
>
> Actually in some very practical sense we already have two copies of
> this in the kernel. device_shutdown and the hotunplug/module
> remove code. So it is should be mostly a
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
[snip]
> 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,
> resu
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 thi
On Friday, 13 July 2007 19:32, Huang, Ying wrote:
> On Thu, 2007-07-12 at 20:06 -0700, [EMAIL PROTECTED] wrote:
> > >> I agree, a stipped down hibernate kernel can be very small, not
> > >> allocating
> > >> this memory until it's needed is a step for the final polishing.
> > >
> > > I'm not sure
On Friday, 13 July 2007 11:38, [EMAIL PROTECTED] wrote:
> On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Friday, 13 July 2007 05:06, [EMAIL PROTECTED] wrote:
> >> On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
> >>
> >>> On Thursday, 12 July 2007 20:57, [EMAIL PROTECTED] wrote:
> On Th
EMAIL PROTECTED]>,
> > "Huang, Ying" <[EMAIL PROTECTED]>,
> > Andrew Morton <[EMAIL PROTECTED]>, Pavel Machek <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED], linux-kernel@vger.kernel.org,
> > [EMAIL PROTECTED]
> > Subject: Re: [P
On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
On Friday, 13 July 2007 05:06, [EMAIL PROTECTED] wrote:
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 20:57, [EMAIL PROTECTED] wrote:
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
2. Do not reserve memory for kexec ker
On Thu, 2007-07-12 at 20:06 -0700, [EMAIL PROTECTED] wrote:
> >> I agree, a stipped down hibernate kernel can be very small, not allocating
> >> this memory until it's needed is a step for the final polishing.
> >
> > I'm not sure if I agree with that. In any case, having to use two different
> >
OTECTED]>, Pavel Machek <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], linux-kernel@vger.kernel.org,
[EMAIL PROTECTED]
Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
On Friday, 13 July 2007 05:12, [EMAIL PROTECTED] wrote:
On Thu, 12 Jul 2007, Jeremy Ma
On Friday, 13 July 2007 05:06, [EMAIL PROTECTED] wrote:
> On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Thursday, 12 July 2007 20:57, [EMAIL PROTECTED] wrote:
> >> On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
> >>
> 2. Do not reserve memory for kexec kernel. That is, backup needed m
On Friday, 13 July 2007 05:12, [EMAIL PROTECTED] wrote:
> On Thu, 12 Jul 2007, Jeremy Maitin-Shepard wrote:
>
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> >
> > [snip]
> >
> >> There's more to it, though. If devices are suspended, the hibernation
> >> kernel
> >> will have to resume the
On Thu, 12 Jul 2007, Jeremy Maitin-Shepard wrote:
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
[snip]
There's more to it, though. If devices are suspended, the hibernation kernel
will have to resume them (using platform, like ACPI, callbacks in the process)
instead and that will get compl
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 20:57, [EMAIL PROTECTED] wrote:
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
2. Do not reserve memory for kexec kernel. That is, backup needed memory
before kexec and restore them after kexec.
I don't think this is ver
Jeremy Maitin-Shepard wrote:
A typical usage pattern of hibernate on a laptop is to shut the lid,
causing the system to start to hibernate, and to place the machine in
All laptops we have here, and those of all people I have seen
with laptops, do suspend-to-RAM on lid-close, not hibernate.
An
Hi!
> > Looks interesting... but I was feeling strange dejavu reading
> > this... and that's because you pasted the changelog twice :-).
> >
>
> Sorry, I should have re-checked the mail before sending out.
Were your patches enough to get hibernation working? I got kexec to
work here, so I guess
On Thursday, 12 July 2007 21:55, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > There's more to it, though. If devices are suspended, the hibernation
> > kernel
> > will have to resume them (using platform, like ACPI, callbacks in the
> > proces
Mark Lord <[EMAIL PROTECTED]> writes:
[snip]
> Whoops.. wrong half of the script.
> For TuxOnIce in 10 seconds, it does this:
[snip]
I'd argue that for most usage patterns, it doesn't matter all that much
how long it takes to hibernate and power off the system. What really
matter is that it is
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
[snip]
> There's more to it, though. If devices are suspended, the hibernation kernel
> will have to resume them (using platform, like ACPI, callbacks in the process)
> instead and that will get complicated.
> It's better if devices are quiesced,
[EMAIL PROTECTED] writes:
> On Thu, 12 Jul 2007, Eric W. Biederman wrote:
>
>>> 2. Do not reserve memory for kexec kernel. That is, backup needed memory
>>> before kexec and restore them after kexec.
>>> 3. Support the in-place kexec? The relocatable kernel is not necessary
>>> if this can be impl
On Thursday, 12 July 2007 21:14, [EMAIL PROTECTED] wrote:
> 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
On Thursday, 12 July 2007 20:57, [EMAIL PROTECTED] wrote:
> On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
>
> >>> I didn't understand the ACPI problem. Does this mean that CONFIG_ACPI
> >>> must
> >>> be disabled in the to-be-hibernated kernel, or in the little transient
> >>> kexec kernel?
> >>
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
On Thu, 12 Jul 2007, Eric W. Biederman wrote:
2. Do not reserve memory for kexec kernel. That is, backup needed memory
before kexec and restore them after kexec.
3. Support the in-place kexec? The relocatable kernel is not necessary
if this can be implemented.
It sounds like what you really wa
On Thursday, 12 July 2007 20:42, [EMAIL PROTECTED] wrote:
> On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Thursday, 12 July 2007 08:43, [EMAIL PROTECTED] wrote:
> >> On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
> >>
> >>> Andrew Morton wrote:
> On Wed, 11 Jul 2007 15:30:31 +
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 12:10, [EMAIL PROTECTED] wrote:
On Thu, 12 Jul 2007, Huang, Ying wrote:
On Thu, 2007-07-12 at 00:03 -0700, [EMAIL PROTECTED] wrote:
The kexec jump is the first step, maybe the simplest step. There are
many other issues
On Thu, 12 Jul 2007, Mark Lord wrote:
[EMAIL PROTECTED] wrote:
actually, I think that while you may be able to get away with only one
kernel, you are probably better off with two. on the hibernate kernel you
can choose many 'embedded' options that don't make sense for the normal
kernel (no
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
I didn't understand the ACPI problem. Does this mean that CONFIG_ACPI must
be disabled in the to-be-hibernated kernel, or in the little transient
kexec kernel?
Under current implementation of device state quiescent/save/restore, the
CONFIG_ACPI mu
On Thu, 12 Jul 2007, Mark Lord wrote:
Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 08:43, [EMAIL PROTECTED] wrote:
> On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
>
> > Andrew Morton wrote:
..
> 8. hibernate kernel does syspend-to-ram to put the devices into a known
> safe state
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 08:43, [EMAIL PROTECTED] wrote:
On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
Andrew Morton wrote:
On Wed, 11 Jul 2007 15:30:31 +
"Huang, Ying" <[EMAIL PROTECTED]> wrote:
1. Boot a kernel A
2. Work under kern
I like the concept, but I completely disagree with your current
implementation.
I think it will be much easier if you start with a completely
independent code path and then just reuse the pieces of the
existing code path that you need.
More details below.
"Huang, Ying" <[EMAIL PROTECTED]> wri
Mark Lord wrote:
Rafael J. Wysocki wrote:
..
How much RAM is there in your machine?
2GB, but It doesn't need to dump that much for good performance.
Hibernate here consists of:
echo "$(( 256 * 1024 * 1024 ))" > /sys/power/image_size
echo -n disk > /sys/power/state
Plus a couple of fiddly
On Thu, 12 Jul 2007, Mark Lord wrote:
> Rafael J. Wysocki wrote:
> > On Thursday, 12 July 2007 08:43, [EMAIL PROTECTED] wrote:
> >> On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
> >>
> >>> Andrew Morton wrote:
> ..
> >> 8. hibernate kernel does syspend-to-ram to put the devices into a known
> >
Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 15:51, Mark Lord wrote:
..
Currently, TuxOnIce(suspend2) takes about 10 seconds to suspend my notebook.
Switching to this new scheme would double that to 10 seconds to boot/probe,
plus the original 10 seconds to hibernate. Assuming the new impl
On Thursday, 12 July 2007 15:51, Mark Lord wrote:
> Rafael J. Wysocki wrote:
> > On Thursday, 12 July 2007 08:43, [EMAIL PROTECTED] wrote:
> >> On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
> >>
> >>> Andrew Morton wrote:
> ..
> >> 8. hibernate kernel does syspend-to-ram to put the devices into a
Hi!
> And the complexity and difficulty of setup really scares
> me.
> Right now, we've got a pretty good/fast in-kernel (well,
> external patch)
> that allows my machines to hibernate very quickly, wake
> up even faster,
> and not swap like mad afterwards. Without any external
> programs,
>
Hi!
> >Maybe my usage of terminology has some problem. But,
> >the "device
> >hibernate" here means put device into quiescent state
> >and save the
> >device state, but do not put device into low power
> >state.
>
> is there really enough savings (in time or otherwise) to
> make it worth spli
[EMAIL PROTECTED] wrote:
actually, I think that while you may be able to get away with only one
kernel, you are probably better off with two. on the hibernate kernel
you can choose many 'embedded' options that don't make sense for the
normal kernel (no high mem, no SMP support, no SELinux, no
Rafael J. Wysocki wrote:
On Thursday, 12 July 2007 08:43, [EMAIL PROTECTED] wrote:
On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
Andrew Morton wrote:
..
8. hibernate kernel does syspend-to-ram to put the devices into a known
safe state.
Again, the devices should be quiesced rather then su
Rafael J. Wysocki wrote:
[snip]
>
> So if a user wants to install a kernel.org kernel on his system, (s)he'll have
> to compile and install two kernels with different options.
>
> That doesn't sound good to me. :-)
>
definitely. that sounds kind of strange, not to think of having to
remember wh
On Thursday, 12 July 2007 12:10, [EMAIL PROTECTED] wrote:
> On Thu, 12 Jul 2007, Huang, Ying wrote:
>
> > On Thu, 2007-07-12 at 00:03 -0700, [EMAIL PROTECTED] wrote:
> >>>
> >>> The kexec jump is the first step, maybe the simplest step. There are
> >>> many other issues to be resolved, at least th
On Thursday, 12 July 2007 16:43, Huang, Ying wrote:
> On Wed, 2007-07-11 at 17:22 -0700, Andrew Morton wrote:
> > This sounds awesome. Am I correct in expecting that ultimately the
> > existing hibernation implementation just goes away and we reuse (and hence
> > strengthen) the existing kexec (an
On Thursday, 12 July 2007 19:09, Huang, Ying wrote:
> On Wed, 2007-07-11 at 22:48 -0700, Jeremy Fitzhardinge wrote:
> > >> The kexec jump is implemented in the framework of software suspend. In
> > >> fact, the kexec based hibernation can be seen as just implementing the
> > >> image writing and re
On Thursday, 12 July 2007 08:43, [EMAIL PROTECTED] wrote:
> On Wed, 11 Jul 2007, Jeremy Fitzhardinge wrote:
>
> > Andrew Morton wrote:
> >> On Wed, 11 Jul 2007 15:30:31 +
> >> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
> >>
> >> > 1. Boot a kernel A
> >> > 2. Work under kernel A
> >> > 3.
On Thursday, 12 July 2007 02:22, Andrew Morton wrote:
> On Wed, 11 Jul 2007 15:30:31 +
> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>
> > Kexec base hibernation has some potential advantages over uswsusp and
> > suspend2. Some most obvious advantages are:
> >
> > 1. The hibernation image size c
On Thu, 12 Jul 2007, Huang, Ying wrote:
On Thu, 2007-07-12 at 00:03 -0700, [EMAIL PROTECTED] wrote:
The kexec jump is the first step, maybe the simplest step. There are
many other issues to be resolved, at least the following ones.
1. Separate device suspend from device hibernate.
Maybe m
On Thu, 2007-07-12 at 00:03 -0700, [EMAIL PROTECTED] wrote:
> >
> > The kexec jump is the first step, maybe the simplest step. There are
> > many other issues to be resolved, at least the following ones.
> >
> > 1. Separate device suspend from device hibernate.
>
Maybe my usage of terminology has
On Wed, 2007-07-11 at 22:48 -0700, Jeremy Fitzhardinge wrote:
> >> The kexec jump is implemented in the framework of software suspend. In
> >> fact, the kexec based hibernation can be seen as just implementing the
> >> image writing and reading method of software suspend with a kexeced
> >> Linux k
On Wed, 2007-07-11 at 13:13 +0200, Pavel Machek wrote:
> Hi!
>
> Looks interesting... but I was feeling strange dejavu reading
> this... and that's because you pasted the changelog twice :-).
>
Sorry, I should have re-checked the mail before sending out.
> How fast can kexec boot secondary kern
On Thu, 12 Jul 2007, Huang, Ying wrote:
On Wed, 2007-07-11 at 17:22 -0700, Andrew Morton wrote:
This sounds awesome. Am I correct in expecting that ultimately the
existing hibernation implementation just goes away and we reuse (and hence
strengthen) the existing kexec (and kdump?) infrastructu
1 - 100 of 106 matches
Mail list logo
