John Levon wrote:

>On Fri, Nov 15, 2002 at 08:13:51AM -0600, Corey Minyard wrote:
>
>  
>
>>I don't think that's a good idea for two reasons:
>>
>>   * If the oprofile code is only using the counter that the NMI
>>     watchdog is not using, it will silently cause the NMI watchdog to
>>     stop working.  I know that's not the case now, but it could be in
>>     the future.
>>    
>>
>Uh, this is fine. We always call the NMI watchdog handler, so it will
>see apic irqs get stuck, and work anyway.
>
If the NMI watchdog doesn't handle an interrupt, it will not re-enable 
the watchdog (in local APIC mode).  If there is no other source of NMIs, 
then it will never run.  It will get hit when the timer wraps around, I 
guess, but that could be a LONG time.

>>   * The oprofile code will always reset the counter, so the NMI
>>     watchdog will never see the timeout, so it doesn't matter.
>>    
>>
>wrong. If we are using counters 0 and 1, and 1 overflows, oprofile
>resets that, then 0 overflows, the NMI watchdog will see it and
>incorrectly reset it. You HAVE to avoid the reset - you can test it if
>you don't believe me.
>
Ok, I see that.

>>+/* This is for I/O APIC, until we can figure out how to tell if it's from the
>>+   I/O APIC.  If the NMI  was not handled before now, we handle it. */
>>+static int dummy_watchdog_reset(int handled)
>>+{
>>+	return !handled;
>>+}
>>    
>>
>
>And if it was handled previously, you reset it to not handled ? Uh ?
>
Oops.  Fixed this.

I have attached another patch, this one fixes my stupid bug in 
dummy_watchdog_reset and also adds code to the NMI watchdog to not 
handle the NMI if it has already been handled.  Again, you must do a "cd 
arch/i386/kernel; mv nmi.c nmi_watchdog.c" before applying this patch.

I have also created a kernel module that loops requesting and releasing 
the NMI, and counting the number of NMIs that actually get hit by the 
handler that is installed..  This is on a dual 2.8GHZ Pentium 4 machine 
with hyperthreading (so 4 processors, sort of).  I have six processes 
doing the request/release and some other processes eating CPU on each 
processor.  This has been running for almost three hours, about 
10,000,000 NMIs have occurred (around 1000/sec).  Around 4700 NMIs have 
been caught by the handler, meaning that it was a close race between the 
removal and the NMI occurring.  So it looks good.

-Corey