From: Don Zickus <dzickus@redhat.com>
To: Huang Ying <ying.huang@intel.com>
Cc: Robert Richter <robert.richter@amd.com>,
huang ying <huang.ying.caritas@gmail.com>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH -v2 7/7] x86, NMI, Remove do_nmi_callback logic
Date: Tue, 28 Sep 2010 11:19:24 -0400 [thread overview]
Message-ID: <20100928151924.GJ26290@redhat.com> (raw)
In-Reply-To: <1285633705.20791.84.camel@yhuang-dev>
On Tue, Sep 28, 2010 at 08:28:25AM +0800, Huang Ying wrote:
> Hi, Don,
>
> On Mon, 2010-09-27 at 23:16 +0800, Don Zickus wrote:
> > On Mon, Sep 27, 2010 at 03:43:41PM +0200, Robert Richter wrote:
> > > On 27.09.10 08:56:44, huang ying wrote:
> > >
> > > > >> -static int unknown_nmi_panic_callback(struct pt_regs *regs, int cpu)
> > > > >> -{
> > > > >> - unsigned char reason = get_nmi_reason();
> > > > >> - char buf[64];
> > > > >> -
> > > > >> - sprintf(buf, "NMI received for unknown reason %02x\n", reason);
> > > > >> - die_nmi(buf, regs, 1); /* Always panic here */
> > > > >> - return 0;
> > > > >
> > > > > You are dropping this code that is different to panic().
> > > >
> > > > What is the difference? Is it relevant?
> > >
> > > I think yes, since the code behaves different. Otherwise we could
> > > remove die_nmi() completly and replace it by panic(). But both are
> > > different implementions. Maybe we can merge the code, but I didn't
> > > look at it closly.
> >
> > Actually die_nmi is a wrapper around panic with two important pieces.
> > One, it dumps some registers and two it does another notifier call to
> > DIE_NMIWATCHDOG (which correlates to another discussion in this patch
> > series).
> >
> > So if we do any consolidation between panic and die_nmi, it should be
> > convert to die_nmi. But then I wonder if that breaks the original
> > semantics of 'panic_on_unrecovered_nmi'. I don't think so though.
>
> Please take a look at the original code:
>
>
> if (nmi_watchdog_tick(regs, reason))
> return;
> if (!do_nmi_callback(regs, cpu))
> #endif /* !CONFIG_LOCKUP_DETECTOR */
> unknown_nmi_error(reason, regs);
> #else
> unknown_nmi_error(reason, regs);
> #endif
>
> If NMI comes from watchdog, nmi_watchdog_tick() will return 1. So
> do_nmi_callback() is NOT for watchdog NMI, but for unknown NMI. Why do
> we call DIE_NMIWATCHDOG for unknown NMI (NOT watchdog NMI)? die_nmi is
> for watchdog, not unknown NMI.
I think watchdog is an overloaded term. I was under the impression that
once the nmi watchdog determined a problem, it called the DIE_NMIWATCHDOG
die chain to see if any other drivers wanted to clean up or do their thing
first before panic'ing (namely drivers in drivers/char/watchdog).
Cheers,
Don
next prev parent reply other threads:[~2010-09-28 15:19 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-27 0:57 [PATCH -v2 1/7] x86, NMI, Add symbol definition for NMI magic constants Huang Ying
2010-09-27 0:57 ` [PATCH -v2 2/7] x86, NMI, Add touch_nmi_watchdog to io_check_error delay Huang Ying
2010-09-27 0:57 ` [PATCH -v2 3/7] x86, NMI, Rename memory parity error to PCI SERR error Huang Ying
2010-09-27 8:01 ` Robert Richter
2010-09-27 8:39 ` Huang Ying
2010-09-27 9:00 ` Robert Richter
2010-09-27 15:33 ` Don Zickus
2010-09-27 16:45 ` Robert Richter
2010-09-27 17:50 ` Don Zickus
2010-09-28 1:33 ` Huang Ying
2010-09-28 14:29 ` Robert Richter
2010-09-29 7:56 ` huang ying
2010-09-28 15:38 ` Don Zickus
2010-09-28 1:22 ` Huang Ying
2010-09-27 0:57 ` [PATCH -v2 4/7] x86, NMI, Rewrite NMI handler Huang Ying
2010-09-27 9:41 ` Robert Richter
2010-09-27 12:39 ` huang ying
2010-09-27 13:25 ` Robert Richter
2010-09-27 15:29 ` Don Zickus
2010-09-27 17:40 ` Robert Richter
2010-09-27 19:14 ` Don Zickus
2010-09-27 22:35 ` Robert Richter
2010-09-28 1:03 ` Huang Ying
2010-09-28 14:59 ` Robert Richter
2010-09-29 7:54 ` huang ying
2010-09-27 0:57 ` [PATCH -v2 5/7] Make NMI reason io port (0x61) can be processed on any CPU Huang Ying
2010-09-27 0:57 ` [PATCH -v2 6/7] x86, NMI, Add support to notify hardware error with unknown NMI Huang Ying
2010-09-27 10:09 ` Robert Richter
2010-09-27 12:47 ` huang ying
2010-09-27 13:38 ` Robert Richter
2010-09-27 15:20 ` Don Zickus
2010-09-28 0:36 ` Huang Ying
2010-09-28 15:32 ` Don Zickus
2010-09-29 8:17 ` huang ying
2010-09-30 4:36 ` Don Zickus
2010-09-30 4:57 ` Huang Ying
2010-09-30 8:38 ` Robert Richter
2010-09-30 9:36 ` huang ying
2010-09-30 9:51 ` Andi Kleen
2010-10-01 20:00 ` Maciej W. Rozycki
2010-09-30 8:25 ` Andi Kleen
2010-09-28 1:19 ` Huang Ying
2010-09-28 15:27 ` Robert Richter
2010-09-29 8:07 ` huang ying
2010-09-27 15:38 ` Don Zickus
2010-09-28 1:54 ` Huang Ying
2010-09-27 0:57 ` [PATCH -v2 7/7] x86, NMI, Remove do_nmi_callback logic Huang Ying
2010-09-27 10:44 ` Robert Richter
2010-09-27 12:56 ` huang ying
2010-09-27 13:43 ` Robert Richter
2010-09-27 15:16 ` Don Zickus
2010-09-27 16:58 ` Robert Richter
2010-09-28 1:41 ` Huang Ying
2010-09-28 15:16 ` Robert Richter
2010-09-28 15:21 ` Don Zickus
2010-09-28 0:28 ` Huang Ying
2010-09-28 15:19 ` Don Zickus [this message]
2010-09-29 6:55 ` huang ying
2010-09-30 4:04 ` Don Zickus
2010-09-30 5:21 ` Huang Ying
2010-09-30 8:24 ` Andi Kleen
2010-09-30 8:23 ` Robert Richter
2010-09-27 10:50 ` [PATCH -v2 1/7] x86, NMI, Add symbol definition for NMI magic constants Robert Richter
2010-09-27 15:29 ` Don Zickus
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=20100928151924.GJ26290@redhat.com \
--to=dzickus@redhat.com \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=huang.ying.caritas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=robert.richter@amd.com \
--cc=ying.huang@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.