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

[Corey Minyard <minyard@acm.org>]

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@acm.org> 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
>  
>