Re: Catching NForce2 lockup with NMI watchdog

From: George Anzinger <george@mvista.com>
To: macro@ds2.pg.gda.pl
Cc: bill davidsen <davidsen@tmr.com>, linux-kernel@vger.kernel.org
Subject: Re: Catching NForce2 lockup with NMI watchdog
Date: Fri, 12 Dec 2003 14:27:38 -0800	[thread overview]
Message-ID: <3FDA40DA.20409@mvista.com> (raw)
In-Reply-To: <brcoob$a02$1@gatekeeper.tmr.com>

Having had cause to try and figure out all this, I vote for the following being 
included in the source somewhere...

-g

bill davidsen wrote:
> In article <Pine.LNX.4.55.0312101421540.31543@jurand.ds.pg.gda.pl>,
> Maciej W. Rozycki <macro@ds2.pg.gda.pl> wrote:
> 
> |  The I/O APIC NMI watchdog utilizes the property of being transparent to a
> | single IRQ source of a specially reconfigured 8259A PIC (the master one in
> | the IA32 PC architecture).  There are more prerequisites that have to be
> | met and all indeed are for a 100% compatible PC as specified by the
> | Intel's Multiprocessor Specification.
> | 
> | 1. The INT output of the master 8259A PIC has to be connected to the LINT0
> | (or LINTIN0; the name varies by implementations) inputs of all local APICs
> | in the system.
> | 
> | 2a. The OUT0 output of the 8254 PIT (IOW the timer source) has to be 
> | directly connected to the INTIN2 input of the first I/O APIC.
> | 
> | 2b. Alternatively the INT output of the master 8259A PIC has to be
> | connected to the INTIN0 input of the first I/O APIC.
> | 
> | 3. There must be no glue logic that would change logical properties of the
> | signal between the INT output of the master 8259A PIC and the respective
> | APIC interrupt inputs.
> | 
> | In practice, assuming the MP IRQ routing information provided the BIOS has
> | been correct (which is not always the case), prerequisites #1 and #2 have
> | been met so far, but #3 has proved to be occasionally problematic.
> 
> In practice many system seem to take a good bit of guessing and testing.
> I have an old P-II which only works with acpi=force and nmi_watchdog=2,
> for instance.
> 
> It would be nice if there were a program which could poke at the
> hardware and suggest options which might work, as in eliminating the
> ones which can be determined not to work. Absent that trial and error
> rule, unfortunately.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml