Re: [patch 7/7] Add documentation for extended crashkernel syntax
* Pavel Machek <[EMAIL PROTECTED]> [2007-09-18 19:21]: > > This adds the documentation for the extended crashkernel syntax into > > Documentation/kdump/kdump.txt. > > Should you also update kernel-parameters.txt? Ok, I'll do. > > +For example: > > + > > +crashkernel=512M-2G:64M,2G-:128M > > + > > +This would mean: > > + > > +1) if the RAM is smaller than 512M, then don't reserve anything > > + (this is the "rescue" case) > > +2) if the RAM size is between 512M and 2G, then reserve 64M > > +3) if the RAM size is larger than 2G, then reserve 128M > > Why is this useful? I mean... if 64M is enough to save a dump, why use > 128M? ...or does the required size somehow scale with memory in > machine? (pagetables?) A bit, yes (ELF core headers, DISCONT memory, per-CPU data), but consider also that saving may be faster if you have more RAM (e.g. saving over SSH, encryption, ...). Thanks, Bernhard ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
huang ying wrote: > On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: > >>> Usage: >>> >>> 1. Compile kernel with following options selected: >>> >>> CONFIG_X86_32=y >>> CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with >>> it >>> CONFIG_KEXEC=y >>> CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory >>> image >>> CONFIG_PM=y >>> CONFIG_KEXEC_JUMP=y >>> >>> 2. Download the kexec-tools-testing git tree, apply the kexec-tools >>>kjump patches (or download the source tar ball directly) and >>>compile. >>> >>> 3. Download and compile the krestore tool. >>> >>> 4. Prepare 2 root partition used by kernel A and kernel B/C, referred >>>as /dev/hda, /dev/hdb in following text. This is not strictly >>>necessary, I use this scheme for testing during development. >>> >>> 5. Boot kernel compiled for normal usage (kernal A). >>> >>> 6. Load kernel compiled for hibernating/restore usage (kernel B) with >>>kexec, the same kernel as that of 5 can be used if >>>CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. >>> >>>The --elf64-core-headers should be specified in command line of >>>kexec, because only the 64bit ELF is supported by krestore tool. >>> >>>For example, the shell command line can be as follow: >>> >>>kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff >>>--elf64-core-headers --append="root=/dev/hdb single" >>> >>> 7. Jump to the hibernating kernel (kernel B) with following shell >>>command line: >>> >>>kexec -j >>> >>> 8. In the hibernating kernel (kernel B), the memory image of >>>hibernated kernel (kernel A) can be saved as follow: >>> >>>cp /proc/vmcore . >>>cp /sys/kernel/kexec_jump_back_entry . >>> >>> >> Here we save also kernel B's pages. >> > > No, the kernel B's pages will not be saved. Because when we build the > elfcore (/proc/vmcore) header, we exclude memory area used by kernel > B. The details can be found in kexec-tools patches. > > Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in order not to allocate pages found also in A's space? Or does does the --mem-min and --mem-max do that also? Thanks, Mika ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
huang ying wrote: > On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: > >> huang ying wrote: >> >>> On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: >>> >>> > Usage: > > 1. Compile kernel with following options selected: > > CONFIG_X86_32=y > CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient > with it > CONFIG_KEXEC=y > CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore > memory image > CONFIG_PM=y > CONFIG_KEXEC_JUMP=y > > 2. Download the kexec-tools-testing git tree, apply the kexec-tools >kjump patches (or download the source tar ball directly) and >compile. > > 3. Download and compile the krestore tool. > > 4. Prepare 2 root partition used by kernel A and kernel B/C, referred >as /dev/hda, /dev/hdb in following text. This is not strictly >necessary, I use this scheme for testing during development. > > 5. Boot kernel compiled for normal usage (kernal A). > > 6. Load kernel compiled for hibernating/restore usage (kernel B) with >kexec, the same kernel as that of 5 can be used if >CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. > >The --elf64-core-headers should be specified in command line of >kexec, because only the 64bit ELF is supported by krestore tool. > >For example, the shell command line can be as follow: > >kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff >--elf64-core-headers --append="root=/dev/hdb single" > > 7. Jump to the hibernating kernel (kernel B) with following shell >command line: > >kexec -j > > 8. In the hibernating kernel (kernel B), the memory image of >hibernated kernel (kernel A) can be saved as follow: > >cp /proc/vmcore . >cp /sys/kernel/kexec_jump_back_entry . > > > Here we save also kernel B's pages. >>> No, the kernel B's pages will not be saved. Because when we build the >>> elfcore (/proc/vmcore) header, we exclude memory area used by kernel >>> B. The details can be found in kexec-tools patches. >>> >>> >>> >> Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in >> order not to allocate pages found also in A's space? Or does does the >> --mem-min and --mem-max do that also? >> > > That is what "memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED]" for. The > contents of e820 memmap will be overrided when these kernel parameters > are specified. > > Best Regards, > Huang Ying > Yes, you just didn't specify exactmap for kernel B in your instructions, but only for C. But it is also required for kernel B then? Thanks, Mika ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: >> The ACPI platform firmware is allowed to preserve information >> accross the hibernation-resume cycle, so this need not be the same. > > All of my comments related to the case where S4 is not being used > (instead the system is just powered off normally), and a boot > kernel that does not initialize ACPI is used. In that case, the > ACPI platform firmware should not be able to distinguish a normal > boot from a resume from hibernation. I think that in order for this to work, there would need to be some ABI whereby the resume-ing kernel can pass its entire ACPI state and a bunch of other ACPI-related device details to the resume-ed kernel, which I believe it does not do at the moment. I believe that what causes problems is the ACPI state data that the kernel stores is *different* between identical sequential boots, especially when you add/remove/replace batteries, AC, etc. Since we currently throw away most of that in-kernel ACPI interpreter state data when we load the to-be-resumed image and replace it with the state from the previous boot it looks to the ACPI code and firmware like our system's hardware magically changed behind its back. The result is that the ACPI and firmware code is justifiably confused (although probably it should be more idempotent to begin with). There's 2 potential solutions: 1) Formalize and copy a *lot* of ACPI state from the resume-ing kernel to the resume-ed kernel. 2) Properly call the ACPI S4 methods in the proper order Neither one is particularly easy or particularly pleasant, especially given all the vendor bugs in this general area. Theoretically we should be able to do both, since one will be more reliable than the other on different systems depending on what kinds of firmware bugs they have. Cheers, Kyle Moffett ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > On Friday, 21 September 2007 15:14, huang ying wrote: > > On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > > > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > [--snip--] > > > > > > > > No one has yet attacked the hard problem of coming up with separate > > > > hibernate methods for drivers. > > > > > > Well, I've been playing a bit with that for some time, but it's not easy > > > by any > > > means. > > > > > > In short, I'm seeing some problems related to the handling of ACPI that > > > seem to > > > shatter the entire idea of having separate hibernate methods, at least as > > > far > > > as ACPI systems are concerned. > > > > So sadly to hear this. Can you details it a little? Or a link? > > 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. > > Now, the ACPI specification requires us to put devices into low power states > before executing _PTS and that's exactly what we're doing before a suspend to > RAM. Thus, it seems that in general we need to do the same for hibernation on > ACPI systems. Then, is it possible to separate device quiesce from device suspend. Perhaps not for swsusp, but for kexec based hibernation? Best Regards, Huang Ying ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 15:14, huang ying wrote: > On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > > > Nigel Cunningham <[EMAIL PROTECTED]> writes: [--snip--] > > > > > > No one has yet attacked the hard problem of coming up with separate > > > hibernate methods for drivers. > > > > Well, I've been playing a bit with that for some time, but it's not easy by > > any > > means. > > > > In short, I'm seeing some problems related to the handling of ACPI that > > seem to > > shatter the entire idea of having separate hibernate methods, at least as > > far > > as ACPI systems are concerned. > > So sadly to hear this. Can you details it a little? Or a link? 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. Now, the ACPI specification requires us to put devices into low power states before executing _PTS and that's exactly what we're doing before a suspend to RAM. Thus, it seems that in general we need to do the same for hibernation on ACPI systems. Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: > > > Usage: > > > > 1. Compile kernel with following options selected: > > > > CONFIG_X86_32=y > > CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with > > it > > CONFIG_KEXEC=y > > CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory > > image > > CONFIG_PM=y > > CONFIG_KEXEC_JUMP=y > > > > 2. Download the kexec-tools-testing git tree, apply the kexec-tools > >kjump patches (or download the source tar ball directly) and > >compile. > > > > 3. Download and compile the krestore tool. > > > > 4. Prepare 2 root partition used by kernel A and kernel B/C, referred > >as /dev/hda, /dev/hdb in following text. This is not strictly > >necessary, I use this scheme for testing during development. > > > > 5. Boot kernel compiled for normal usage (kernal A). > > > > 6. Load kernel compiled for hibernating/restore usage (kernel B) with > >kexec, the same kernel as that of 5 can be used if > >CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. > > > >The --elf64-core-headers should be specified in command line of > >kexec, because only the 64bit ELF is supported by krestore tool. > > > >For example, the shell command line can be as follow: > > > >kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff > >--elf64-core-headers --append="root=/dev/hdb single" > > > > 7. Jump to the hibernating kernel (kernel B) with following shell > >command line: > > > >kexec -j > > > > 8. In the hibernating kernel (kernel B), the memory image of > >hibernated kernel (kernel A) can be saved as follow: > > > >cp /proc/vmcore . > >cp /sys/kernel/kexec_jump_back_entry . > > > Here we save also kernel B's pages. No, the kernel B's pages will not be saved. Because when we build the elfcore (/proc/vmcore) header, we exclude memory area used by kernel B. The details can be found in kexec-tools patches. > > 9. Shutdown or reboot in hibernating kernel (kernel B). > > > > 10. Boot kernel (kernel C) compiled for hibernating/restore usage on > > the root file system /dev/hdb in memory range of kernel B. > > > > For example, the following kernel command line parameters can be > > used: > > > > root=/dev/hdb single memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED] > > > 0-640K from kernel A overrides 0-640K of kernel C at restore time. No. The 0-640K is not in the memory image of kernel A. It is excluded from memory image of kernel A in /sbin/kexec. Not very strictly, there is one backup page for each page in 0-640K, after jump back, the backup page will be swapped with the target page (in 0-640K). No information is lost. So you can jump back and forth, for arbitrary times. > > 11. In restore kernel (kernel C), the memory image of kernel A can be > > restored as follow: > > > > cp kexec_jump_back_entry /sys/kernel/kexec_jump_back_entry > > krestore vmcore > > > > > This steps replaces kernel C's pages with kernel B's (at least 15m-16m), > saved at step 8, so these kernels should be equal? Or they must be > physically located in non-overlapping regions such that C is in B's > memory range but non-overlapping. The proposed setup doesn't guaratee > this afaics. No. These pages are excluded from /proc/vmcore. These kernels need not to be equal. > > 12. Jump back to hibernated kernel (kernel A) > > > > kexec -b > > Best Regards, Huang Ying ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: > huang ying wrote: > > On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: > > > >>> Usage: > >>> > >>> 1. Compile kernel with following options selected: > >>> > >>> CONFIG_X86_32=y > >>> CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient > >>> with it > >>> CONFIG_KEXEC=y > >>> CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore > >>> memory image > >>> CONFIG_PM=y > >>> CONFIG_KEXEC_JUMP=y > >>> > >>> 2. Download the kexec-tools-testing git tree, apply the kexec-tools > >>>kjump patches (or download the source tar ball directly) and > >>>compile. > >>> > >>> 3. Download and compile the krestore tool. > >>> > >>> 4. Prepare 2 root partition used by kernel A and kernel B/C, referred > >>>as /dev/hda, /dev/hdb in following text. This is not strictly > >>>necessary, I use this scheme for testing during development. > >>> > >>> 5. Boot kernel compiled for normal usage (kernal A). > >>> > >>> 6. Load kernel compiled for hibernating/restore usage (kernel B) with > >>>kexec, the same kernel as that of 5 can be used if > >>>CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. > >>> > >>>The --elf64-core-headers should be specified in command line of > >>>kexec, because only the 64bit ELF is supported by krestore tool. > >>> > >>>For example, the shell command line can be as follow: > >>> > >>>kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff > >>>--elf64-core-headers --append="root=/dev/hdb single" > >>> > >>> 7. Jump to the hibernating kernel (kernel B) with following shell > >>>command line: > >>> > >>>kexec -j > >>> > >>> 8. In the hibernating kernel (kernel B), the memory image of > >>>hibernated kernel (kernel A) can be saved as follow: > >>> > >>>cp /proc/vmcore . > >>>cp /sys/kernel/kexec_jump_back_entry . > >>> > >>> > >> Here we save also kernel B's pages. > >> > > > > No, the kernel B's pages will not be saved. Because when we build the > > elfcore (/proc/vmcore) header, we exclude memory area used by kernel > > B. The details can be found in kexec-tools patches. > > > > > Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in > order not to allocate pages found also in A's space? Or does does the > --mem-min and --mem-max do that also? That is what "memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED]" for. The contents of e820 memmap will be overrided when these kernel parameters are specified. Best Regards, Huang Ying ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: > huang ying wrote: > > On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: > > > >> huang ying wrote: > >> > >>> On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: > >>> > >>> > > Usage: > > > > 1. Compile kernel with following options selected: > > > > CONFIG_X86_32=y > > CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient > > with it > > CONFIG_KEXEC=y > > CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore > > memory image > > CONFIG_PM=y > > CONFIG_KEXEC_JUMP=y > > > > 2. Download the kexec-tools-testing git tree, apply the kexec-tools > >kjump patches (or download the source tar ball directly) and > >compile. > > > > 3. Download and compile the krestore tool. > > > > 4. Prepare 2 root partition used by kernel A and kernel B/C, referred > >as /dev/hda, /dev/hdb in following text. This is not strictly > >necessary, I use this scheme for testing during development. > > > > 5. Boot kernel compiled for normal usage (kernal A). > > > > 6. Load kernel compiled for hibernating/restore usage (kernel B) with > >kexec, the same kernel as that of 5 can be used if > >CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. > > > >The --elf64-core-headers should be specified in command line of > >kexec, because only the 64bit ELF is supported by krestore tool. > > > >For example, the shell command line can be as follow: > > > >kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff > >--elf64-core-headers --append="root=/dev/hdb single" > > > > 7. Jump to the hibernating kernel (kernel B) with following shell > >command line: > > > >kexec -j > > > > 8. In the hibernating kernel (kernel B), the memory image of > >hibernated kernel (kernel A) can be saved as follow: > > > >cp /proc/vmcore . > >cp /sys/kernel/kexec_jump_back_entry . > > > > > > > Here we save also kernel B's pages. > > > >>> No, the kernel B's pages will not be saved. Because when we build the > >>> elfcore (/proc/vmcore) header, we exclude memory area used by kernel > >>> B. The details can be found in kexec-tools patches. > >>> > >>> > >>> > >> Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in > >> order not to allocate pages found also in A's space? Or does does the > >> --mem-min and --mem-max do that also? > >> > > > > That is what "memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED]" for. The > > contents of e820 memmap will be overrided when these kernel parameters > > are specified. > > > > Best Regards, > > Huang Ying > > > Yes, you just didn't specify exactmap for kernel B in your instructions, > but only for C. But it is also required for kernel B then? > They are specified for kernel B by /sbin/kexec automatically. Best Regards, Huang Ying ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 17:02, huang ying wrote: > On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > On Friday, 21 September 2007 15:14, huang ying wrote: > > > On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > > > > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > > [--snip--] > > > > > > > > > > No one has yet attacked the hard problem of coming up with separate > > > > > hibernate methods for drivers. > > > > > > > > Well, I've been playing a bit with that for some time, but it's not > > > > easy by any > > > > means. > > > > > > > > In short, I'm seeing some problems related to the handling of ACPI that > > > > seem to > > > > shatter the entire idea of having separate hibernate methods, at least > > > > as far > > > > as ACPI systems are concerned. > > > > > > So sadly to hear this. Can you details it a little? Or a link? > > > > 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. > > > > Now, the ACPI specification requires us to put devices into low power states > > before executing _PTS and that's exactly what we're doing before a suspend > > to > > RAM. Thus, it seems that in general we need to do the same for hibernation > > on > > ACPI systems. > > Then, is it possible to separate device quiesce from device suspend. It surely is possible, but I'm not sure if it's going to be useful. I mean, if we need to do exactly the same thing before a suspend to RAM and before a hibernation (ie. to put devices into low power states), why would we want to use different methods for that in both cases? > Perhaps not for swsusp, but for kexec based hibernation? Frankly, I don't know. Generally, changing the way in which device drivers handle suspend (to RAM) and hibernation is a huge task. After considering this issue for some time I think that we really should start from hardening suspend (to RAM) so that it doesn't need the freezer any more, because _that_ would require us to change the suspend-related drivers' callbacks anyway. When we are sure how we are going to eliminate the freezer from suspend (to RAM), we'll know how that affects hibernation and what to do about it. Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > On Friday, 21 September 2007 15:14, huang ying wrote: >> On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: >> > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: >> > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > [--snip--] >> > > >> > > No one has yet attacked the hard problem of coming up with separate >> > > hibernate methods for drivers. >> > >> > Well, I've been playing a bit with that for some time, but it's not easy by > any >> > means. >> > >> > In short, I'm seeing some problems related to the handling of ACPI that >> > seem > to >> > shatter the entire idea of having separate hibernate methods, at least as > far >> > as ACPI systems are concerned. >> >> So sadly to hear this. Can you details it a little? Or a link? > 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? The firmware shouldn't see the hibernate as anything other than a shutdown and reboot. ACPI should be initialized normally when resuming, which should take care of getting AC power status reported properly. This should be the behavior, anyway, on the many systems that do not support S4. > Now, the ACPI specification requires us to put devices into low power states > before executing _PTS and that's exactly what we're doing before a suspend to > RAM. Thus, it seems that in general we need to do the same for hibernation on > ACPI systems. It seems that if ACPI S4 is going to be used, Switching to low power state is something that should be done only immediately before entering that state (i.e. after the image has already been saved). In particular, it should not be done just before the atomic copy. It is true that (during resume) after the atomic copy snapshot is restored, drivers will need to be prepared (i.e. have saved whatever information is necessary) to _resume_ devices from the low power state, but that does not mean they have to actually be put into that low power state before the copy is made. I agree that for the kexec implementation there may be additional issues. For swsusp, uswsusp, and tuxonice, though, I don't see why there should be a problem. I think that, as was recognized before, all of the issues are resolved by properly considering exactly what each callback should do and when it should be called. The problems stem from ambiguous specifications, or trying to use the same callback for two different purposes or in two different cases. Let me know if I'm mistaken. -- Jeremy Maitin-Shepard ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Hi. On Saturday 22 September 2007 09:19:18 Kyle Moffett wrote: > I think that in order for this to work, there would need to be some > ABI whereby the resume-ing kernel can pass its entire ACPI state and > a bunch of other ACPI-related device details to the resume-ed kernel, > which I believe it does not do at the moment. I believe that what > causes problems is the ACPI state data that the kernel stores is > *different* between identical sequential boots, especially when you > add/remove/replace batteries, AC, etc. That's certainly possible. We already pass a very small amount of data between the boot and resuming kernels at the moment, and it's done quite simply - by putting the variables we want to 'transfer' in a nosave page/section. I could conceive of a scheme wherein this was extended for driver data. Since the memory needed would depend on the drivers loaded, it would probably require that the space be allocated when hibernating, and the locations of structures be stored in the image header and then drivers notified of the locations to use when preparing to resume, but it could work... > Since we currently throw away most of that in-kernel ACPI interpreter > state data when we load the to-be-resumed image and replace it with > the state from the previous boot it looks to the ACPI code and > firmware like our system's hardware magically changed behind its > back. The result is that the ACPI and firmware code is justifiably > confused (although probably it should be more idempotent to begin > with). There's 2 potential solutions: >1) Formalize and copy a *lot* of ACPI state from the resume-ing > kernel to the resume-ed kernel. >2) Properly call the ACPI S4 methods in the proper order ... that said, I don't think the above should be necessary in most cases. I believe we're already calling the ACPI S4 methods in the proper order. If I understood correctly, Rafael put a lot of effort into learning what that was, and into ensuring it does get done. > Neither one is particularly easy or particularly pleasant, especially > given all the vendor bugs in this general area. Theoretically we > should be able to do both, since one will be more reliable than the > other on different systems depending on what kinds of firmware bugs > they have. Regards, Nigel ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 21:45, Alan Stern wrote: > 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. I guess so, but I'm not sure. The ACPI NVS area is explicitly marked as reserved and we don't save it. On x86_64 we don't save any memory areas marked as reserved and yet the above happens. Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 23:08, Jeremy Maitin-Shepard wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > > On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: > >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > >> > >> [snip] > >> > >> > The ACPI NVS area is explicitly marked as reserved and we don't save it. > >> > On x86_64 we don't save any memory areas marked as reserved and yet the > > above > >> > happens. > >> > >> I think you have mentioned before, though, that ACPI is first > >> initialized by the boot kernel, before it is later initialized by > >> resuming kernel. This could well be the source of the problem. > > > No, it's not. I have tested that too with an ACPI-less boot kernel. > > Well, it seems that there just must be some other bug. I would define > anything that differs between the post-resume initialization of ACPI I'm not sure what you mean. > from the normal boot initialization of ACPI as a bug. If the interaction > with the hardware is the same, then the behavior will be the same. The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: >> >> [snip] >> >> > The ACPI NVS area is explicitly marked as reserved and we don't save it. >> > On x86_64 we don't save any memory areas marked as reserved and yet the > above >> > happens. >> >> I think you have mentioned before, though, that ACPI is first >> initialized by the boot kernel, before it is later initialized by >> resuming kernel. This could well be the source of the problem. > No, it's not. I have tested that too with an ACPI-less boot kernel. Well, it seems that there just must be some other bug. I would define anything that differs between the post-resume initialization of ACPI from the normal boot initialization of ACPI as a bug. If the interaction with the hardware is the same, then the behavior will be the same. -- Jeremy Maitin-Shepard ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Saturday, 22 September 2007 01:47, Nigel Cunningham wrote: > Hi. > > On Saturday 22 September 2007 09:19:18 Kyle Moffett wrote: > > I think that in order for this to work, there would need to be some > > ABI whereby the resume-ing kernel can pass its entire ACPI state and > > a bunch of other ACPI-related device details to the resume-ed kernel, > > which I believe it does not do at the moment. I believe that what > > causes problems is the ACPI state data that the kernel stores is > > *different* between identical sequential boots, especially when you > > add/remove/replace batteries, AC, etc. > > That's certainly possible. We already pass a very small amount of data > between > the boot and resuming kernels at the moment, and it's done quite simply - by > putting the variables we want to 'transfer' in a nosave page/section. Well, if the boot and image kernels are different, which is now possible on x86_64 with some recent patches (currently in -mm), the nosave trick won't work. Still, I don't think we need to pass anything from the boot to the image kernel. Moreover, we shouldn't do that, IMO (arguably, the boot kernel could be replaced with a resume-aware boot loader). > I could conceive of a scheme wherein this was extended for driver data. > Since the memory needed would depend on the drivers loaded, it would > probably require that the space be allocated when hibernating, and the > locations of structures be stored in the image header and then drivers > notified of the locations to use when preparing to resume, but it could > work... > > > Since we currently throw away most of that in-kernel ACPI interpreter > > state data when we load the to-be-resumed image and replace it with > > the state from the previous boot it looks to the ACPI code and > > firmware like our system's hardware magically changed behind its > > back. The result is that the ACPI and firmware code is justifiably > > confused (although probably it should be more idempotent to begin > > with). There's 2 potential solutions: > >1) Formalize and copy a *lot* of ACPI state from the resume-ing > > kernel to the resume-ed kernel. > >2) Properly call the ACPI S4 methods in the proper order > > ... that said, I don't think the above should be necessary in most cases. I > believe we're already calling the ACPI S4 methods in the proper order. If I > understood correctly, Rafael put a lot of effort into learning what that was, > and into ensuring it does get done. Yes, I did, but I can be wrong nevertheless. ;-) Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > [snip] > > > The ACPI NVS area is explicitly marked as reserved and we don't save it. > > On x86_64 we don't save any memory areas marked as reserved and yet the > > above > > happens. > > I think you have mentioned before, though, that ACPI is first > initialized by the boot kernel, before it is later initialized by > resuming kernel. This could well be the source of the problem. No, it's not. I have tested that too with an ACPI-less boot kernel. Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > On Friday, 21 September 2007 23:08, Jeremy Maitin-Shepard wrote: >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: >> >> > On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote: >> >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: >> >> >> >> [snip] >> >> >> >> > The ACPI NVS area is explicitly marked as reserved and we don't save it. >> >> > On x86_64 we don't save any memory areas marked as reserved and yet the >> > above >> >> > happens. >> >> >> >> I think you have mentioned before, though, that ACPI is first >> >> initialized by the boot kernel, before it is later initialized by >> >> resuming kernel. This could well be the source of the problem. >> >> > No, it's not. I have tested that too with an ACPI-less boot kernel. >> >> Well, it seems that there just must be some other bug. I would define >> anything that differs between the post-resume initialization of ACPI > I'm not sure what you mean. >> from the normal boot initialization of ACPI as a bug. If the interaction >> with the hardware is the same, then the behavior will be the same. > The ACPI platform firmware is allowed to preserve information accross the > hibernation-resume cycle, so this need not be the same. All of my comments related to the case where S4 is not being used (instead the system is just powered off normally), and a boot kernel that does not initialize ACPI is used. In that case, the ACPI platform firmware should not be able to distinguish a normal boot from a resume from hibernation. -- Jeremy Maitin-Shepard ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: > On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > >> The ACPI platform firmware is allowed to preserve information > >> accross the hibernation-resume cycle, so this need not be the same. > > > > All of my comments related to the case where S4 is not being used > > (instead the system is just powered off normally), and a boot > > kernel that does not initialize ACPI is used. In that case, the > > ACPI platform firmware should not be able to distinguish a normal > > boot from a resume from hibernation. > > I think that in order for this to work, there would need to be some > ABI whereby the resume-ing kernel can pass its entire ACPI state and > a bunch of other ACPI-related device details to the resume-ed kernel, > which I believe it does not do at the moment. In fact we don't need to do this. The solution is not to touch ACPI in the boot kernel (ie. the one that loads the image) and pass control to the image kernel. This is how it's supposed to work according to the spec, more or less (well, there are some ugly details that need handling, like the restoration of the NVS area). > I believe that what causes problems is the ACPI state data that the kernel > stores is *different* between identical sequential boots, especially when > you add/remove/replace batteries, AC, etc. Rather the ACPI state data that the platform firmware stores may be different, depending on whether you enter S4 or S5 during "power off" and that determines the interactions between the kernel and the firmware after the next boot. Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Friday, 21 September 2007 20:11, Jeremy Maitin-Shepard wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > > On Friday, 21 September 2007 15:14, huang ying wrote: > >> On 9/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > >> > On Friday, 21 September 2007 05:33, Eric W. Biederman wrote: > >> > > Nigel Cunningham <[EMAIL PROTECTED]> writes: > > [--snip--] > >> > > > >> > > No one has yet attacked the hard problem of coming up with separate > >> > > hibernate methods for drivers. > >> > > >> > Well, I've been playing a bit with that for some time, but it's not easy > >> > by > > any > >> > means. > >> > > >> > In short, I'm seeing some problems related to the handling of ACPI that > >> > seem > > to > >> > shatter the entire idea of having separate hibernate methods, at least as > > far > >> > as ACPI systems are concerned. > >> > >> So sadly to hear this. Can you details it a little? Or a link? > > > 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. > ACPI should be initialized normally when resuming, which should take care of > getting AC power status reported properly. Well, that doesn't work. I've tested it, really. :-) > This should be the behavior, anyway, on the many systems that do not > support S4. > > > Now, the ACPI specification requires us to put devices into low power states > > before executing _PTS and that's exactly what we're doing before a suspend > > to > > RAM. Thus, it seems that in general we need to do the same for hibernation > > on > > ACPI systems. > > It seems that if ACPI S4 is going to be used, Switching to low power > state is something that should be done only immediately before entering > that state (i.e. after the image has already been saved). Doesn't. Work. > In particular, it should not be done just before the atomic copy. It is > true that (during resume) after the atomic copy snapshot is restored, > drivers will need to be prepared (i.e. have saved whatever information > is necessary) to _resume_ devices from the low power state, but that > does not mean they have to actually be put into that low power state > before the copy is made. > > I agree that for the kexec implementation there may be additional > issues. For swsusp, uswsusp, and tuxonice, though, I don't see why > there should be a problem. I think that, as was recognized before, all > of the issues are resolved by properly considering exactly what each > callback should do and when it should be called. The problems stem from > ambiguous specifications, or trying to use the same callback for two > different purposes or in two different cases. > > Let me know if I'm mistaken. See above. :-) Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
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 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: [snip] > The ACPI NVS area is explicitly marked as reserved and we don't save it. > On x86_64 we don't save any memory areas marked as reserved and yet the above > happens. I think you have mentioned before, though, that ACPI is first initialized by the boot kernel, before it is later initialized by resuming kernel. This could well be the source of the problem. In particular, isn't it the case that you also switch the devices to low power mode before resuming? -- Jeremy Maitin-Shepard ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote: > On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: >> On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: >>> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: The ACPI platform firmware is allowed to preserve information accross the hibernation-resume cycle, so this need not be the same. >>> >>> All of my comments related to the case where S4 is not being used >>> (instead the system is just powered off normally), and a boot >>> kernel that does not initialize ACPI is used. In that case, the >>> ACPI platform firmware should not be able to distinguish a normal >>> boot from a resume from hibernation. >> >> I think that in order for this to work, there would need to be >> some ABI whereby the resume-ing kernel can pass its entire ACPI >> state and a bunch of other ACPI-related device details to the >> resume-ed kernel, which I believe it does not do at the moment. > > In fact we don't need to do this. > > The solution is not to touch ACPI in the boot kernel (ie. the one > that loads the image) and pass control to the image kernel. This > is how it's supposed to work according to the spec, more or less > (well, there are some ugly details that need handling, like the > restoration of the NVS area). First of all, we will need to make the resumed kernel throw away *ALL* of its ACPI state on S5 and completely reinitialize ACPI as though it was booting for the first time on resume. From what I can tell, we "throw away" all the ACPI state in the boot kernel and reinitialize it there, but then the reinitialized state is overwritten with the resumed kernel's state and the two don't always happen to be the same. (Like if a battery got replaced or AC status changed). Umm, I don't see how that can possibly work properly. For a laptop, for example, the restore kernel will need to access the disk, the LCD display, and possibly the AC/battery and current CPU frequency. From what I understand of ACPI, both of the former may need ACPI code to operate properly (Isn't there an ATA taskfile object of some kind?) and the latter two almost definitely need ACPI. Ergo the boot kernel may need to initialize and use ACPI just to run an ATA taskfile so it can read from the HDD efficiently. >> I believe that what causes problems is the ACPI state data that >> the kernel stores is *different* between identical sequential >> boots, especially when you add/remove/replace batteries, AC, etc. > > Rather the ACPI state data that the platform firmware stores may be > different, depending on whether you enter S4 or S5 during "power > off" and that determines the interactions between the kernel and > the firmware after the next boot. That's not what he was talking about. The problem discussed was: (A) You hibernate your box, entering S5 (IE: power off) (B) You resume the box and the boot kernel inits all the ACPI stuff. (C) The boot kernel's ACPI state is completely replaced by the resumed kernel's state. (D) Hardware stops working mysteriously because of ACPI problems. The only possible conclusion is that the state between the boot kernel and the resume kernel was *different* and so the device failed because the ACPI state in the resume kernel doesn't match the actual state of the hardware. Cheers, Kyle Moffett ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] Add extended crashkernel syntax to kernel-parameters.txt
This adds the documentation for the extended crashkernel syntax into Documentation/kernel-parameters.txt. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |7 +++ 1 file changed, 7 insertions(+) --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -498,6 +498,13 @@ and is between 256 and 4096 characters. [KNL] Reserve a chunk of physical memory to hold a kernel to switch to with kexec on panic. + crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED] + [KNL] Same as above, but depends on the memory + in the running system. The syntax of range is + start-[end] where start and end are both + a memory unit (amount[KMG]). See also + Documentation/kdump/kdump.txt for a example. + cs4232= [HW,OSS] Format: , ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] Add extended crashkernel syntax to kernel-parameters.txt
This adds the documentation for the extended crashkernel syntax into Documentation/kernel-parameters.txt. Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |7 +++ 1 file changed, 7 insertions(+) --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -498,6 +498,13 @@ and is between 256 and 4096 characters. [KNL] Reserve a chunk of physical memory to hold a kernel to switch to with kexec on panic. + crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED] + [KNL] Same as above, but depends on the memory + in the running system. The syntax of range is + start-[end] where start and end are both + a memory unit (amount[KMG]). See also + Documentation/kdump/kdump.txt for a example. + cs4232= [HW,OSS] Format: , ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On Saturday, 22 September 2007 20:00, Kyle Moffett wrote: > On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote: > > On Saturday, 22 September 2007 01:19, Kyle Moffett wrote: > >> On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote: > >>> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > The ACPI platform firmware is allowed to preserve information > accross the hibernation-resume cycle, so this need not be the same. > >>> > >>> All of my comments related to the case where S4 is not being used > >>> (instead the system is just powered off normally), and a boot > >>> kernel that does not initialize ACPI is used. In that case, the > >>> ACPI platform firmware should not be able to distinguish a normal > >>> boot from a resume from hibernation. > >> > >> I think that in order for this to work, there would need to be > >> some ABI whereby the resume-ing kernel can pass its entire ACPI > >> state and a bunch of other ACPI-related device details to the > >> resume-ed kernel, which I believe it does not do at the moment. > > > > In fact we don't need to do this. > > > > The solution is not to touch ACPI in the boot kernel (ie. the one > > that loads the image) and pass control to the image kernel. This > > is how it's supposed to work according to the spec, more or less > > (well, there are some ugly details that need handling, like the > > restoration of the NVS area). > > First of all, we will need to make the resumed kernel throw away > *ALL* of its ACPI state on S5 and completely reinitialize ACPI as > though it was booting for the first time on resume. Yes, if we entered S5 in the last step of the hibernation sequence, the right thing to do would be to make the resumed kernel reinitialize ACPI from scratch. > From what I can tell, we "throw away" all the ACPI state in the boot kernel > and reinitialize it there, but then the reinitialized state is > overwritten with the resumed kernel's state and the two don't always > happen to be the same. (Like if a battery got replaced or AC status > changed). Usually it goes like that. Still, you can pass "acpi=off" to the boot kernel, in which case it won't reinitialize ACPI. > Umm, I don't see how that can possibly work properly. For a laptop, > for example, the restore kernel will need to access the disk, the LCD > display, and possibly the AC/battery and current CPU frequency. From > what I understand of ACPI, both of the former may need ACPI code to > operate properly (Isn't there an ATA taskfile object of some kind?) > and the latter two almost definitely need ACPI. Well, this is not the case on any systems that I have access to, including two quite modern notebooks. Apparently, everything works without ACPI on these machines. Besides, in theory, it's possible to use an "intelligent" boot loader to read the hibernation image and that doesn't need ACPI for anything. > Ergo the boot kernel may need to initialize and use ACPI just to run an ATA > taskfile so it can read from the HDD efficiently. It is possible, but I haven't seen that yet. > >> I believe that what causes problems is the ACPI state data that > >> the kernel stores is *different* between identical sequential > >> boots, especially when you add/remove/replace batteries, AC, etc. > > > > Rather the ACPI state data that the platform firmware stores may be > > different, depending on whether you enter S4 or S5 during "power > > off" and that determines the interactions between the kernel and > > the firmware after the next boot. > > That's not what he was talking about. The problem discussed was: >(A) You hibernate your box, entering S5 (IE: power off) >(B) You resume the box and the boot kernel inits all the ACPI stuff. >(C) The boot kernel's ACPI state is completely replaced by the > resumed kernel's state. >(D) Hardware stops working mysteriously because of ACPI problems. > > The only possible conclusion is that the state between the boot > kernel and the resume kernel was *different* and so the device failed > because the ACPI state in the resume kernel doesn't match the actual > state of the hardware. I think it's even more complicated. The ACPI state of the resumed kernel has to match whatever is preserved by the platform. Well, my impression is that our current ACPI resume code actually expects the platform to preserve something and if that's missing the devices in question are not handled properly. If that really is the case, there is the question whether we can do something about it in a reasonable way and I can't answer it right now. Besides, I really think that we should use the ACPI S4 state, because machines generally support that. Greetings, Rafael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On 9/21/07, Huang, Ying <[EMAIL PROTECTED]> wrote: > This is fairly simple in fact. For example, you can specify the > bdev/sectors in kernel command line when do kexec load "kexec -l <...> > --append='...'", then the image writing system can get it through > "cat /proc/cmdline". I hope you take into account encrypted swap configuration. Currently all three suspend implementations support using encrypted swap in order to suspend/resume. A configuration which forces the user to remap encryption on the kexec kernel during suspend is not valid. Best Regards, Alon Bar-Lev. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [patch 1/7] Extended crashkernel command line
* Thu, 20 Sep 2007 19:18:46 +0200
[]
> extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
> extern unsigned int vmcoreinfo_size;
> extern unsigned int vmcoreinfo_max_size;
> +int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> + unsigned long long *crash_size, unsigned long long *crash_base);
(BTW, why `system_ram' is `unsigned long' in parse_crashkernel_mem() but
`unsigned long long' in parse_crashkernel()?)
> +static int __init parse_crashkernel_mem(char
> *cmdline,
> + unsigned long system_ram,
> + unsigned long long *crash_size,
> + unsigned long long *crash_base)
> +{
> + char *cur = cmdline;
> +
> + /* for each entry of the comma-separated list */
> + do {
> + unsigned long long start = 0, end = ULLONG_MAX;
> + unsigned long long size = -1;
[]
What is the point of not using `ulong' and `u64'?
What about another names?
+int __init get_crashkernel_params(u64 *memsize, u64 *addrbase, char *cmdline,
u64 ram);
_
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
