* Borislav Petkov 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 +++
>
* 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 of crash memory ranges. That's because the walk_system
* 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 second kernel. I'm jus
* Eric W. Biederman wrote:
> Sigh. Can we please just do the work to rip out the apic shutdown code from
> the
> kexec on panic code path?
>
> I forgetting details but the only reason we have do any apic shutdown is bugs
> in
> older kernels that could not initialize a system properly if w
* 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
>
> ---
> kexec/arch/i38
* Xunlei Pang wrote:
> The current kernel_ident_mapping_init() creates the identity
> mapping using 2MB page(PMD level), this patch adds the 1GB
> page(PUD level) support.
>
> This is useful on large machines to save some reserved memory
> (as paging structures) in the kdump case when kexec set
* 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 = true;
No, this should
* Xunlei Pang wrote:
> On 05/05/2017 at 02:52 PM, Ingo Molnar wrote:
> > * Xunlei Pang wrote:
> >
> >> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image,
> >> unsigned long start_pgtable)
> >>
> >>level4p = (pgd_
* Xunlei Pang wrote:
> On 05/05/2017 at 05:20 PM, Ingo Molnar wrote:
> > * Xunlei Pang wrote:
> >
> >> On 05/05/2017 at 02:52 PM, Ingo Molnar wrote:
> >>> * Xunlei Pang wrote:
> >>>
> >>>> @@ -122,6 +122,10 @@ static int init_pg
* 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 noticeable I'd expect SME to not
b
* 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 new identify mapped page ta
* 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: '&mem_section' means "address of t
* 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 arch updates for today, I'll probably move on
> to driver pul
* 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
>
* 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 hosed.
* H. Peter Anvin 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 comm
* Baoquan He wrote:
> CC more people ...
>
> On 03/07/15 at 01:31am, "Hatayama, Daisuke/畑山 大輔" wrote:
> > The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
> > "crash_kexec_post_notifiers" kernel boot option, which toggles
> > wheather panic() calls crash_kexec() before panic_notif
* Vivek Goyal wrote:
> On Mon, Mar 23, 2015 at 08:19:43AM +0100, Ingo Molnar wrote:
> >
> > * Baoquan He wrote:
> >
> > > CC more people ...
> > >
> > > On 03/07/15 at 01:31am, "Hatayama, Daisuke/畑山 大輔" wrote:
> > &g
* Masami Hiramatsu wrote:
> (2015/03/23 16:19), Ingo Molnar wrote:
> >
> > * Baoquan He wrote:
> >
> >> CC more people ...
> >>
> >> On 03/07/15 at 01:31am, "Hatayama, Daisuke/畑山 大輔" wrote:
> >>> The commit f06e5153f4ae2e2
* Vivek Goyal 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 like crash_k
* 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
> +--
* 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
>
* 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;
> + efi_con
* 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)
> > > >on
* 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 ("iom
* 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 efi_me
* 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 efi_me
* 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 current
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
* Takao Indoh 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 one)
please collect Ack
> AuthorDate: Thu, 9 Feb 2012 16:53:41 -0500
> > Committer: Ingo Molnar
> > 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
(&vmlist_lock);
> - for (p = vmlist; p; p = p->next) {
> - if (p->addr == (void __force *)addr)
> - break;
> - }
> - read_unlock(&vmlist_lock);
> + p = find_vm_area((void __force *)addr);
>
> if (!p) {
> printk(KERN_ERR "iounmap: bad address %p\n", addr);
For the x86 bits, provided it gets some good testing:
Acked-by: Ingo Molnar
Thanks,
Ingo
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
* Neil Horman <[EMAIL PROTECTED]> wrote:
> Ok, new patch attached, taking into account Andi's request for a
> cleaner method to implement single application quirks. I've spoken
> with Ben, who is continuing to retest, and reports that clean
> methodical testing results in success with this pa
* 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 t
* 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
===
--- linux-x86.q.or
* 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
http://lists.infradead.org/mailman/listinfo/
* 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_ke
* 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();
> >
* 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 platform
* 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 a
* 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
* Bernhard Walle <[EMAIL PROTECTED]> wrote:
> This patch series fixes the crashkernel reservation on NUMA machine.
> The regression was discovered by Dave Anderson <[EMAIL PROTECTED]>.
>
> The background is that on NUMA machines, reserve_bootmem_generic() is
> required instead of reserve_bootm
* 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_
* 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 tip/x86/
* 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/io
* 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 appar
* 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
kexec@l
* Bernhard Walle <[EMAIL PROTECTED]> wrote:
> * Greg KH <[EMAIL PROTECTED]> [2008-06-27 11:18]:
> >
> > Looks good, want me to take this through my tree (due to the firmware
> > core change)? If so, can you get an ack on the x86 portion from the
> > respective people as well?
>
> Well, the x86
* 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 whi
ng rejects to file
arch/ia64/hp/common/sba_iommu.c.rej
due 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
_
8 +++-
> 3 files changed, 13 insertions(+), 1 deletion(-)
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
* 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
> different
* Huang Ying <[EMAIL PROTECTED]> wrote:
> +/* Ftrace disable/restore without lock. Some synchronization mechanism
> + * must be used to prevent ftrace_enabled to be changed between
> + * disable/restore. */
use the proper comment style please:
/*
*
*/
> +static inline int __ftrace_enabled_sa
* Huang Ying <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-08-15 at 14:49 +0200, Ingo Molnar wrote:
> > * Huang Ying <[EMAIL PROTECTED]> wrote:
> >
> > > +/* Ftrace disable/restore without lock. Some synchronization mechanism
> > > + * must be used to
* Ken'ichi Ohmichi <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Since linux-2.6.27, kdump has failed on i386 sparsemem kernel.
> 1st-kernel gets a panic just before switching to 2nd-kernel.
>
> The cause is that a kernel accesses invalid mem_section by
> page_to_pfn(image->swap_page) at machine_kexe
* Neil Horman <[EMAIL PROTECTED]> wrote:
> Hey all-
> Theres a corner case in 32 bit x86 kdump at the moment. When
> the box panics via nmi, we call bust_spinlocks(1) to disable
> sensitivity to the console_sem (allowing us to print to the console in
> all cases), but we don't call cras
* 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 cons
* 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:
* 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/kdu
* 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 PROTECT
* Eduardo Habkost <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 06, 2008 at 08:14:45AM +0100, Ingo Molnar wrote:
> >
> > * Eduardo Habkost <[EMAIL PROTECTED]> wrote:
> >
> > > This reverts commit c7ffa6c26277b403920e2255d10df849bd613380.
> >
* 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
* 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 nmi_shootdo
* Eduardo Habkost <[EMAIL PROTECTED]> wrote:
> Hi, Ingo,
>
> This is yet another spin of the series to disable vmx on kdump and
> on emergency_restart, after some feedback from Avi.
this is going to interact with the KVM tree, wont it?
i think the best way forward would be to keep your change
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> * Eduardo Habkost <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Hi, Ingo,
>>>
>>> This is yet another spin of the series to disable vmx on kdump and
>>> on emergency_r
* Yoshihiro Takahashi 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.
>
> While nmi_shootdown_cp
* Sam Ravnborg wrote:
> On Thu, May 07, 2009 at 03:26:51PM -0700, H. Peter Anvin wrote:
> > From: H. Peter Anvin
> >
> > 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 page alignment datum
* Eric W. Biederman wrote:
> Cliff Wickman writes:
>
> > From: Cliff Wickman
> >
> > The copy of /proc/vmcore to a user buffer proceeds much faster
> > if the kernel addresses memory as cached.
> >
> > With this patch we have seen an increase in transfer rate from less than
> > 15MB/s to 80-4
* Ahmed S. Darwish 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?
> If not, wha
* Ahmed S. Darwish 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 up
> > a
>
* H. Peter Anvin wrote:
> On 01/26/2011 06:00 AM, Ingo Molnar wrote:
> >
> >I mean, use the warm reset vector to truly reset the box.
> >
> >Then, once a stable known-good kernel boots, *that* kernel can then recover
> >all the
> >log data which
* 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 merg
* 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
73 matches
Mail list logo
