From: Zhenzhong Duan
When add crashkernel=2M-256M, kernel don't give any warning.
This is misleading sometimes.
Signed-off-by: Zhenzhong Duan
---
kernel/kexec.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 7b08867..0a6d147 100
On 03/13/2012 08:21 AM, Simon Horman wrote:
On Thu, Mar 08, 2012 at 02:39:38PM +0800, Cong Wang wrote:
Currently the debugging code is under #ifdef DEBUG, which
means when we want to debug, we have to re-compile the source
code with -DDEBUG. This is not convenient, we want to have
a generic --de
Subject: [PATCH 1/3] boot: fortify early_idt_handlers definition
From: Fernando Luis Vazquez Cao
The current definition is too brittle which makes it easy to screw things up
when modifying the code. Add some comments while at it.
Signed-off-by: Fernando Luis Vazquez Cao
---
diff -urNp linux
Subject: [PATCH 2/3] boot: ignore early NMIs
From: Fernando Luis Vazquez Cao
NMIs very early in the boot process are rarely critical (usually
it just means that there was a spurious bit flip somewhere in the
hardware, or that this is a kdump kernel and we received an NMI
generated in the previ
On 03/13/2012 05:16 AM, H. Peter Anvin wrote:
On 03/12/2012 01:04 PM, H. Peter Anvin wrote:
On 03/12/2012 01:01 PM, Eric W. Biederman wrote:
The basic problem is which source do we block this at? How many
sources are their? And architecturally last I looked x86 no longer
has a NMI disable EFI
On 03/13/2012 03:40 AM, H. Peter Anvin wrote:
On 03/11/2012 11:14 PM, Fernando Luis Vázquez Cao wrote:
The thing is that we want to avoid playing with hardware in the kdump
reboot patch when we can avoid it, the premise being that it cannot
be accessed without risking a lockup or worse (as the
Subject: [PATCH 3/3] boot: add early NMI counter
From: Fernando Luis Vazquez Cao
We currently ignore early NMIs but it would be nice to be able to
know whether they actually occurred.
This patch adds an early NMI counter, whose count is moved over to
the per-cpu NMI counter before the kernel
On Thu, Mar 08, 2012 at 02:39:38PM +0800, Cong Wang wrote:
> Currently the debugging code is under #ifdef DEBUG, which
> means when we want to debug, we have to re-compile the source
> code with -DDEBUG. This is not convenient, we want to have
> a generic --debug option so that we can enable debugg
On Mon, Mar 12, 2012 at 03:14:20PM +0900, Fernando Luis Vázquez Cao wrote:
[..]
> The thing is that we want to avoid playing with hardware in the kdump
> reboot patch when we can avoid it, the premise being that it cannot
> be accessed without risking a lockup or worse (as the deadlock accessing
>
On Sun, Mar 11, 2012 at 10:49:23PM -0700, H. Peter Anvin wrote:
> On 03/11/2012 10:43 PM, Fernando Luis Vázquez Cao wrote:
>
> >
> > To tackle this issue we can either stop the hardlockup detector
> > or disable the LAPIC (the NMIs needed by x86's hardlockup detector
> > are generated using perfo
Vivek Goyal writes:
> On Mon, Mar 12, 2012 at 03:14:20PM +0900, Fernando Luis Vázquez Cao wrote:
>
> [..]
>> The thing is that we want to avoid playing with hardware in the kdump
>> reboot patch when we can avoid it, the premise being that it cannot
>> be accessed without risking a lockup or wors
On 03/10/2012 05:52 AM, H. Peter Anvin wrote:
Is there a reason to not just simply block these NMIs during the kexec
sequence?
Ok, some background:
In the reboot path to the kdump kernel we disable local interrupts
and the APICs in native_machine_crash_shutdown() and reset the IDT
in machine_k
On 03/12/2012 02:49 PM, H. Peter Anvin wrote:
On 03/11/2012 10:43 PM, Fernando Luis Vázquez Cao wrote:
To tackle this issue we can either stop the hardlockup detector
or disable the LAPIC (the NMIs needed by x86's hardlockup detector
are generated using performance counters in the LAPIC), leavi
Okay, I need to ask this...
Is there a reason to not just simply block these NMIs during the kexec
sequence?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
kexec mailing lis
On 03/11/2012 10:43 PM, Fernando Luis Vázquez Cao wrote:
>
> To tackle this issue we can either stop the hardlockup detector
> or disable the LAPIC (the NMIs needed by x86's hardlockup detector
> are generated using performance counters in the LAPIC), leaving
> the I/O APICs untouched. The second
On Thu, Mar 08, 2012 at 07:29:25PM +0200, Maxim Kammerer wrote:
> Hi,
>
> In kexec/arch/i386/x86-linux-setup.c:setup_linux_vesafb():
>
> fprintf(stderr, "%s: %dx%dx%d @ %lx +%x\n", __FUNCTION__,
> var.xres, var.yres, var.bits_per_pixel,
> fix.smem_start, fix.smem_len);
>
> Th
On 03/12/2012 01:04 PM, H. Peter Anvin wrote:
> On 03/12/2012 01:01 PM, Eric W. Biederman wrote:
>>
>> The basic problem is which source do we block this at? How many
>> sources are their? And architecturally last I looked x86 no longer
>> has a NMI disable EFI and similar systems want to get awa
On 03/11/2012 11:14 PM, Fernando Luis Vázquez Cao wrote:
>
> The thing is that we want to avoid playing with hardware in the kdump
> reboot patch when we can avoid it, the premise being that it cannot
> be accessed without risking a lockup or worse (as the deadlock accessing
> the I/O APIC showed)
On Thu, 08 Mar 2012 at 17:29 GMT, Maxim Kammerer wrote:
> Hi,
>
> In kexec/arch/i386/x86-linux-setup.c:setup_linux_vesafb():
>
> fprintf(stderr, "%s: %dx%dx%d @ %lx +%x\n", __FUNCTION__,
> var.xres, var.yres, var.bits_per_pixel,
> fix.smem_start, fix.smem_len);
>
> This message
On 03/09/2012 01:35 AM, Eric W. Biederman wrote:
I am fine with your approach. I suggest a big fat comment mentioning
the 10 byte requirement and the register requirement.
Neither one is locally obvious which makes it easy to goof when
modifying the code.
Done.
Doing something less brittl
On 03/12/2012 01:01 PM, Eric W. Biederman wrote:
>
> The basic problem is which source do we block this at? How many
> sources are their? And architecturally last I looked x86 no longer
> has a NMI disable EFI and similar systems want to get away without
> a CMOS legacy clock because designers s
On 03/12/2012 12:02 PM, Eric W. Biederman wrote:
>
> Disabling NMI generation in the LAPIC is fine, and for the short term
> I don't even have a problem with disabling the entire LAPIC as all of
> our platforms seem to have code for completely reprogramming it.
>
> At the same time there have bee
"H. Peter Anvin" writes:
> On 03/11/2012 11:14 PM, Fernando Luis Vázquez Cao wrote:
>>
>> The thing is that we want to avoid playing with hardware in the kdump
>> reboot patch when we can avoid it, the premise being that it cannot
>> be accessed without risking a lockup or worse (as the deadlock
On Mon, Mar 12, 2012 at 12:02:06PM -0700, Eric W. Biederman wrote:
[..]
>
> > I personally think that disabling LAPIC is reasonably practical solution
> > to the problem until and unless somebody shows that it deadlocks
> > easily.
>
> Disabling NMI generation in the LAPIC is fine, and for the sh
24 matches
Mail list logo
