From: george anzinger <george@mvista.com>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: Ingo Molnar <mingo@elte.hu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: NMI watchdog question.
Date: Wed, 06 Nov 2002 09:59:41 -0800 [thread overview]
Message-ID: <3DC9588D.C3574CB5@mvista.com> (raw)
In-Reply-To: 15816.62663.166644.782004@kim.it.uu.se
Mikael Pettersson wrote:
>
> george anzinger writes:
> > In attempting to understand how the NMI watchdog works I
> > think I have found that:
> >
> > a. the NMI interrupts are generated by the performance
> > counter in the cpu and
> ...
> > If this is so (and help me to understand if it is not), then
> > what do the timer interrupts going thru the IO_APIC have to
> > do with the NMI watchdog.
>
> Before 2.4, the NMI watchdog was only available for SMP boxes,
> since it used the I/O APIC to send NMIs to the CPUs. Then the
> ability to use the *local* APIC on UP machines was introduced,
> and with it the ability to drive the NMI watchdog from the CPU
> itself, via performance counter overflow interrupts.
>
> The NMI watchdog still supports both these modes of operation.
> Typically, the performance counter + local APIC mode kicks in
> when (a) you asked for it, or (b) you asked for the I/O APIC
> mode but it wasn't available.
So then the NMI checks for timer interrupts being serviced
in this case? But, still, why the turn off if the timer
does not go thru the APIC? The case this came up in is an
SMP machine, but the test in apic.c shows that the PIT
interrupt does not go thru the APIC. Leaving NMI on seems
to work, so I am wondering if this is just old code.
>
> /Mikael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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
next prev parent reply other threads:[~2002-11-06 17:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-06 5:50 NMI watchdog question george anzinger
2002-11-06 10:53 ` Mikael Pettersson
2002-11-06 17:59 ` george anzinger [this message]
2002-11-06 18:12 ` John Levon
2002-11-06 18:58 ` Maciej W. Rozycki
2002-11-06 18:55 ` Maciej W. Rozycki
2002-11-06 19:49 ` george anzinger
2002-11-06 20:07 ` John Levon
2002-11-07 16:20 ` Bill Davidsen
2002-11-07 16:30 ` Maciej W. Rozycki
2002-11-07 16:44 ` Zwane Mwaikambo
-- strict thread matches above, loose matches on Subject: below --
2005-03-06 0:53 Pallai Roland
[not found] <3EShS-A1-9@gated-at.bofh.it>
2005-03-06 15:14 ` Robert Hancock
2005-03-06 18:51 Pallai Roland
2005-03-07 10:16 Mikael Pettersson
2005-03-07 13:00 ` Pallai Roland
2005-03-08 2:28 Pallai Roland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3DC9588D.C3574CB5@mvista.com \
--to=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@csd.uu.se \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox