Re: [PATCH] crash: use macro to add crashk_res into iomem early for specific arch

* Baoquan He wrote: > On 03/24/24 at 05:06am, Ingo Molnar wrote: > > > > * Baoquan He wrote: > > > ..snip > > > --- > > > arch/x86/include/asm/crash_reserve.h | 2 ++ > > > kernel/crash_reserve.c | 7 +++ > > &g

Re: [PATCH] crash: use macro to add crashk_res into iomem early for specific arch

* Baoquan He wrote: > There are regression reports[1][2] that crashkernel region on x86_64 can't > be added into iomem tree sometime. This causes the later failure of kdump > loading. > > This happened after commit 4a693ce65b18 ("kdump: defer the insertion of > crashkernel resources") was

Re: [PATCH v11 2/5] x86: kdump: move reserve_crashkernel_low() into crash_core.c

t moving of code that doesn't regress on x86: Acked-by: Ingo Molnar Thanks, Ingo ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] efi/x86: Revert struct layout change to fix kexec boot regression

* Ard Biesheuvel wrote: > On Fri, 10 Apr 2020 at 16:34, Borislav Petkov wrote: > > > > On Fri, Apr 10, 2020 at 04:22:49PM +0200, Ard Biesheuvel wrote: > > > > BTW, a fixes tag is good to have.. > > > > > > I usually omit those for patches that fix bugs that were introduced in > > > the

Re: [PATCH] x86/efi: update e820 about reserved EFI boot services data to fix kexec breakage

* Dave Young wrote: > On 12/04/19 at 03:52pm, Dave Young wrote: > > Michael Weiser reported he got below error during a kexec rebooting: > > esrt: Unsupported ESRT version 2904149718861218184. > > > > The ESRT memory stays in EFI boot services data, and it was reserved > > in kernel via

Re: [PATCH] x86/efi: update e820 about reserved EFI boot services data to fix kexec breakage

* Dave Young wrote: > On 12/04/19 at 03:52pm, Dave Young wrote: > > Michael Weiser reported he got below error during a kexec rebooting: > > esrt: Unsupported ESRT version 2904149718861218184. > > > > The ESRT memory stays in EFI boot services data, and it was reserved > > in kernel via

Re: [PATCH v3 2/2] x86/kdump: Reserve extra memory when SME or SEV is active

* Kairui Song wrote: > Since commit c7753208a94c ("x86, swiotlb: Add memory encryption support"), > SWIOTLB will be enabled even if there is less than 4G of memory when SME > is active, to support DMA of devices that not support address with the > encrypt bit. > > And commit aba2d9a6385a

Re: [PATCH v6 1/2] x86/kexec: Build identity mapping for EFI systab and ACPI tables

* Dave Young wrote: > On 05/14/19 at 01:38pm, Peter Zijlstra wrote: > > On Tue, May 14, 2019 at 04:48:41PM +0800, Dave Young wrote: > > > > > > I did some tests on the laptop, thing is: > > > > 1. apply the 3 patches (two you posted + Boris's revert commit > > > > 52b922c3d49c) > > > >

Re: [PATCH] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernels

* Borislav Petkov wrote: > I'll queue the below in the next days if there are no more complaints: Just a minor style nit, this was inherited from existing code: > + efi_config_table_64_t *tbl = (efi_config_table_64_t *) > config_tables + i; > +

Re: [PATCH v3 1/4] x86: kdump: move reserve_crashkernel_low() into kexec_core.c

* Chen Zhou wrote: > Hi Ingo, > > On 2019/4/10 15:09, Ingo Molnar wrote: > > > > * Chen Zhou wrote: > > > >> In preparation for supporting more than one crash kernel regions > >> in arm64 as x86_64 does, move reserve_crashkernel_low() into

Re: [PATCH v3 1/4] x86: kdump: move reserve_crashkernel_low() into kexec_core.c

* Chen Zhou wrote: > In preparation for supporting more than one crash kernel regions > in arm64 as x86_64 does, move reserve_crashkernel_low() into > kexec/kexec_core.c. > > Signed-off-by: Chen Zhou > --- > arch/x86/include/asm/kexec.h | 3 ++ > arch/x86/kernel/setup.c | 66 >

Re: [PATCH] x86: fix -Wmissing-prototypes warning

* wang.y...@zte.com.cn wrote: > Hi Ingo, > > > * Yi Wang wrote: > > > > > We may get -Wmissing-prototypes warnings when building > > > kernel with W=1, it's better to fix them as global function > > > signature can be changed and caller who use the old unchanged > > > prototypes will be

Re: [PATCH] x86: fix -Wmissing-prototypes warning

* Yi Wang wrote: > We may get -Wmissing-prototypes warnings when building > kernel with W=1, it's better to fix them as global function > signature can be changed and caller who use the old unchanged > prototypes will be hosed. > > This patch fixes most of -Wmissing-prototypes warnings which >

Re: [GIT PULL] remove in-kernel calls to syscalls

* Linus Torvalds wrote: > On Mon, Apr 2, 2018 at 12:04 PM, Dominik Brodowski > wrote: > > > > This patchset removes all in-kernel calls to syscall functions in the > > kernel with the exception of arch/. > > Ok, this finished off my

Re: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo

* Kirill A. Shutemov wrote: > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception:

Re: [PATCH v1 1/2] x86/mm, kexec: Fix memory corruption with SME on successive kexecs

* Tom Lendacky wrote: > After issuing successive kexecs it was found that the SHA hash failed > verification when booting the kexec'd kernel. When SME is enabled, the > change from using pages that were marked encrypted to now being marked as > not encrypted (through

Re: [PATCH v9 00/38] x86: Secure Memory Encryption (AMD)

* Tom Lendacky wrote: > This patch series provides support for AMD's new Secure Memory Encryption > (SME) > feature. I'm wondering, what's the typical performance hit to DRAM access latency when SME is enabled? On that same note, if the performance hit is

Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

* Xunlei Pang <xp...@redhat.com> wrote: > On 05/05/2017 at 05:20 PM, Ingo Molnar wrote: > > * Xunlei Pang <xp...@redhat.com> wrote: > > > >> On 05/05/2017 at 02:52 PM, Ingo Molnar wrote: > >>> * Xunlei Pang <xlp...@redhat.com> wrote: >

Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

* Xunlei Pang <xp...@redhat.com> wrote: > On 05/05/2017 at 02:52 PM, Ingo Molnar wrote: > > * Xunlei Pang <xlp...@redhat.com> wrote: > > > >> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, > >> unsigned long start_pgtable) > &g

Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

* Xunlei Pang wrote: > @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned > long start_pgtable) > > level4p = (pgd_t *)__va(start_pgtable); > clear_page(level4p); > + > + if (direct_gbpages) > + info.direct_gbpages =

Re: [PATCH] memmap: Parse "Reserved" together with "reserved"

* Yinghai Lu wrote: > For x86 with recent kernel after > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c") > change "reserved" to "Reserved" in /sys firmware memmap and /proc/iomem. > > So here, we add handling for that too. > > Signed-off-by: Yinghai Lu

Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

* Thomas Gleixner wrote: > Borislav, > > On Mon, 5 Oct 2015, Borislav Petkov wrote: > > On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI，HIDEHIRO wrote: > > > That's different from my point of view. I'm not going to pass > > > some data from the first kernel to the

Re: [PATCH v3] kexec: fix out of the ELF headers buffer issue in syscall kexec_file_load()

* Andrew Morton wrote: > On Tue, 29 Sep 2015 20:58:57 +0800 "Lee, Chun-Yi" > wrote: > > > This patch modified the code in fill_up_crash_elf_data by using > > walk_system_ram_res instead of walk_system_ram_range to count the max > > number

