Messages in this thread | | | Date | Mon, 13 Sep 2010 14:23:54 -0400 | From | Don Zickus <> | Subject | Re: [RFC 5/6] x86, NMI, Add support to notify hardware error with unknown NMI |
| |
On Mon, Sep 13, 2010 at 08:07:07PM +0200, Andi Kleen wrote: > > > > > Honestly, I don't think you need much screen real estate. It would be > > nice when an unknown NMI comes in, if the kernel just pokes around > > the hardware registers and display a summary of what it found. For > > example, > > > > The following devices had error bits set in the status registers: > > PCI device x:y.z - STATUS_BIT1 | STATUS_BIT2 > > HW device xyz - STATUS_BIT3 > > ... > > You mean data from the generic PCI config space?
Yes. I normally just look at the Status register. With PCI-e I'll look at the other status registers in the capabilities field too.
> > I don't think i would feel comfortable with arbitrary driver callbacks > (the risk of the driver breaking the panic would be high)
Neither would I.
> > But if it's generic if not on the screen it should > be at least in the error serialization data and logged after boot.
I guess I don't know what that is, 'error serialization data'. Is there somewhere I can read more about it?
> > At least on PCI-E it may be enough to simply dump all recent AER > data.
This assumes AER is supported on the bridge? Which for newer chips is probably true, but I wasn't sure about older ones.
How would I dump AER data from within the kernel?
> > > > > But I guess if we accept the fact that an unknown NMI will panic the > > box, then we can probably be a little more liberal in breaking > > spinlocks and poking around the hardware to display some userful info. > > You have to be a bit careful with that, you may caused nested errors > (e.g. machine checks or more NMIs). I suppose this could be checked for > though.
Of course.
Cheers, Don
| |