public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Don Zickus <dzickus@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
	Prarit Bhargava <prarit@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, arozansk@redhat.com,
	Thomas.Mingarelli@hp.com, ak@linux.intel.com,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH RFC] NMI Re-introduce un[set]_nmi_callback
Date: Thu, 4 Sep 2008 20:47:20 +0200	[thread overview]
Message-ID: <20080904184720.GI18288@one.firstfloor.org> (raw)
In-Reply-To: <20080904182637.GP3400@redhat.com>

On Thu, Sep 04, 2008 at 02:26:37PM -0400, Don Zickus wrote:
> On Thu, Sep 04, 2008 at 07:52:31PM +0200, Andi Kleen wrote:
> > On Thu, Sep 04, 2008 at 01:20:52PM -0400, Don Zickus wrote:
> > > On Thu, Sep 04, 2008 at 05:52:17PM +0200, Andi Kleen wrote:
> > > > Then if there's a chipset specific NMI driver it could
> > > > also check if the chipset raised it. That would be a possible
> > > > solution for HP -- they would need to implement such a driver
> > > > for their systems with the special watchdog.
> > > 
> > > The thing with HP's special watchdog timer is that it does _not_ have a
> > > chipset specific NMI it is trying to catch.  HP is going on the assumption
> > > that _all_ NMIs are /bad/ and they want to catch _every_ NMI, log it, and
> > > reboot the system.
> > 
> > That's my point. If you have drivers which can identify all other
> > NMIs then the left over NMIs must come from that watchdog driver.
> > So they just need drivers which can do that for their chipsets.
> 
> Except their chipsets are _not_ producing NMIs.  They just want to

They will produce NMIs when the suitable error conditions are true.
That is why the fallback is assuming a chipset problem.

So the only reliable way to find out if the event really came from
the misdesigned watchdog (whoever designed it didn't understand
NMIs I would say) you have to check the chipset (and all other
sources). Hopefully they are all better designed and can
actually tell you if they triggered or not.

Also there's the issue that sometimes people want
the fallback to be the NMI button.

> > It's not race free, but that's simply not possible with the x86
> > NMI architecture.
> 
> I agree.
> 
> > 
> > Better would be probably to just configure the watchdog 
> > to reboot the system directly on its own. Most other watchdogs
> > I'm aware of do that. That's more reliable anyways because the system
> > might be wedged enough to not be able to process NMIs anymore.
> 
> The trick is they want to log it in a special way (BIOS or NVRAM or
> something I forget) before rebooting.

Then why tell the OS? It should be an SMI then.


-Andi
-- 
ak@linux.intel.com

  reply	other threads:[~2008-09-04 18:50 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-04 13:07 [PATCH RFC] NMI Re-introduce un[set]_nmi_callback Prarit Bhargava
2008-09-04 13:37 ` Peter Zijlstra
2008-09-04 14:29   ` Prarit Bhargava
2008-09-04 14:49     ` aris
2008-09-04 14:56     ` Ingo Molnar
2008-09-04 15:12       ` H. Peter Anvin
2008-09-04 15:18         ` Ingo Molnar
2008-09-04 15:52       ` Andi Kleen
2008-09-04 17:20         ` Don Zickus
2008-09-04 17:52           ` Andi Kleen
2008-09-04 18:26             ` Don Zickus
2008-09-04 18:47               ` Andi Kleen [this message]
2008-09-04 19:08               ` Vivek Goyal
2008-09-04 20:00                 ` Andi Kleen
2008-09-04 20:01                   ` Mingarelli, Thomas
2008-09-04 20:19                     ` Andi Kleen
2008-09-04 20:21                       ` Mingarelli, Thomas
2008-09-04 20:53                         ` Andi Kleen
2008-09-04 21:22                           ` Don Zickus
2008-09-04 20:57                     ` Vivek Goyal
2008-09-04 21:05                       ` Mingarelli, Thomas
2008-09-04 21:21                         ` Vivek Goyal
2008-09-04 21:24                           ` Don Zickus
2008-09-04 21:46                             ` Vivek Goyal
2008-09-05  8:57                               ` Ingo Molnar
2008-09-05 10:24                             ` Ingo Molnar
2008-09-05  9:33                   ` Ingo Molnar
2008-09-05 14:16                     ` Vivek Goyal
2008-09-05 14:18                     ` Andi Kleen

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=20080904184720.GI18288@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=Thomas.Mingarelli@hp.com \
    --cc=ak@linux.intel.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arozansk@redhat.com \
    --cc=dzickus@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=prarit@redhat.com \
    --cc=tglx@linutronix.de \
    /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