Re: [PATCH 0/3 v3] Fix kdump failures with crashkernel=high

* Borislav Petkov b...@alien8.de wrote: Joerg Roedel (3): swiotlb: Warn on allocation failure in swiotlb_alloc_coherent x86, swiotlb: Try coherent allocations with __GFP_NOWARN x86, crash: Allocate enough low-mem when crashkernel=high arch/x86/kernel/pci-swiotlb.c | 7

Re: Re: [PATCH v2] kernel/panic/kexec: fix crash_kexec_post_notifiers option issue in oops path

* Vivek Goyal vgo...@redhat.com wrote: Yet the actual bug is in that commit, 'crash_kexec_post_notifiers' was clearly not a no-op in the default case, against expectations. Hi Ingo, I did a quick test and in default case crash_kexec() runs before panic notifiers. So it does look

Re: [PATCH v2] kernel/panic/kexec: fix crash_kexec_post_notifiers option issue in oops path

* Vivek Goyal vgo...@redhat.com wrote: On Mon, Mar 23, 2015 at 08:19:43AM +0100, Ingo Molnar wrote: * Baoquan He b...@redhat.com wrote: CC more people ... On 03/07/15 at 01:31am, Hatayama, Daisuke/畑山 大輔 wrote: The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced

Re: [patch 1/3 v2] Add function get_bootparam

* H. Peter Anvin h...@zytor.com wrote: On 11/11/2013 05:27 PM, Toshi Kani wrote: On Tue, 2013-11-05 at 16:29 +0800, dyo...@redhat.com wrote: Not only setup_subarch will get data from debugfs file boot_params/data, later code for adding efi_info will also need do same thing. Thus add a

Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path

...@redhat.com AuthorDate: Thu, 9 Feb 2012 16:53:41 -0500 Committer:  Ingo Molnar mi...@elte.hu CommitDate: Sat, 11 Feb 2012 15:38:53 +0100 x86/kdump: No need to disable ioapic/lapic in crash path A customer of ours noticed when their machine crashed, kdump did not work but hung instead

Re: [PATCH v2] generic-ipi: Initialize call_single_queue before enabling interrupt

* Takao Indoh indou.ta...@jp.fujitsu.com wrote: Just a reminder... Thanks for acks, but I'm still waiting for inclusion. I tested 3.0.0-rc3 and kdump still failed due to pending IPI from 1st kernel. Need this patch to fix it. For any future patch that has a review discussion (like this

Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic

* Ahmed S. Darwish darwish...@gmail.com wrote: - The latest approach (proposed by Linus) is to forget the disk: jump to real-mode, but display the kernel log in a fancy format (with scroll ups and downs) instead. Will re-initializing the VGA registers to their POST state be possible?

Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic

* Ahmed S. Darwish darwish...@gmail.com wrote: Also, have you tried BIOS warm reset vector, which is supposed to reboot without clearing RAM contents - how well does it work in practice on typical laptops? If on crash we could reboot without memory getting cleared that would open

Re: [PATCH 03/14] x86, config: change defaults PHYSICAL_START and PHYSICAL_ALIGN

* Sam Ravnborg s...@ravnborg.org wrote: On Thu, May 07, 2009 at 03:26:51PM -0700, H. Peter Anvin wrote: From: H. Peter Anvin h...@zytor.com Change the default for CONFIG_PHYSICAL_START to 16 MB; 4 MB if EMBEDDED. Change the default for CONFIG_PHYSICAL_ALIGN to match up with a large

Re: kdump hangs up by Sysrq+C trigger in high load.

* Yoshihiro Takahashi ytakaha...@miraclelinux.com wrote: Hi. kdump hangs up by Sysrq+C trigger once in about 10 times in high load. After the above occurs, kdump cannot collect vmcores with NMI button. When waiting_for_crash_ipi does case more than 0, mdelay seem to make a stall.

