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

[Andi Kleen]

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/