Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel

Ccing efi people. On 12/16/16 at 02:33pm, Jean Delvare wrote: > On Fri, 16 Dec 2016 14:18:58 +0200, Andy Shevchenko wrote: > > On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote: > > > On 12/15/16 at 12:28pm, Jean Delvare wrote: > > > > I am no kexec expert b

Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel

Ccing efi people. On 12/16/16 at 02:33pm, Jean Delvare wrote: > On Fri, 16 Dec 2016 14:18:58 +0200, Andy Shevchenko wrote: > > On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote: > > > On 12/15/16 at 12:28pm, Jean Delvare wrote: > > > > I am no kexec expert b

Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel

On 12/16/16 at 02:18pm, Andy Shevchenko wrote: > On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote: > > On 12/15/16 at 12:28pm, Jean Delvare wrote: > > > Hi Andy, > > > > > > On Fri,  2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote: > > > > Unt

Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel

On 12/16/16 at 02:18pm, Andy Shevchenko wrote: > On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote: > > On 12/15/16 at 12:28pm, Jean Delvare wrote: > > > Hi Andy, > > > > > > On Fri,  2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote: > > > > Unt

Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel

On 12/15/16 at 12:28pm, Jean Delvare wrote: > Hi Andy, > > On Fri, 2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote: > > Until now kexec'ed kernel has no clue where to look for DMI entry point. > > > > Pass it via kernel command line parameter in the same way as it's done for > > ACPI > >

Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel

On 12/15/16 at 12:28pm, Jean Delvare wrote: > Hi Andy, > > On Fri, 2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote: > > Until now kexec'ed kernel has no clue where to look for DMI entry point. > > > > Pass it via kernel command line parameter in the same way as it's done for > > ACPI > >

Re: [PATCH v2 2/5] ia64: reuse append_elf_note() and final_note() functions

Hi Hari Personally I like V1 more, but split the patch 2 is easier for ia64 people to reivew. I did basic x86 testing, it runs ok. On 11/25/16 at 05:24pm, Hari Bathini wrote: > Get rid of multiple definitions of append_elf_note() & final_note() > functions. Reuse these functions compiled under

Re: [PATCH v2 2/5] ia64: reuse append_elf_note() and final_note() functions

Hi Hari Personally I like V1 more, but split the patch 2 is easier for ia64 people to reivew. I did basic x86 testing, it runs ok. On 11/25/16 at 05:24pm, Hari Bathini wrote: > Get rid of multiple definitions of append_elf_note() & final_note() > functions. Reuse these functions compiled under

Re: [PATCHv4 07/10] kexec: Switch to __pa_symbol

On 11/30/16 at 09:13pm, Eric W. Biederman wrote: > Dave Young <dyo...@redhat.com> writes: > > > Hi, Laura > > On 11/29/16 at 10:55am, Laura Abbott wrote: > >> > >> __pa_symbol is the correct api to get the physical address of kernel > >> symbo

Re: [PATCHv4 07/10] kexec: Switch to __pa_symbol

On 11/30/16 at 09:13pm, Eric W. Biederman wrote: > Dave Young writes: > > > Hi, Laura > > On 11/29/16 at 10:55am, Laura Abbott wrote: > >> > >> __pa_symbol is the correct api to get the physical address of kernel > >> symbols. Switch to it to all

Re: [PATCHv4 07/10] kexec: Switch to __pa_symbol

Hi, Laura On 11/29/16 at 10:55am, Laura Abbott wrote: > > __pa_symbol is the correct api to get the physical address of kernel > symbols. Switch to it to allow for better debug checking. > I assume __pa_symbol is faster than __pa, but it still need some testing on all arches which support

Re: [PATCHv4 07/10] kexec: Switch to __pa_symbol

Hi, Laura On 11/29/16 at 10:55am, Laura Abbott wrote: > > __pa_symbol is the correct api to get the physical address of kernel > symbols. Switch to it to allow for better debug checking. > I assume __pa_symbol is faster than __pa, but it still need some testing on all arches which support

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

