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

[Maciej W. Rozycki]

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
may be done if an auxiliary variable is used and other users of the index
cooperate.  The dummy read isn't really necessary, but of course someone
broke their RTC access logic, so it was added as a workaround.

 But then the firmware may screw it up if it changes the index from within 
the SMM.

> 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.

  Maciej
-
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/