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

From: Andi Kleen
Date: Mon Oct 25 2004 - 16:08:06 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/