Searched hist:"5211 a242d0cbdded372aee59da18f80552b0a80a" (Results 1 – 4 of 4) sorted by relevance
/openbmc/linux/arch/x86/kernel/ |
H A D | dumpstack.c | diff 5211a242d0cbdded372aee59da18f80552b0a80a Wed Jun 24 16:32:11 CDT 2009 Kurt Garloff <garloff@suse.de> x86: Add sysctl to allow panic on IOCK NMI error
This patch introduces a new sysctl:
/proc/sys/kernel/panic_on_io_nmi
which defaults to 0 (off).
When enabled, the kernel panics when the kernel receives an NMI caused by an IO error.
The IO error triggered NMI indicates a serious system condition, which could result in IO data corruption. Rather than contiuing, panicing and dumping might be a better choice, so one can figure out what's causing the IO error.
This could be especially important to companies running IO intensive applications where corruption must be avoided, e.g. a bank's databases.
[ SuSE has been shipping it for a while, it was done at the request of a large database vendor, for their users. ]
Signed-off-by: Kurt Garloff <garloff@suse.de> Signed-off-by: Roberto Angelino <robertangelino@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> LKML-Reference: <20090624213211.GA11291@kroah.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
H A D | traps.c | diff 5211a242d0cbdded372aee59da18f80552b0a80a Wed Jun 24 16:32:11 CDT 2009 Kurt Garloff <garloff@suse.de> x86: Add sysctl to allow panic on IOCK NMI error
This patch introduces a new sysctl:
/proc/sys/kernel/panic_on_io_nmi
which defaults to 0 (off).
When enabled, the kernel panics when the kernel receives an NMI caused by an IO error.
The IO error triggered NMI indicates a serious system condition, which could result in IO data corruption. Rather than contiuing, panicing and dumping might be a better choice, so one can figure out what's causing the IO error.
This could be especially important to companies running IO intensive applications where corruption must be avoided, e.g. a bank's databases.
[ SuSE has been shipping it for a while, it was done at the request of a large database vendor, for their users. ]
Signed-off-by: Kurt Garloff <garloff@suse.de> Signed-off-by: Roberto Angelino <robertangelino@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> LKML-Reference: <20090624213211.GA11291@kroah.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
/openbmc/linux/include/linux/ |
H A D | kernel.h | diff 5211a242d0cbdded372aee59da18f80552b0a80a Wed Jun 24 16:32:11 CDT 2009 Kurt Garloff <garloff@suse.de> x86: Add sysctl to allow panic on IOCK NMI error
This patch introduces a new sysctl:
/proc/sys/kernel/panic_on_io_nmi
which defaults to 0 (off).
When enabled, the kernel panics when the kernel receives an NMI caused by an IO error.
The IO error triggered NMI indicates a serious system condition, which could result in IO data corruption. Rather than contiuing, panicing and dumping might be a better choice, so one can figure out what's causing the IO error.
This could be especially important to companies running IO intensive applications where corruption must be avoided, e.g. a bank's databases.
[ SuSE has been shipping it for a while, it was done at the request of a large database vendor, for their users. ]
Signed-off-by: Kurt Garloff <garloff@suse.de> Signed-off-by: Roberto Angelino <robertangelino@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> LKML-Reference: <20090624213211.GA11291@kroah.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
/openbmc/linux/kernel/ |
H A D | sysctl.c | diff 5211a242d0cbdded372aee59da18f80552b0a80a Wed Jun 24 16:32:11 CDT 2009 Kurt Garloff <garloff@suse.de> x86: Add sysctl to allow panic on IOCK NMI error
This patch introduces a new sysctl:
/proc/sys/kernel/panic_on_io_nmi
which defaults to 0 (off).
When enabled, the kernel panics when the kernel receives an NMI caused by an IO error.
The IO error triggered NMI indicates a serious system condition, which could result in IO data corruption. Rather than contiuing, panicing and dumping might be a better choice, so one can figure out what's causing the IO error.
This could be especially important to companies running IO intensive applications where corruption must be avoided, e.g. a bank's databases.
[ SuSE has been shipping it for a while, it was done at the request of a large database vendor, for their users. ]
Signed-off-by: Kurt Garloff <garloff@suse.de> Signed-off-by: Roberto Angelino <robertangelino@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> LKML-Reference: <20090624213211.GA11291@kroah.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|