From: Dave Peterson <dsp@llnl.gov>
To: Doug Thompson <dthompson@lnxi.com>
Subject: Re: [PATCH] EDAC: core EDAC support code
Date: Mon, 13 Mar 2006 11:35:35 -0800
User-Agent: KMail/1.5.3
Cc: arjan@infradead.org, greg@kroah.com, gregkh@kroah.com,
       bluesmoke-devel@lists.sourceforge.net,
       Doug Thompson <dthompson@lnxi.com>, torvalds@osdl.org, alan@redhat.com,
       linux-kernel@vger.kernel.org, rdunlap@xenotime.net
References: <4412A0AB02000036000015D4@zoot.lnxi.com>
In-Reply-To: <4412A0AB02000036000015D4@zoot.lnxi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200603131135.35531.dsp@llnl.gov>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1247
Lines: 26

On Saturday 11 March 2006 09:04, Doug Thompson wrote:
> > > >     - When an error is actually detected, the subsystem that detected
> > > >       the error (for instance, PCI) would feed the error information
> > > >       to EDAC.  Then EDAC would determine how to respond to the error
> > > >       (for instance, push it to userspace or implement the
> > > >       userspace-chosen policy (panic/reboot/etc))
> > >
> > > yup.
> >
> > Cool!  I think this also coincides with what Doug is saying.  Doug, how
> > does this sound?
>
> It sounds good. One issue is how this works with the IBM PCI Parity
> handling submission? I don't remember if it has been included yet or
> not. I haven't fully studied their model, but it allowed for device
> drivers to register notification functions. The PCI subsystem would then
> notify the driver of such errors so the driver could do what ever it
> needed to do in the bad-thing-happened event.

Hmm... interesting.  Can you provide any links to info on this?

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