lkml.org 
[lkml]   [2010]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v3 5/6] x86, NMI, treat unknown NMI as hardware error
On Fri, Oct 22, 2010 at 10:05:10AM +0800, Huang Ying wrote:
> > > > 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.
> >
> > After re-reading Huang's patch, I am starting to understand what you mean
> > by broken hardware. Basically you are trying to distinguish between
> > legacy systems that were 'broken' in the sense they would randomly send
> > uknown NMIs for no good reason, hence the 'Dazed and confused' messages
> > and hardware errors on more modern systems that say, 'Hardware error,
> > panicing check your BIOS for more info' (or whatever).
>
> Yes.
>
> > So Huang's patch was sort of acting like a switch. On legacy systems use
> > 'Dazed and confused' for unknown NMIs. Whereas on whitelisted modern
> > systems use a more relavant 'Check BIOS for error' message. Is that
> > right?
>
> In fact we want to go panic and 'check BIOS for error, contact your
> hardware vendor' for all systems. But as you said, there are some
> 'broken hardware' randomly send unknown NMIs for no good reason. So a
> white list is used for them. And not all pre-Nehalem machines are
> 'broken' in fact.

Ok, I think I finally understand what you guys are trying to do. I also
can't see a problem with it. Though I think the patch could probably use
some clean up to make it more clear. Off the top of my head perhaps a
function call that sets the variable unknown_nmi_as_hwerr instead of
setting it explicitly and maybe structuring unknown_nmi() with an if-then
modern-message; else legacy-message; to possibly make it obvious what the
code is trying to acheive.

And yeah I know not all pre-Nehalem machines are broken. I am usually
sarcastic when I mention that just because being at IDF last year, I got
the impression that pre-Nehalem machines were considered the dark ages.
:-)

I am actually curious to know how many x86_64 machines would be considered
broken?

>
> > That's why you guys are complaining that registering a die_notifier would
> > be silly?
>
> I think whether going die_notifier or unknown_nmi_error() depends on it
> is general or specific for some hardware. Do you agree with that?

Well I am hoping the only general case would be the one you want to use
now. Everything else would be specific and require a die_notifier. I
mean how many different ways do we want to have a printk/panic in
unknown_nmi()?

Cheers,
Don


\
 
 \ /
  Last update: 2010-10-22 04:59    [W:0.190 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site