lkml.org 
[lkml]   [2004]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Race betwen the NMI handler and the RTC clock in practially all kernels
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
>
>

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

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