Re: Race betwen the NMI handler and the RTC clock in practially allkernels

[Corey Minyard]

According to the comments in 2.4, this code causes the NMI to be 
re-asserted if another NMI occurred while the NMI handler was running.  
I have no idea how twiddling with these CMOS registers causes this to 
happen, but that is supposed to be the intent.  I don't think it has 
anything to do with delays.

I would like to know what this code really does before removing it.

-Corey

Andi Kleen wrote:

> Corey Minyard <minyard@xxxxxxx> writes:
>
>  
>
> > I had a customer on x86 notice that sometimes offset 0xf in the CMOS
> > RAM was getting set to invalid values.  Their BIOS used this for
> > information about how to boot, and this caused the BIOS to lock up.
> >
> > They traced it down to the following code in arch/kernel/traps.c (now
> > in include/asm-i386/mach-default/mach_traps.c):
> >
> >    outb(0x8f, 0x70);
> >    inb(0x71);              /* dummy */
> >    outb(0x0f, 0x70);
> >    inb(0x71);              /* dummy */
> >    
>
> Just use a different dummy register, like 0x80 which is normally used
> for delaying IO (I think that is what the dummy access does) 
>
> But I'm pretty sure this NMI handling is incorrect anyways, its
> use of bits doesn't match what the datasheets say of modern x86
> chipsets say. Perhaps it would be best to just get rid of 
> that legacy register twiddling completely.
>
> I will also remove it from x86-64.
>
> -Andi
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/