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

[Maciej W. Rozycki]

On Mon, 25 Oct 2004, Andi Kleen wrote:

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

 You mean once per write, don't you?  The index is w/o, unfortunately.

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

 The flip-flop is expected to be connected to the NMI input of the
processor, which for systems using local APICs means their LINT1 inputs (I
think it's broadcasted for all existing systems, although in principle
only the BSP needs to be connected).  But from the local APIC's point of
view LINT1 is just another local interrupt line which may or may not be
programmed for the NMI delivery mode and moreover, NMIs may arrive via the
LINT0 input or from the performance counter interrupt if programmed so
(this is the case with the NMI watchdog) or from another APIC as an IPI or
an ordinary interrupt.  These alternative sources are of course unaffected
by the flip-flop unless you have a strange implementation of the local
APIC.

  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/