Messages in this thread | | | Date | Mon, 25 Oct 2004 22:17:58 +0200 | From | Andi Kleen <> | Subject | Re: Race betwen the NMI handler and the RTC clock in practially all kernels |
| |
On Mon, Oct 25, 2004 at 09:07:42PM +0100, Maciej W. Rozycki wrote: > On Mon, 25 Oct 2004, Andi Kleen wrote: > > > > 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) > > It's not the dummy read that causes the problem. It's the index write > that does. It can be solved pretty easily by not changing the index. It
True. It has to be cached once.
> > 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. > > The use is correct. Bit #7 at I/O port 0x70 controls the NMI line > pass-through flip-flop. "0" means "pass-through" and "1" means "force > inactive." As the NMI line is level-driven and the NMI input is > edge-triggered, the sequence is needed to regenerate an edge if another > NMI arrives via the line (not via the APIC) while the handler is running.
At least in the datasheet I'm reading (AMD 8111) it is just a global enable/disable bit.
-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/
| |