On 11/21/16 at 09:49pm, Thiago Jung Bauermann wrote: > Hello Dave, > > Thanks for your review. > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > > > powerpc's purgatory.ro has

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

On 11/21/16 at 09:49pm, Thiago Jung Bauermann wrote: > Hello Dave, > > Thanks for your review. > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > > > powerpc's purgatory.ro has

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

On 11/22/16 at 11:44am, Thiago Jung Bauermann wrote: > Am Dienstag, 22. November 2016, 17:01:10 BRST schrieb Michael Ellerman: > > Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: > > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: >

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

On 11/22/16 at 11:44am, Thiago Jung Bauermann wrote: > Am Dienstag, 22. November 2016, 17:01:10 BRST schrieb Michael Ellerman: > > Thiago Jung Bauermann writes: > > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > > >> On 11/10/16 at 01:27a

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

Hi Michael On 11/22/16 at 05:01pm, Michael Ellerman wrote: > Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > >> On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > >> > powe

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

Hi Michael On 11/22/16 at 05:01pm, Michael Ellerman wrote: > Thiago Jung Bauermann writes: > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > >> On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > >> > powerpc's purgatory.ro has

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

On 11/21/16 at 09:49pm, Thiago Jung Bauermann wrote: > Hello Dave, > > Thanks for your review. > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > > > powerpc's purgatory.ro has

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

On 11/21/16 at 09:49pm, Thiago Jung Bauermann wrote: > Hello Dave, > > Thanks for your review. > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > > > powerpc's purgatory.ro has

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > powerpc's purgatory.ro has 12 relocation types when built as > a relocatable object. To implement support for them requires > arch_kexec_apply_relocations_add to duplicate a lot of code with > module_64.c:apply_relocate_add. > > When built as

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > powerpc's purgatory.ro has 12 relocation types when built as > a relocatable object. To implement support for them requires > arch_kexec_apply_relocations_add to duplicate a lot of code with > module_64.c:apply_relocate_add. > > When built as

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/06/16 at 04:46pm, Baoquan He wrote: > KASLR memory randomization can randomize the base of the physical memory > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space > utility, mainly makedumpfile can use them

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/06/16 at 04:46pm, Baoquan He wrote: > KASLR memory randomization can randomize the base of the physical memory > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space > utility, mainly makedumpfile can use them

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/13/16 at 04:53pm, Baoquan He wrote: > Hi Pratyush, > > On 10/12/16 at 02:39pm, Pratyush Anand wrote: > > > > > > On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote: > > > > PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only > > > > > VMALLOC_BASE and VMEMMAP_BASE is

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/13/16 at 04:53pm, Baoquan He wrote: > Hi Pratyush, > > On 10/12/16 at 02:39pm, Pratyush Anand wrote: > > > > > > On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote: > > > > PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only > > > > > VMALLOC_BASE and VMEMMAP_BASE is

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/11/16 at 04:19pm, Dave Young wrote: > On 10/11/16 at 03:41pm, Baoquan He wrote: > > Hi Eric, > > > > Thanks a lot for your reviewing! Sorry for late reply. > > > > On 10/06/16 at 03:07pm, Eric W. Biederman wrote: > > > Baoquan He <b...@re

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/11/16 at 04:19pm, Dave Young wrote: > On 10/11/16 at 03:41pm, Baoquan He wrote: > > Hi Eric, > > > > Thanks a lot for your reviewing! Sorry for late reply. > > > > On 10/06/16 at 03:07pm, Eric W. Biederman wrote: > > > Baoquan He writes: >

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/11/16 at 03:41pm, Baoquan He wrote: > Hi Eric, > > Thanks a lot for your reviewing! Sorry for late reply. > > On 10/06/16 at 03:07pm, Eric W. Biederman wrote: > > Baoquan He writes: > > > > > KASLR memory randomization can randomize the base of the physical memory > > >

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/11/16 at 03:41pm, Baoquan He wrote: > Hi Eric, > > Thanks a lot for your reviewing! Sorry for late reply. > > On 10/06/16 at 03:07pm, Eric W. Biederman wrote: > > Baoquan He writes: > > > > > KASLR memory randomization can randomize the base of the physical memory > > > mapping