Re: [PATCH 0/8] Make nmi_shootdown_cpus() usable by non-kdump code

* Eduardo Habkost [EMAIL PROTECTED] wrote: Hi, Ingo, As tip/master is a moving target, I am splitting the previous kdump/reboot virtualization-disable code series[1] into smaller series so the simpler parts can be included sooner. This first series is just for making

Re: [PATCH 15/15] Revert x86: default to reboot via ACPI

* Ingo Molnar [EMAIL PROTECTED] wrote: Andrey Borzenkov's patch, for example, adds a new DMI entry because reboot=acpi breaks his keyboard (even without KVM, I guess). Andrey, was that the case? hm, IIRC the problem was KVM in his case too. actually, Andrey's problem seems

Re: [PATCH 00/14] x86: disable virt on kdump and emergency_restart

* Avi Kivity [EMAIL PROTECTED] wrote: Eduardo Habkost wrote: Hi, This is a new version of the series to disabling virtualization on kdump, now extended to do the same tricks on emergency_restart() if needed. Looks good. If you me to push it upstream, I'll need kexec/kdump acks.

Re: [PATCH 15/15] Revert x86: default to reboot via ACPI

* Eduardo Habkost [EMAIL PROTECTED] wrote: This reverts commit c7ffa6c26277b403920e2255d10df849bd613380. Now that we have the hooks to disable virtualization on emergency_restart(), we can get back to the BOOT_KBD reboot_type default. Signed-off-by: Eduardo Habkost [EMAIL PROTECTED] hm,

Re: [PATCH 0/3 -v4] kexec/i386: kexec page table code clean up

* Huang Ying [EMAIL PROTECTED] wrote: This patchset cleans up page table setup code of kexec on i386. This patchset is based on v2.6.28-rc2-338-g65fc716 and has been tested on i386. applied to tip/x86/crashdump: 9868ee6: kexec/i386: setup kexec page table in C 92be3d6: kexec/i386:

Re: [PATCH] x86: make oops_begin and oops_end equal

* Neil Horman [EMAIL PROTECTED] wrote: Thanks for the review. I've sent a redone patch series just a moment ago, based on your comments. There was also another problem with these two patches: oops_end(flags, regs, signr) had special behaviour for regs=NULL that I did not consider

Re: [PATCH] kexec jump: fix compiling warning on xchg(kexec_lock, 0) in kernel_kexec()

* Andrew Morton [EMAIL PROTECTED] wrote: instead? Not that that's really right either, but at least it avoids the _ridiculous_ crap. The real solution is probably to use a spinlock and trylock/unlock. Or test_and_set_bit(). That's what I've been saying too, only differently ;)

Re: [PATCH 2/5] x86: Define elfcorehdr_addr in arch dependent section

(-) the x86 bits look fine to me. Acked-by: Ingo Molnar [EMAIL PROTECTED] Ingo ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr'

to a crossing change i guess. Also, i guess this should go via -mm as it touches fs/proc/vmcore.c and include/linux/crash_dump.h. The x86 bits look good to me. Acked-by: Ingo Molnar [EMAIL PROTECTED] Ingo ___ kexec mailing list kexec

Re: [PATCH] x86: Move dma32_reserve_bootmem() after reserve_crashkernel()

* Bernhard Walle [EMAIL PROTECTED] wrote: On a x86-64 machine (nothing special I could encounter) I had the problem that crashkernel reservation with the usual [EMAIL PROTECTED] failed. While debugging that, I encountered that dma32_reserve_bootmem() reserves a memory region which is in

Re: [PATCH] x86: Find offset for crashkernel reservation automatically

* Bernhard Walle [EMAIL PROTECTED] wrote: But in general policy should go in userspace (if possible), so I agree with you that kexec-tools can handle that. At a quick skim the patch looks good. I thought I had initially implemented the code to work this way but apparently in all

Re: [PATCH] x86: Fix documentation bug about relocatability

