Re: [PATCH -v3 5/6] x86, NMI, treat unknown NMI as hardware error

[Andi Kleen]

On Thu, Oct 21, 2010 at 10:10:02AM -0400, Don Zickus wrote:
> On Thu, Oct 21, 2010 at 01:17:31PM +0800, Huang Ying wrote:
> > > > But there is some general rules for unknown NMI. We think unknown NMI is
> > > > hardware error notification on all systems except systems with broken
> > > > hardware or software bugs, stone age machines. Do you agree with that?
> > > 
> > > Nope.  In my experiences, most of our customers are still running
> > > pre-Nehalem boxes, therefore most unknown NMIs are from broken hardware or
> > > bad firmware (at least in the bugzillas I deal with).
> > 
> > It seems that we have different point of view for reason of unknown NMI.
> > Should broken hardware be seen as hardware error?
> 
> Well, do you have an alternative way to handle broken hardware?  Broken
> hardware has generated NMIs, sometimes if I am lucky SERRs.  The ones that
> generate SERRs can be filtered through a different path, but what about
> the ones that don't?
> 

Don, AFAIK you're saying the same thing as Ying: an unknown NMI is 
a hardware error.

The reason the hardware does that is that it wants to tell us:

"I lost track of an error. There is corrupted data somewhere in the system.
Please stop, don't do anything that could consume that data. S.O.S."

The correct answer for that is panic.

The only problem we're trying to solve here is to distingush
other cases, like when software uses NMIs for something else
or there may be other cases

> > 
> > As far as I know, Windows treat unknown NMI as hardware errors. Although
> > we are programming for Linux not Windows. Many hardware are built for
> > Windows.
> 
> I was told Windows treats _any_ NMI as hardware errors, not just unknown
> ones. :-)

I don't know details about Windows' code here, but I assume that 
they have a way to hook into the NMI too, otherwise drivers like the HP
watchdog wouldn't work on Windows. But yes we know they shut down.

Essentially the hardware (and the BIOS) is designed 
under the assumption that the OS behaves like Windows for this.

In my long experience in making Linux work on all kinds
of hardware I learned very firmly that trying to drive PC hardware 
in a different way than Windows does is usually a bad idea.

The approach of Ying's patch kit was really to make
the behaviour more like Windows.


> Probably.  I guess I don't fully understand your definition of hardware
> error notification so I can't tell if we are arguing or agreeing (but
> using different words).
> 
> How do you envision the code looking like with hardware error
> notification?
> 
> I just wanted to keep the code in traps.c simple and clean and not
> constantly add new #ifdefs every time Intel came up with an interesting
> way to determine a hardware error condition.
> 
> For example, I am not the biggest fan of seeing stuff like edac or mce
> inside the code and would prefer them to use notifiers.  But that is just
> my opinion.

mce is only for testing anyways, "real" mce doesn't need vector 0.
So basically it's just a fancy "smp_call_nmi()" thingy.

EDAC shouldn't need it either, if it's does it's some probably
broken legacy behaviour.

> If you have a framework that you wanted to propose that could encapsulate
> an ever growing class of hardware error notifications, I would be
> interested

The trend in error reporting is away from NMIs and towards machine checks.
My bunch is that NMI reporting is more or less a legacy problem, so we have
to deal with what is there today.

I don't think you need to worry about a lot more hardware NMI sources.

The only thing that we need to worry about is more software NMI sources,
these unfortunately like to multiply.

-Andi

-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/