Re: Change CONFIG_DEVKMEM default value to n

On 10/10/16 at 07:12am, Greg Kroah-Hartman wrote: > On Mon, Oct 10, 2016 at 10:50:50AM +0800, Dave Young wrote: > > On 10/10/16 at 10:44am, Dave Young wrote: > > > On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote: > > > > On Fri, Oct 07, 2016 at 10:0

Re: Change CONFIG_DEVKMEM default value to n

On 10/10/16 at 07:12am, Greg Kroah-Hartman wrote: > On Mon, Oct 10, 2016 at 10:50:50AM +0800, Dave Young wrote: > > On 10/10/16 at 10:44am, Dave Young wrote: > > > On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote: > > > > On Fri, Oct 07, 2016 at 10:0

[PATCH v2] Move CONFIG_DEVKMEM default to n

Kconfig comment suggests setting it as "n" if in doubt thus move the default value to 'n'. Signed-off-by: Dave Young <dyo...@redhat.com> Suggested-by: Kees Cook <keesc...@chromium.org> --- Greg: drop the "default" line will set the default as n drivers/char/Kco

[PATCH v2] Move CONFIG_DEVKMEM default to n

Kconfig comment suggests setting it as "n" if in doubt thus move the default value to 'n'. Signed-off-by: Dave Young Suggested-by: Kees Cook --- Greg: drop the "default" line will set the default as n drivers/char/Kconfig |1 - 1 file changed, 1 deletion(-) --- linux-x

Re: Change CONFIG_DEVKMEM default value to n

On 10/10/16 at 10:44am, Dave Young wrote: > On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote: > > On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote: > > > Kconfig comment suggests setting it as "n" if in doubt thus move the > > > default value to

Re: Change CONFIG_DEVKMEM default value to n

On 10/10/16 at 10:44am, Dave Young wrote: > On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote: > > On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote: > > > Kconfig comment suggests setting it as "n" if in doubt thus move the > > > default value to

Re: Change CONFIG_DEVKMEM default value to n

On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote: > On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote: > > Kconfig comment suggests setting it as "n" if in doubt thus move the > > default value to 'n'. > > > > Signed-off-by: Dave Young <dyo...

Re: Change CONFIG_DEVKMEM default value to n

On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote: > On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote: > > Kconfig comment suggests setting it as "n" if in doubt thus move the > > default value to 'n'. > > > > Signed-off-by: Dave Young > > Su

loop mount: kernel BUG at lib/percpu-refcount.c:231

