lkml.org 
[lkml]   [1996]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux & ECC memory

>>From asm/i386/kernel/traps.c (w/ the indents shrunk to fit in 80 cols):
>
>---------------------------------------------------------------------------
>asmlinkage void do_nmi(struct pt_regs * regs, long error_code)
>{
>#ifdef CONFIG_SMP_NMI_INVAL
> smp_flush_tlb_rcv();
>#else
>#ifndef CONFIG_IGNORE_NMI
> printk("Uhhuh. NMI received. Dazed and confused, but trying to continue\n");
> printk("You probably have a hardware problem with your RAM chips or a\n");
> printk("power saving mode enabled.\n");
>#endif
>#endif
>}
>---------------------------------------------------------------------------

1) Couldn't this code determine the active process and remove the active
memory pages from use? (although you'd definatly want this as an option...
I see that some powersaving modes also generate an NMI!)

2) This, of course, wouldn't be good if it happened in the kernel space, at
which point it should panic.

3) On that note, we all know and love the kernel processes (nfsiod,
bdflush), what about one that periodicly did a checksum of the kernel code
region (and itself)? This wouldn't work if there's any self modifying code
in the kernel though... :-( A damaged kernel could conceivably be worse
than a panic.

Of course, given the frequency that this occurs, I don't know how much
effort and kernel bloat should be dedicated to it.
-Rob H.



\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.132 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site