Messages in this thread | | | Date | Mon, 25 Oct 2004 14:50:27 -0500 | From | Corey Minyard <> | Subject | Re: 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/
| |