Hi, Below bug happened to me while loop mount a file image after stopping a kvm guest. But it only happend once til now.. [ 4761.031686] [ cut here ] [ 4761.075984] kernel BUG at lib/percpu-refcount.c:231! [ 4761.120184] invalid opcode: [#1] SMP [ 4761.164307]

loop mount: kernel BUG at lib/percpu-refcount.c:231

Hi, Below bug happened to me while loop mount a file image after stopping a kvm guest. But it only happend once til now.. [ 4761.031686] [ cut here ] [ 4761.075984] kernel BUG at lib/percpu-refcount.c:231! [ 4761.120184] invalid opcode: [#1] SMP [ 4761.164307]

Change CONFIG_DEVKMEM default value to n

Kconfig comment suggests setting it as "n" if in doubt thus move the default value to 'n'. Signed-off-by: Dave Young <dyo...@redhat.com> Suggested-by: Kees Cook <keesc...@chromium.org> --- drivers/char/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ---

Change CONFIG_DEVKMEM default value to n

Kconfig comment suggests setting it as "n" if in doubt thus move the default value to 'n'. Signed-off-by: Dave Young Suggested-by: Kees Cook --- drivers/char/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-x86.orig/drivers/char/Kconfig +++ linux-x86/dr

Re: [PATCH] Let CONFIG_STRICT_DEVMEM depends on CONFIG_DEVMEM

On 10/06/16 at 02:39pm, Kees Cook wrote: > On Wed, Oct 5, 2016 at 10:12 PM, Dave Young <dyo...@redhat.com> wrote: > > With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless > > even if it is set =y, thus let's update the dependency in Kconfig. > > > &g

Re: [PATCH] Let CONFIG_STRICT_DEVMEM depends on CONFIG_DEVMEM

On 10/06/16 at 02:39pm, Kees Cook wrote: > On Wed, Oct 5, 2016 at 10:12 PM, Dave Young wrote: > > With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless > > even if it is set =y, thus let's update the dependency in Kconfig. > > > > Signed-off-by: Dave Youn

[PATCH] Let CONFIG_STRICT_DEVMEM depends on CONFIG_DEVMEM

With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless even if it is set =y, thus let's update the dependency in Kconfig. Signed-off-by: Dave Young <dyo...@redhat.com> --- lib/Kconfig.debug |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-x86.orig/lib/Kconfig

[PATCH] Let CONFIG_STRICT_DEVMEM depends on CONFIG_DEVMEM

With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless even if it is set =y, thus let's update the dependency in Kconfig. Signed-off-by: Dave Young --- lib/Kconfig.debug |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-x86.orig/lib/Kconfig.debug +++ linux-x86/lib

Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi, 河合英宏 Thanks for the patch log update, it looks good to me. Acked-by: Dave Young <dyo...@redhat.com> On 09/20/16 at 11:22am, 河合英宏 / KAWAI，HIDEHIRO wrote: > Here is the revised commit description reflecting Dave's > comment. Cc list was copied from -mm version. > > Fr

Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi, 河合英宏 Thanks for the patch log update, it looks good to me. Acked-by: Dave Young On 09/20/16 at 11:22am, 河合英宏 / KAWAI，HIDEHIRO wrote: > Here is the revised commit description reflecting Dave's > comment. Cc list was copied from -mm version. > > From: Hidehiro Kawai > Sub

Re: [PATHC v2 5/9] ima: on soft reboot, save the measurement list

Hi, Mimi On 08/30/16 at 06:40pm, Mimi Zohar wrote: > From: Thiago Jung Bauermann > > This patch uses the kexec buffer passing mechanism to pass the > serialized IMA binary_runtime_measurements to the next kernel. > > Changelog v2: > - Fix build issue by defining a

Re: [PATHC v2 5/9] ima: on soft reboot, save the measurement list

Hi, Mimi On 08/30/16 at 06:40pm, Mimi Zohar wrote: > From: Thiago Jung Bauermann > > This patch uses the kexec buffer passing mechanism to pass the > serialized IMA binary_runtime_measurements to the next kernel. > > Changelog v2: > - Fix build issue by defining a stub ima_add_kexec_buffer and

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

Hi Dave, > > On 30/08/2016:04:22:30 PM, Dave Young wrote: > > Hi, Pratyush > > > > On 08/16/16 at 08:55am, Pratyush Anand wrote: > > > We have observed on few x86 machines with rtc-cmos device that > > > hpet_rtc_interrupt() is called just after irq regist

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

Hi Dave, > > On 30/08/2016:04:22:30 PM, Dave Young wrote: > > Hi, Pratyush > > > > On 08/16/16 at 08:55am, Pratyush Anand wrote: > > > We have observed on few x86 machines with rtc-cmos device that > > > hpet_rtc_interrupt() is called just after irq regist

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

On 08/30/16 at 04:38pm, Dave Young wrote: > On 08/30/16 at 04:22pm, Dave Young wrote: > > Hi, Pratyush > > > > On 08/16/16 at 08:55am, Pratyush Anand wrote: > > > We have observed on few x86 machines with rtc-cmos device that > > > hpet_rtc_interrupt(

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

On 08/30/16 at 04:38pm, Dave Young wrote: > On 08/30/16 at 04:22pm, Dave Young wrote: > > Hi, Pratyush > > > > On 08/16/16 at 08:55am, Pratyush Anand wrote: > > > We have observed on few x86 machines with rtc-cmos device that > > > hpet_rtc_interrupt(

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

On 08/30/16 at 04:22pm, Dave Young wrote: > Hi, Pratyush > > On 08/16/16 at 08:55am, Pratyush Anand wrote: > > We have observed on few x86 machines with rtc-cmos device that > > hpet_rtc_interrupt() is called just after irq registration and before > >

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

On 08/30/16 at 04:22pm, Dave Young wrote: > Hi, Pratyush > > On 08/16/16 at 08:55am, Pratyush Anand wrote: > > We have observed on few x86 machines with rtc-cmos device that > > hpet_rtc_interrupt() is called just after irq registration and before > >

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

Hi, Pratyush On 08/16/16 at 08:55am, Pratyush Anand wrote: > We have observed on few x86 machines with rtc-cmos device that > hpet_rtc_interrupt() is called just after irq registration and before > cmos_do_probe() could call hpet_rtc_timer_init(). > > So, neither hpet_default_delta nor

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

Hi, Pratyush On 08/16/16 at 08:55am, Pratyush Anand wrote: > We have observed on few x86 machines with rtc-cmos device that > hpet_rtc_interrupt() is called just after irq registration and before > cmos_do_probe() could call hpet_rtc_timer_init(). > > So, neither hpet_default_delta nor

Re: Capturing crash with 4.6.0 and above kernel does not work

On 08/25/16 at 05:45pm, Himanshu Madhani wrote: > > > On 8/25/16, 1:10 AM, "Michal Hocko" wrote: > > >[Let's add kdump people] > > > >On Wed 24-08-16 16:38:56, Himanshu Madhani wrote: > >> Hello list, > >> > >> I am wondering if anybody has issue capturing crash dump with

Re: Capturing crash with 4.6.0 and above kernel does not work

On 08/25/16 at 05:45pm, Himanshu Madhani wrote: > > > On 8/25/16, 1:10 AM, "Michal Hocko" wrote: > > >[Let's add kdump people] > > > >On Wed 24-08-16 16:38:56, Himanshu Madhani wrote: > >> Hello list, > >> > >> I am wondering if anybody has issue capturing crash dump with the 4.6.0 > >> and

Re: [PATCH v3 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range

On 08/25/16 at 11:00pm, Hari Bathini wrote: > > > On Thursday 25 August 2016 12:31 PM, Dave Young wrote: > > On 08/10/16 at 03:35pm, Hari Bathini wrote: > > > When fadump is enabled, by default 5% of system RAM is reserved for > > > fadump kernel. While that wor

Re: [PATCH v3 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range

On 08/25/16 at 11:00pm, Hari Bathini wrote: > > > On Thursday 25 August 2016 12:31 PM, Dave Young wrote: > > On 08/10/16 at 03:35pm, Hari Bathini wrote: > > > When fadump is enabled, by default 5% of system RAM is reserved for > > > fadump kernel. While that wor

Re: [PATCH v3 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range

On 08/10/16 at 03:35pm, Hari Bathini wrote: > When fadump is enabled, by default 5% of system RAM is reserved for > fadump kernel. While that works for most cases, it is not good enough > for every case. > > Currently, to override the default value, fadump supports specifying > memory to reserve

Re: [PATCH v3 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range

On 08/10/16 at 03:35pm, Hari Bathini wrote: > When fadump is enabled, by default 5% of system RAM is reserved for > fadump kernel. While that works for most cases, it is not good enough > for every case. > > Currently, to override the default value, fadump supports specifying > memory to reserve

Re: [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size"

On 08/23/16 at 06:11pm, Yinghai Lu wrote: > On Wed, Aug 17, 2016 at 1:20 AM, Dave Young <dyo...@redhat.com> wrote: > > On 08/17/16 at 09:50am, Xunlei Pang wrote: > >> "/sys/kernel/kexec_crash_size" only handles crashk_res, it > >> is fine in most

Re: [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size"

On 08/23/16 at 06:11pm, Yinghai Lu wrote: > On Wed, Aug 17, 2016 at 1:20 AM, Dave Young wrote: > > On 08/17/16 at 09:50am, Xunlei Pang wrote: > >> "/sys/kernel/kexec_crash_size" only handles crashk_res, it > >> is fine in most cases, but sometimes we have c

Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On 08/22/16 at 04:49pm, Icenowy Zheng wrote: > > > 22.08.2016, 15:28, "Dave Young" <dyo...@redhat.com>: > > On 08/18/16 at 09:41pm, Matt Fleming wrote: > >>  On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote: > >>  > > >>  > Could

Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On 08/22/16 at 04:49pm, Icenowy Zheng wrote: > > > 22.08.2016, 15:28, "Dave Young" : > > On 08/18/16 at 09:41pm, Matt Fleming wrote: > >>  On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote: > >>  > > >>  > Could we add some quirk for th

Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On 08/18/16 at 09:41pm, Matt Fleming wrote: > On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote: > > > > Could we add some quirk for these broken hardware instead of changing > > the normal code? > > I'd prefer not to do that if possible. Due to the way that the BIOS &

Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On 08/18/16 at 09:41pm, Matt Fleming wrote: > On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote: > > > > Could we add some quirk for these broken hardware instead of changing > > the normal code? > > I'd prefer not to do that if possible. Due to the way that the BIOS &

Re: [PATCH v2 2/6] powerpc: kexec_file: Add buffer hand-over support for the next kernel

On 08/22/16 at 12:38am, Thiago Jung Bauermann wrote: > Am Montag, 22 August 2016, 11:21:35 schrieb Dave Young: > > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > > > diff --git a/arch/powerpc/kernel/machine_kexec_64.c > > > b/arch/powerpc/kernel/machine_kexec_64

Re: [PATCH v2 2/6] powerpc: kexec_file: Add buffer hand-over support for the next kernel

On 08/22/16 at 12:38am, Thiago Jung Bauermann wrote: > Am Montag, 22 August 2016, 11:21:35 schrieb Dave Young: > > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > > > diff --git a/arch/powerpc/kernel/machine_kexec_64.c > > > b/arch/powerpc/kernel/machine_kexec_64

Re: [PATCH v2 3/6] kexec_file: Allow skipping checksum calculation for some segments.

On 08/22/16 at 12:25am, Thiago Jung Bauermann wrote: > Am Montag, 22 August 2016, 11:17:45 schrieb Dave Young: > > On 08/18/16 at 06:09pm, Thiago Jung Bauermann wrote: > > > Hello Dave, > > > > > > Thanks for your review! > > > > > > [ Tr

Re: [PATCH v2 3/6] kexec_file: Allow skipping checksum calculation for some segments.

On 08/22/16 at 12:25am, Thiago Jung Bauermann wrote: > Am Montag, 22 August 2016, 11:17:45 schrieb Dave Young: > > On 08/18/16 at 06:09pm, Thiago Jung Bauermann wrote: > > > Hello Dave, > > > > > > Thanks for your review! > > > > > > [ Tr

Re: [PATCH v2 2/6] powerpc: kexec_file: Add buffer hand-over support for the next kernel

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > The buffer hand-over mechanism allows the currently running kernel to pass > data to kernel that will be kexec'd via a kexec segment. The second kernel > can check whether the previous kernel sent data and retrieve it. > > This is the

Re: [PATCH v2 2/6] powerpc: kexec_file: Add buffer hand-over support for the next kernel

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > The buffer hand-over mechanism allows the currently running kernel to pass > data to kernel that will be kexec'd via a kexec segment. The second kernel > can check whether the previous kernel sent data and retrieve it. > > This is the

Re: [PATCH v2 3/6] kexec_file: Allow skipping checksum calculation for some segments.

the trimming. > > Am Donnerstag, 18 August 2016, 17:03:30 schrieb Dave Young: > > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > > > Adds checksum argument to kexec_add_buffer specifying whether the given > > > segment should be part of the checksum calcu

Re: [PATCH v2 3/6] kexec_file: Allow skipping checksum calculation for some segments.

the trimming. > > Am Donnerstag, 18 August 2016, 17:03:30 schrieb Dave Young: > > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > > > Adds checksum argument to kexec_add_buffer specifying whether the given > > > segment should be part of the checksum calcu

Re: [PATCH v2 3/6] kexec_file: Allow skipping checksum calculation for some segments.

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > Adds checksum argument to kexec_add_buffer specifying whether the given > segment should be part of the checksum calculation. > Since it is used with add buffer, could it be added to kbuf as a new field? Like kbuf.no_checksum, default value

Re: [PATCH v2 3/6] kexec_file: Allow skipping checksum calculation for some segments.

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > Adds checksum argument to kexec_add_buffer specifying whether the given > segment should be part of the checksum calculation. > Since it is used with add buffer, could it be added to kbuf as a new field? Like kbuf.no_checksum, default value

Re: [PATCH v2 1/2] kexec: add dtb info to struct kimage

); > image->initrd_buf = NULL; > > + vfree(image->dtb_buf); > + image->dtb_buf = NULL; > + > kfree(image->cmdline_buf); > image->cmdline_buf = NULL; > > -- > 1.9.1 > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Acked-by: Dave Young <dyo...@redhat.com> Thanks Dave

Re: [PATCH v2 1/2] kexec: add dtb info to struct kimage

vfree(image->dtb_buf); > + image->dtb_buf = NULL; > + > kfree(image->cmdline_buf); > image->cmdline_buf = NULL; > > -- > 1.9.1 > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Acked-by: Dave Young Thanks Dave

Re: [PATCH v2 2/2] kexec: extend kexec_file_load system call

Since Eric was objecting the extension, I think you should convince him, but I will review from code point of view. On 08/11/16 at 08:03pm, Thiago Jung Bauermann wrote: > From: AKASHI Takahiro > > Device tree blob must be passed to a second kernel on DTB-capable >

Re: [PATCH v2 2/2] kexec: extend kexec_file_load system call

Since Eric was objecting the extension, I think you should convince him, but I will review from code point of view. On 08/11/16 at 08:03pm, Thiago Jung Bauermann wrote: > From: AKASHI Takahiro > > Device tree blob must be passed to a second kernel on DTB-capable > archs, like powerpc and arm64,

Re: [PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus

On 08/17/16 at 07:36pm, Joe Perches wrote: > On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote: > > nr_cpus can help to save memory. So we should remind user of it. > > trivia: > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > [] > > @@ -390,9 +390,11 @@ Notes

Re: [PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus

On 08/17/16 at 07:36pm, Joe Perches wrote: > On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote: > > nr_cpus can help to save memory. So we should remind user of it. > > trivia: > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > [] > > @@ -390,9 +390,11 @@ Notes

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On 08/17/16 at 11:00am, Alex Thorlton wrote: > On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote: > > > > Why do you guys need the physical mapping all of a sudden? > > > > > > It's not that we need it all of the sudden, necessarily, it's just that >

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On 08/17/16 at 11:00am, Alex Thorlton wrote: > On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote: > > > > Why do you guys need the physical mapping all of a sudden? > > > > > > It's not that we need it all of the sudden, necessarily, it's just that >

Re: [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size"

rface, > and users should be aware of what they are doing. Cc Yinghai Lu for review since he introduced the ,high and ,low logic. > > Suggested-by: Dave Young <dyo...@redhat.com> > Signed-off-by: Xunlei Pang <xlp...@redhat.com> > --- > include/linu

Re: [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size"

rface, > and users should be aware of what they are doing. Cc Yinghai Lu for review since he introduced the ,high and ,low logic. > > Suggested-by: Dave Young > Signed-off-by: Xunlei Pang > --- > include/linux/kexec.h | 4 ++-- > kernel/kexec_core.c | 23

Re: [PATCH v2 2/2] kexec: Consider crashk_low_res in sanity_check_segment_list()

Hi, Xunlei, On 08/17/16 at 09:50am, Xunlei Pang wrote: > We have crashk_res only in most cases, but sometimes we have > crashk_low_res. > > For example, on 64-bit x86 systems, when "crashkernel=32M,high" > combined with "crashkernel=128M,low" is used, so some segments > may have the chance to be

Re: [PATCH v2 2/2] kexec: Consider crashk_low_res in sanity_check_segment_list()

Hi, Xunlei, On 08/17/16 at 09:50am, Xunlei Pang wrote: > We have crashk_res only in most cases, but sometimes we have > crashk_low_res. > > For example, on 64-bit x86 systems, when "crashkernel=32M,high" > combined with "crashkernel=128M,low" is used, so some segments > may have the chance to be

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

> > Why do you guys need the physical mapping all of a sudden? > > It's not that we need it all of the sudden, necessarily, it's just that > we've had to make other changes to make things work with the new, > (almost) completely isolated, EFI page tables. We ended up choosing the > lesser of two

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

> > Why do you guys need the physical mapping all of a sudden? > > It's not that we need it all of the sudden, necessarily, it's just that > we've had to make other changes to make things work with the new, > (almost) completely isolated, EFI page tables. We ended up choosing the > lesser of two

Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On 08/15/16 at 01:56pm, Matt Fleming wrote: > On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote: > > Some broken firmwares have a wrongly filled version field in BGRT table. > > (See http://wiki.osdev.org/Broken_UEFI_implementations ) > > > > As we know, these firmwares can also provide correct

Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On 08/15/16 at 01:56pm, Matt Fleming wrote: > On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote: > > Some broken firmwares have a wrongly filled version field in BGRT table. > > (See http://wiki.osdev.org/Broken_UEFI_implementations ) > > > > As we know, these firmwares can also provide correct

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > Hello, > > This patch series implements a mechanism which allows the kernel to pass > on a buffer to the kernel that will be kexec'd. This buffer is passed > as a segment which is added to the kimage when it is being prepared > by

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > Hello, > > This patch series implements a mechanism which allows the kernel to pass > on a buffer to the kernel that will be kexec'd. This buffer is passed > as a segment which is added to the kimage when it is being prepared > by

Re: [PATCH] kexec: Account crashk_low_res to kexec_crash_size

Hi, On 08/15/16 at 04:05pm, Xunlei Pang wrote: > On 2016/08/15 at 15:17, Dave Young wrote: > > Hi Xunlei, > > > > On 08/13/16 at 04:26pm, Xunlei Pang wrote: > >> "/sys/kernel/kexec_crash_size" only includes crashk_res, it > >> is fine in

Re: [PATCH] kexec: Account crashk_low_res to kexec_crash_size

Hi, On 08/15/16 at 04:05pm, Xunlei Pang wrote: > On 2016/08/15 at 15:17, Dave Young wrote: > > Hi Xunlei, > > > > On 08/13/16 at 04:26pm, Xunlei Pang wrote: > >> "/sys/kernel/kexec_crash_size" only includes crashk_res, it > >> is fine in

<    3   4   5   6   7   8   9   10   11   12   >