On Mon, Feb 12 2024 at 12:44, Kirill A. Shutemov wrote:
> acpi_mp_wake_mailbox_paddr and acpi_mp_wake_mailbox initialized once
> during ACPI MADT init and never changed.
>
> Signed-off-by: Kirill A. Shutemov
> Acked-by: Kai Huang
Reviewed-by:
e use of ifdefs.
>
> There have been no functional changes.
>
> Signed-off-by: Kirill A. Shutemov
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
> Acked-by: Kai Huang
Reviewed-by: Thomas Gleixner
___
kexec mailing list
kexec@lists.infr
/13356251.uLZWGnKmhe@kreacher
> Acked-by: Kai Huang
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
Reviewed-by: Thomas Gleixner
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
specific convention and not covered by the
> ACPI specification.
>
> Signed-off-by: Kirill A. Shutemov
> Reviewed-by: Kai Huang
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
Reviewed-by: Thomas Gleixner
___
kexec mailing list
kexec@
up again after kexec.
>
> Signed-off-by: Kirill A. Shutemov
> Acked-by: Kai Huang
Reviewed-by: Thomas Gleixner
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
version 1, the structure includes the
> reset vector address. Clear and distinct naming helps to prevent any
> confusion.
>
> Signed-off-by: Kirill A. Shutemov
> Reviewed-by: Kai Huang
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
Reviewed-by: Thomas Gleixner
t; Signed-off-by: Kirill A. Shutemov
> Reviewed-by: Kai Huang
Reviewed-by: Thomas Gleixner
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Tue, Dec 05 2023 at 03:45, Kirill A. Shutemov wrote:
> MADT Multiprocessor Wakeup structure version 1 brings support of CPU
> offlining: BIOS provides a reset vector where the CPU has to jump to
> offline itself.
CPU has to jump to for offlining itself.
> The new TEST mailbox command can be
On Tue, Dec 05 2023 at 03:45, Kirill A. Shutemov wrote:
> ACPI MADT doesn't allow to offline CPU after it got woke up. It limits
to offline a CPU after it was onlined. This limits kexec: ...
> kexec: the second kernel won't be able to use more than one CPU.
... one CPU, which is enough to cover
On Tue, Dec 05 2023 at 03:45, Kirill A. Shutemov wrote:
> ACPI MADT doesn't allow to offline CPU after it got woke up.
>
> Currently hotplug prevented based on the confidential computing
Currently CPU hotplug is prevented...
Other than that:
Reviewed-by: Thomas
On Tue, Dec 05 2023 at 03:44, Kirill A. Shutemov wrote:
>
> +static bool cpu_hotplug_offline_disabled;
__ro_after_init?
Other than that:
Reviewed-by: Thomas Gleixner
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infrade
On Fri, Oct 20 2023 at 18:12, Kirill A. Shutemov wrote:
> MADT Multiprocessor Wakeup structure version 1 brings support of CPU
> offlining: BIOS provides a reset vector where the CPU has to jump to
> offline itself. The new TEST mailbox command can be used to test the CPU
> offlined successfully
On Mon, Oct 23 2023 at 22:07, Kai Huang wrote:
> On Mon, 2023-10-23 at 18:31 +0300, kirill.shute...@linux.intel.com wrote:
>> On Mon, Oct 23, 2023 at 09:30:59AM +, Huang, Kai wrote:
>> > IMHO it's a little bit odd to have two mechanisms in place, even in this
>> > middle
>> > state patch. Is
On Fri, Oct 20 2023 at 18:12, Kirill A. Shutemov wrote:
Subject: cpu/hotplug: ...
> ACPI MADT doesn't allow to offline CPU after it got woke up.
ACPI MADT is a table ...
This is about the MADT mailbox wakeup method, right?
> Currently offlining hotplug prevented based on the confidential
is
On Thu, Oct 05 2023 at 16:13, Kirill A. Shutemov wrote:
>
> + /* Disable CPU onlining/offlining */
That's not what the function does.
> + cpu_hotplug_not_supported();
Thanks,
tglx
___
kexec mailing list
kexec@lists.infradead.org
On Thu, Oct 05 2023 at 16:13, Kirill A. Shutemov wrote:
> The function cpu_hotplug_not_supported() can be called to indicate that
> CPU hotplug should be disabled. It does not prevent the initial bring up
> of the CPU, but it stops subsequent offlining.
This tells me what the patch is doing, but
On Thu, Jul 06 2023 at 14:44, Baokun Li wrote:
> On 2023/7/5 16:59, Thomas Gleixner wrote:
>> +/*
>> + * If this is a crash stop which does not execute on the boot CPU,
>> + * then this cannot use the INIT mechanism because INIT to the boot
>> + *
On Mon, Jul 03 2023 at 11:44, Baokun Li wrote:
> When I manually trigger panic in a qume x86 VM with
>
> `echo c > /proc/sysrq-trigger`,
>
> I find that the VM will probably reboot directly, but the
> PANIC_TIMEOUT is 0.
> This prevents us from exporting the vmcore via panic, and even
On Tue, Jun 13 2023 at 14:58, Eric DeVolder wrote:
> On 6/13/23 10:24, Eric DeVolder wrote:
>> On 6/13/23 03:03, Greg KH wrote:
>>> All of these #ifdefs should all be removed and instead use the
>>> is_visible() callback to determine if the attribute is shown or not,
>>> using the IS_ENABLED()
On Fri, May 12 2023 at 17:13, Matthew Garrett wrote:
> On Fri, May 12, 2023 at 03:24:04PM +0200, Thomas Gleixner wrote:
>> On Fri, May 12 2023 at 12:28, Matthew Garrett wrote:
>> > Unless we assert that SHA-1 events are unsupported, it seems a bit odd
>> > to force
On Thu, May 04 2023 at 14:50, Ross Philipson wrote:
>
> +#ifdef CONFIG_SECURE_LAUNCH
> +
> +static atomic_t first_ap_only = {1};
ATOMIC_INIT(1) if at all.
> +
> +/*
> + * Called to fix the long jump address for the waiting APs to vector to
> + * the correct startup location in the Secure
On Thu, May 04 2023 at 14:50, Ross Philipson wrote:
> +
> +/* CPUID: leaf 1, ECX, SMX feature bit */
> +#define X86_FEATURE_BIT_SMX (1 << 6)
> +
> +/* Can't include apiddef.h in asm */
Why not? All it needs is a #ifndef __ASSEMBLY__ guard around the C parts.
> +#define XAPIC_ENABLE (1 << 11)
On Thu, May 04 2023 at 14:50, Ross Philipson wrote:
> The routine slaunch_setup is called out of the x86 specific setup_arch
Can you please make functions visible in changelogs by appending (),
i.e. setup_arch() ?
See https://www.kernel.org/doc/html/latest/process/maintainer-tip.html
for further
On Fri, May 12 2023 at 12:28, Matthew Garrett wrote:
> On Fri, May 12, 2023 at 01:18:45PM +0200, Ard Biesheuvel wrote:
>> On Fri, 12 May 2023 at 13:04, Matthew Garrett wrote:
>> >
>> > On Tue, May 09, 2023 at 06:21:44PM -0700, Eric Biggers wrote:
>> >
>> > > SHA-1 is insecure. Why are you still
On Thu, May 04 2023 at 14:50, Ross Philipson wrote:
> +KASLR Configuration
> +---
> +
> +Secure Launch does not interoperate with KASLR. If possible, the MLE should
> be
> +built with KASLR disabled::
Why?
> + "Processor type and features" -->
> + "Build a relocatable
On Wed, May 03 2023 at 18:41, Eric DeVolder wrote:
> In the patch 'kexec: exclude elfcorehdr from the segment digest'
See reply to 8/8
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 53bab123a8ee..80538524c494 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2119,6
On Wed, May 03 2023 at 18:41, Eric DeVolder wrote:
> This patch is dependent upon the patch 'crash: change
Seriously? You send a patch series which is ordered in itself and then
tell in the changelog of patch 8/8 that it depends on patch 7/8?
This information is complete garbage once the patches
On Mon, Feb 13 2023 at 10:10, Sourabh Jain wrote:
> The sysconf document says _SC_NPROCESSORS_CONF is processors configured,
> isn't that equivalent to possible CPUs?
glibc tries to evaluate that in the following order:
1) /sys/devices/system/cpu/cpu*
That's present CPUs not possible
Eric!
On Tue, Feb 07 2023 at 11:23, Eric DeVolder wrote:
> On 2/1/23 05:33, Thomas Gleixner wrote:
>
> So my latest solution is introduce two new CPUHP states,
> CPUHP_AP_ELFCOREHDR_ONLINE
> for onlining and CPUHP_BP_ELFCOREHDR_OFFLINE for offlining. I'm open to
On Mon, Feb 06 2023 at 13:42, Sourabh Jain wrote:
> On 01/02/23 17:03, Thomas Gleixner wrote:
>> Also in case of loading the crash kernel in the situation where not all
>> present CPUs are online (think boot time SMT disable) then your
>> resulting crash image will con
Eric!
On Tue, Jan 31 2023 at 17:42, Eric DeVolder wrote:
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -366,6 +366,14 @@ int crash_prepare_elf64_headers(struct kimage *image,
> struct crash_mem *mem,
>
> /* Prepare one phdr of type PT_NOTE for each present CPU */
>
Eric!
On Wed, Jan 18 2023 at 16:35, Eric DeVolder wrote:
> CPU and memory change notifications are received in order to
> regenerate the elfcorehdr.
>
> To support cpu hotplug, a callback is registered to capture the
> CPUHP_AP_ONLINE_DYN online and offline events via
>
On Tue, Dec 20 2022 at 13:34, Baoquan He wrote:
> This reverts commit 43931d350f30c6cd8c2f498d54ef7d65750abc92.
>
> On kvm guest with 4 cpus deployed, when adding 'nr_cpus=2' to normal
> kernel's cmdline, and triggering crash to jump to kdump kernel, kdump
> kernel will stably hang. Reverting
On Tue, Dec 20 2022 at 13:41, Baoquan He wrote:
> On one intel bare metal system, I can randomly reproduce the kdump hang
> as below with tick_periodic call trace. Attach the kernel config for
> reference.
This has absolutely nothing to do with x2apic IPI shorthands
> [0.045980] Spurious
On Tue, May 10 2022 at 11:38, Pingfan Liu wrote:
> On Mon, May 09, 2022 at 12:55:21PM +0200, Thomas Gleixner wrote:
>> On Mon, May 09 2022 at 12:13, Pingfan Liu wrote:
>> > The following code chunk repeats in both
>> > migrate_to_reboot_cpu() and smp_shutdown_nonbo
On Mon, May 09 2022 at 12:55, Thomas Gleixner wrote:
> On Mon, May 09 2022 at 12:13, Pingfan Liu wrote:
>> -cpu_hotplug_enable();
>
> This is tinkering at best. Can we please sit down and rethink this whole
> machinery instead of applying random duct tape to it?
On Mon, May 09 2022 at 12:13, Pingfan Liu wrote:
> The following code chunk repeats in both
> migrate_to_reboot_cpu() and smp_shutdown_nonboot_cpus():
>
> if (!cpu_online(primary_cpu))
> primary_cpu = cpumask_first(cpu_online_mask);
>
> This is due to a breakage like the
On Wed, Jun 16 2021 at 10:51, Ondrej Mosnacek wrote:
> diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
> index bda73cb7a044..c43a13241ae8 100644
> --- a/arch/x86/mm/testmmiotrace.c
> +++ b/arch/x86/mm/testmmiotrace.c
> @@ -116,7 +116,7 @@ static void
On Mon, May 17 2021 at 22:33, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> These are all handled correctly when calling the native
> system call entry point, so remove the special cases.
> arch/x86/entry/syscall_x32.c | 2 ++
> arch/x86/entry/syscalls/syscall_32.tbl| 6 ++--
On Fri, Apr 16 2021 at 17:13, Mike Galbraith wrote:
> On Fri, 2021-04-16 at 16:44 +0200, Borislav Petkov wrote:
>> On Fri, Apr 16, 2021 at 03:16:07PM +0200, Mike Galbraith wrote:
>> > On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote:
>> > >
>> > > Please be more verbose and structure your
On Tue, Nov 17 2020 at 12:19, David Woodhouse wrote:
> On Tue, 2020-11-17 at 10:53 +0100, Thomas Gleixner wrote:
>> But that does not solve the problem either simply because then the IOMMU
>> will catch the rogue MSIs and you get an interrupt storm on the IOMMU
>> error inte
On Mon, Nov 16 2020 at 19:06, Eric W. Biederman wrote:
> Bjorn Helgaas writes:
> My two top candidates are poking the IOMMUs early to shut things off,
> and figuring out if we can delay enabling interrupts until we have
> initialized pci.
Keeping interrupts disabled post PCI initialization would
On Sun, Nov 15 2020 at 18:01, Lukas Wunner wrote:
> On Sun, Nov 15, 2020 at 04:11:43PM +0100, Thomas Gleixner wrote:
>> Unfortunately there is no way to tell the APIC "Mask vector X" and the
>> dump kernel does neither know which device it comes from nor does it
>>
On Sun, Nov 15 2020 at 08:29, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
> For ordinary irqs you can have this with level triggered irqs
> and the kernel has code that will shutdown the irq at the ioapic
> level. Then the kernel continues by polling the irq
Bjorn,
On Sat, Nov 14 2020 at 14:39, Bjorn Helgaas wrote:
> On Sat, Nov 14, 2020 at 12:40:10AM +0100, Thomas Gleixner wrote:
>> On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote:
>> > On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote:
>> >> pci_device_shutdown
Bjorn,
On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote:
> On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote:
>> pci_device_shutdown() still clears the Bus Master Enable bit if we're
>> doing a kexec and the device is in D0-D3hot, which should also disable
>> MSI/MSI-X. W
Bjorn,
On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote:
> On Fri, Nov 06, 2020 at 10:14:14AM -0300, Guilherme G. Piccoli wrote:
>> On 23/10/2018 14:03, Bjorn Helgaas wrote:
> I guess Thomas' patch [2] (from thread [1]) doesn't solve this
> problem?
No. As I explained in [1] patch from [2]
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending
On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote:
> On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
> [For now my patch just uses kmap_atomic().]
>
> I've not looked at all of the patches
On Wed, Oct 28 2020 at 14:02, Pingfan Liu wrote:
> On Tue, Oct 27, 2020 at 3:59 AM Thomas Gleixner wrote:
>> Also Liu's patch only works if:
>>
>> 1) CONFIG_IRQ_TIME_ACCOUNTING is enabled
>
> I wonder whether it can not be a default option or not
On Mon, Oct 26 2020 at 17:28, Guilherme Piccoli wrote:
> On Mon, Oct 26, 2020 at 4:59 PM Thomas Gleixner wrote:
>> It gets flooded right at the point where the crash kernel enables
>> interrupts in start_kernel(). At that point there is no device driver
>> and no interupt r
On Mon, Oct 26 2020 at 12:06, Guilherme Piccoli wrote:
> On Sun, Oct 25, 2020 at 8:12 AM Pingfan Liu wrote:
>
> Some time ago (2 years) we faced a similar issue in x86-64, a hard to
> debug problem in kdump, that eventually was narrowed to a buggy NIC FW
> flooding IRQs in kdump kernel, and no
On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote:
> I hit a irqflood bug on powerpc platform, and two years ago, on a x86
> platform.
> When the bug happens, the kernel is totally occupies by irq. Currently, there
> may be nothing or just soft lockup warning showed in console. It is better
> to
Petr,
On Thu, Aug 20 2020 at 12:43, Petr Mladek wrote:
> On Thu 2020-08-20 12:30:55, Thomas Gleixner wrote:
>> Good. So I suggest that I apply that on top of rc1 somewhere in tip and
>> tag the top commit. So you can pull that tag into your printk branch and
>> go wild.
Petr,
On Thu, Aug 20 2020 at 10:47, Petr Mladek wrote:
> The interface is perfectly fine for printk() needs.
Good. So I suggest that I apply that on top of rc1 somewhere in tip and
tag the top commit. So you can pull that tag into your printk branch and
go wild.
Thanks,
tglx
printk intends to store various timestamps (MONOTONIC, REALTIME, BOOTTIME)
to make correlation of dmesg accross different machines easier.
The NMI safe timekeeper allows to retrieve these timestamps from any
context, but it lacks a few things:
1) The nmi safe accessors are not providing time
-off-by: Thomas Gleixner
---
kernel/time/timekeeping.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -53,6 +53,9 @@ static struct {
static DEFINE_RAW_SPINLOCK(timekeeper_lock);
static
by
using sched clock in a similar way as during early boot. But it's not as
trivial as on early boot because it needs some careful protection
against the clock monotonic timestamp jumping backwards on resume.
Signed-off-by: Thomas Gleixner
---
include/linux/timekeeping.h | 15
Sergey Senozhatsky writes:
> On (20/08/11 15:02), Petr Mladek wrote:
>> There is still the alternative to print all three timestamps regularly
>> for those interested. It is less user convenient but much easier
>> to maintain.
>
> Yes, that's a nice alternative.
It's trivial on the kernel side,
Petr Mladek writes:
> On Tue 2020-08-11 12:40:22, Orson Zhai wrote:
>> This is an updated version which comes from patch [1] written by Thomas
>> and suggestion [2] about VMCORE_INFO given by Linus.
All of that want's to be properly distangled into seperate patches.
>> This patch has been
On Thu, 8 Aug 2019, Pingfan Liu wrote:
> On Wed, Aug 7, 2019 at 9:07 PM Thomas Gleixner wrote:
> >
> [...]
> > > > >
> > > > > *** Back ground ***
> > > > >
> > > > > On x86 it's required to have all logical CPUs set CR4.MCE
On Wed, 7 Aug 2019, Pingfan Liu wrote:
> On Wed, Aug 07, 2019 at 11:00:41AM +0800, Dave Young wrote:
> > Add Tony and Xunlei in cc.
> > On 08/05/19 at 04:58pm, Pingfan Liu wrote:
> > > This series include two related groups:
> > > [1-3/4]: protect nr_cpus from rebooting by broadcast mce
> > >
On Fri, 25 Jan 2019, Baoquan He wrote:
> Add two bit fields XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel.
These are not bit fields. These are simple bits.
> Bit XLF_5LEVEL indicates if 5-level related code is contained
> in this kernel.
> Bit XLF_5LEVEL_ENABLED indicates if
On Tue, 4 Sep 2018, H. Peter Anvin wrote:
> On 09/04/18 01:42, Kirill A. Shutemov wrote:
> >
> > Switching between 4- and 5-level paging modes (in either direction)
> > requires paing disabling. It means the code that does the switching has to
> > be under 4G otherwise we would lose control.
> >
ies is a pre-cursor to another AMD processor feature called
> Secure Encrypted Virtualization (SEV). The support for SEV will build upon
> the SME support and will be submitted later. Details on SEV can be found
> in the links below.
Well done series. Thanks to all people involved, espec
On Wed, 21 Jun 2017, Tom Lendacky wrote:
> On 6/21/2017 10:38 AM, Thomas Gleixner wrote:
> > /*
> > * Sanitize CPU configuration and retrieve the modifier
> > * for the initial pgdir entry which will be programmed
> > * into CR3. Depends on enabled
On Wed, 21 Jun 2017, Tom Lendacky wrote:
> On 6/21/2017 2:16 AM, Thomas Gleixner wrote:
> > Why is this an unconditional function? Isn't the mask simply 0 when the MEM
> > ENCRYPT support is disabled?
>
> I made it unconditional because of the call from head_64.S. I can'
On Fri, 16 Jun 2017, Tom Lendacky wrote:
>
> +#ifndef pgprot_encrypted
> +#define pgprot_encrypted(prot) (prot)
> +#endif
> +
> +#ifndef pgprot_decrypted
That looks wrong. It's not decrypted it's rather unencrypted, right?
Thanks,
tglx
On Fri, 16 Jun 2017, Tom Lendacky wrote:
> diff --git a/arch/x86/include/asm/mem_encrypt.h
> b/arch/x86/include/asm/mem_encrypt.h
> index a105796..988b336 100644
> --- a/arch/x86/include/asm/mem_encrypt.h
> +++ b/arch/x86/include/asm/mem_encrypt.h
> @@ -15,16 +15,24 @@
>
> #ifndef __ASSEMBLY__
On Fri, 16 Jun 2017, Tom Lendacky wrote:
> Currently there is a check if the address being mapped is in the ISA
> range (is_ISA_range()), and if it is then phys_to_virt() is used to
> perform the mapping. When SME is active, however, this will result
> in the mapping having the encryption bit
On Fri, 16 Jun 2017, Tom Lendacky wrote:
>
> +config ARCH_HAS_MEM_ENCRYPT
> + def_bool y
> + depends on X86
That one is silly. The config switch is in the x86 KConfig file, so X86 is
on. If you intended to move this to some generic place outside of
x86/Kconfig then this should be
On Fri, 7 Oct 2016, Jiri Olsa wrote:
> On Thu, Oct 06, 2016 at 11:25:43AM -0400, Prarit Bhargava wrote:
> > I thought about doing this but it seems like every time some driver uses
> > topology_logical_package_id() the driver would have to replicate the error
> > checking code.
>
> hm, unless we
On Tue, 4 Oct 2016, Prarit Bhargava wrote:
> On 10/04/2016 06:58 AM, Thomas Gleixner wrote:
> > While it is the right thing to initialize the package map in that case, it
> > still papers over a robustness issue in the uncore code, which needs to be
> > fixed first.
>
>
On Tue, 4 Oct 2016, Jiri Olsa wrote:
> On Tue, Oct 04, 2016 at 12:58:04PM +0200, Thomas Gleixner wrote:
> > > pmu->boxes[pkg] is garbage because pkg was returned as 0x.
> >
> > And that's what needs to be fixed in the first place.
>
> right, I'll check on th
On Mon, 3 Oct 2016, Prarit Bhargava wrote:
> BUG: unable to handle kernel paging request at 00841f1f
> IP: [] uncore_change_context+0xd4/0x180
...
> [] ? uncore_cpu_starting+0x130/0x130
> [] uncore_event_cpu_online+0x6c/0x80
> [] cpuhp_invoke_callback+0x49/0x100
> []
On Wed, 20 Jul 2016, b...@redhat.com wrote:
> On 07/20/16 at 03:54am, Wei, Jiangang wrote:
>
> > In fact, Eric and Ingo suggested that "it should be fixed in the bootup
> > path of the dump kernel, not the crash kernel reboot path", which is
> > convincing and reasonable.
>
> Well this patch
On Wed, 14 Oct 2015, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > On Fri, 25 Sep 2015, Hidehiro Kawai wrote:
> >
> > > This patch introduces new boot option "noextnmi" which disables
> > > external NMI. This option is useful for the dump capture kernel
> > > so that an HA application or administrator
t;
> Currently, only x86 supports this option.
You might add that is can be used for debugging purposes as
well. External NMIs can be their own source of trouble. :)
> Signed-off-by: Hidehiro Kawai <hidehiro.kawai...@hitachi.com>
> Cc: Thomas Gleixner <t...@linutronix.de>
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 just going to
> > provide a configurable
On Fri, 26 Oct 2007, Hiroshi Shimamoto wrote:
Added Venki to CC
I'm now testing crash on 32bit, but there is an issue before
applying the patches. My machine stopped at checking 'hlt'
after kexec, showing below message.
CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
Checking 'hlt'
On Fri, 19 Oct 2007, Hiroshi Shimamoto wrote:
Hi,
I made patches to unify crash_32/64.c.
There are three patches;
1. add lapic_shutdown for x86_64
2. add safe_smp_processor_id for x86_64
3. unify crash_32/64.c
I'm not sure that it's good to split to these patches.
It's fine. So the
81 matches
Mail list logo
