Skip to contentSkip to conversation

ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support

RFC In review Huang Ying 2 participants 3 messages Dec 15, 2010 – Dec 16, 2010

Subsystems (7)
lore
Share & tools
lore

Huang Ying

author
#0 lore raw

RFC 1/1 ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support

Generic Hardware Error Source provides a way to report platform hardware errors (such as that from chipset). It works in so called "Firmware First" mode, that is, hardware errors are reported to firmware firstly, then reported to Linux by firmware. This way, some non-standard hardware error registers or non-standard hardware link can be checked by firmware to produce more valuable hardware error information for Linux.

This patch adds POLL/IRQ/NMI notification types support.

Because the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, IRQ or timer handler, but general ioremap can not be used in atomic context, so a special version of atomic ioremap is implemented for that.

Known issue:

- Error information can not be printed for recoverable errors notified via NMI, because printk is not NMI-safe. Will fix this via delay printing to IRQ context via irq_work or make printk NMI-safe.

---
 arch/x86/kernel/acpi/boot.c |    1 
 arch/x86/kernel/dumpstack.c |    1 
 drivers/acpi/apei/ghes.c    |  428 ++++++++++++++++++++++++++++++++++----------
 kernel/panic.c              |    1 
 lib/ioremap.c               |    2 
 mm/vmalloc.c                |    1 
 6 files changed, 345 insertions(+), 89 deletions(-)
arch/x86/kernel/acpi/boot.c +1 -0
@@ -504,6 +504,7 @@ int acpi_gsi_to_irq(u32 gsi, unsigned in
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
 
 int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
 {
arch/x86/kernel/dumpstack.c +1 -0
@@ -240,6 +240,7 @@ unsigned __kprobes long oops_begin(void)
 	bust_spinlocks(1);
 	return flags;
 }
+EXPORT_SYMBOL_GPL(oops_begin);
 
 void __kprobes oops_end(unsigned long flags, struct pt_regs *regs, int signr)
 {
drivers/acpi/apei/ghes.c +339 -89

587 lines not on this page · raw message

kernel/panic.c +1 -0
@@ -34,6 +34,7 @@ static int pause_on_oops_flag;
 static DEFINE_SPINLOCK(pause_on_oops_lock);
 
 int panic_timeout;
+EXPORT_SYMBOL_GPL(panic_timeout);
 
 ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
 
lib/ioremap.c +2 -0
@@ -9,6 +9,7 @@
 #include <linux/mm.h>
 #include <linux/sched.h>
 #include <linux/io.h>
+#include <linux/module.h>
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>
 
@@ -90,3 +91,4 @@ int ioremap_page_range(unsigned long add
 
 	return err;
 }
+EXPORT_SYMBOL_GPL(ioremap_page_range);
mm/vmalloc.c +1 -0
@@ -1175,6 +1175,7 @@ void unmap_kernel_range_noflush(unsigned
 {
 	vunmap_page_range(addr, addr + size);
 }
+EXPORT_SYMBOL_GPL(unmap_kernel_range_noflush);
 
 /**
  * unmap_kernel_range - unmap kernel VM area and flush cache and TLB
reviewer
#1 lore raw
Quoted 10 lines

Because the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, IRQ or timer handler, but general ioremap can not be used in atomic context, so a special version of atomic ioremap is implemented for that.

Known issue:

- Error information can not be printed for recoverable errors notified via NMI, because printk is not NMI-safe. Will fix this via delay printing to IRQ context via irq_work or make printk NMI-safe.

Would it be possible to defer the "ioremap" to a work queue too? Then we wouldn't need the special versions of ioremap.

-Tony

author
#2 lore raw
Quoted 5 lines · Tony
Quoted 5 lines

Because the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, IRQ or timer handler, but general ioremap can not be used in atomic context, so a special version of atomic ioremap is implemented for that.

Quoted 8 lines
Quoted 5 lines

Known issue:

- Error information can not be printed for recoverable errors notified via NMI, because printk is not NMI-safe. Will fix this via delay printing to IRQ context via irq_work or make printk NMI-safe.

Would it be possible to defer the "ioremap" to a work queue too? Then we wouldn't need the special versions of ioremap.

For recoverable error, we can defer the "ioremap" to a work queue, because most recoverable action can take place only there in fact. But for fatal error, I think it is too late to be processed in a work queue, we need go panic as soon as possible to prevent data corruption.

Best Regards,
Huang Ying