* Bernhard Walle [EMAIL PROTECTED] wrote: This patch fixes a small bug in documentation: x86_64 also has now the ability to build a relocatable kernel. applied to tip/x86/crashdump - thanks Bernhard. Ingo ___ kexec mailing list

Re: [PATCH] Remove CONFIG_EXPERIMENTAL from kdump

* Bernhard Walle [EMAIL PROTECTED] wrote: I would suggest to remove the experimental status from Kdump. Kdump is now in the kernel since a long time and used by Enterprise distributions. I don't think that experimental is true any more. agreed. I have applied your patch to

Re: [PATCH] x86: Limit E820 map when a user-defined memory map is specified

* Yinghai Lu [EMAIL PROTECTED] wrote: On Wed, Jun 25, 2008 at 12:39 PM, Bernhard Walle [EMAIL PROTECTED] wrote: This patch brings back limiting of the E820 map when a user-defined E820 map is specified. While the behaviour of i386 (32 bit) was to limit the E820 map (and /proc/iomem), the

Re: [patch] [PATCH] Use BOOTMEM_EXCLUSIVE for i386

* Bernhard Walle [EMAIL PROTECTED] wrote: This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for i386 and prints a error message on failure. The patch is still for 2.6.26 since it is only bug fixing. The unification of reserve_crashkernel() between i386 and x86_64

Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path

* Neil Horman [EMAIL PROTECTED] wrote: Ingo noted a few posts down the nmi_exit doesn't actually write to the APIC EOI register, so yeah, I agree, its bogus (and I apologize, I should have checked that more carefully). Nevertheless, this patch consistently allowed a hangning machine to

Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path

* Neil Horman [EMAIL PROTECTED] wrote: if (!user_mode_vm(regs)) { + nmi_exit(); + local_irq_enable(); current-thread.trap_no = 2; crash_kexec(regs); looks good to me, but please move the local_irq_enable() to within crash_kexec()

Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path

* Vivek Goyal [EMAIL PROTECTED] wrote: On Wed, Feb 06, 2008 at 11:00:01PM +0100, Ingo Molnar wrote: * Neil Horman [EMAIL PROTECTED] wrote: if (!user_mode_vm(regs)) { + nmi_exit(); + local_irq_enable(); current-thread.trap_no = 2

Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path

* H. Peter Anvin [EMAIL PROTECTED] wrote: I am wondering if interrupts are disabled on crashing cpu or if crashing cpu is inside die_nmi(), how would it stop/prevent delivery of NMI IPI to other cpus. I don't see how it would. cross-CPU IPIs are a bit fragile on some PC platforms. So if

Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path

* Eric W. Biederman [EMAIL PROTECTED] wrote: Looking at the patch the local_irq_enable() is totally bogus. As soon was we hit machine_crash_shutdown the first thing we do is disable irqs. yeah. I'm wondering if someone was using the switch cpus on crash patch that was floating around.

Re: [PATCH] i386: handle an initrd in highmem (version 2)

* H. Peter Anvin [EMAIL PROTECTED] wrote: Fix crash on NUMA reported by Dhaval Giani (reported as being a kexec issue.) here's the delta fix. Ingo Index: linux-x86.q/arch/x86/kernel/setup_32.c === ---

Re: [PATCH] i386: handle an initrd in highmem (version 2)

* H. Peter Anvin [EMAIL PROTECTED] wrote: Fix crash on NUMA reported by Dhaval Giani (reported as being a kexec issue.) thanks, applied. Ingo ___ kexec mailing list kexec@lists.infradead.org

Re: kexec refuses to boot latest -mm

* Dhaval Giani [EMAIL PROTECTED] wrote: So I went ahead and bisected -mm, and the culprit is git-x86. It boots fine before it, but with git-x86 applied, it fails to boot. Ingo/Thomas, could you please point me to the git-x86 tree so that I can bisect it? (with instructions on how to pull