On Fri, 2005-03-18 at 18:35 -0600, Linas Vepstas wrote:
> On Sat, Mar 19, 2005 at 10:13:02AM +1100, Benjamin Herrenschmidt was heard to
> remark:
> >
> > Additionally, in "real life", very few errors are cause by known errata.
> > If the drivers know about the errata, they usually already work
On Sat, Mar 19, 2005 at 10:13:02AM +1100, Benjamin Herrenschmidt was heard to
remark:
>
> Additionally, in "real life", very few errors are cause by known errata.
> If the drivers know about the errata, they usually already work around
> them. Afaik, most of the errors are caused by transcient
On Fri, 2005-03-18 at 11:10 -0700, Grant Grundler wrote:
> On Fri, Mar 18, 2005 at 09:24:02AM -0800, Nguyen, Tom L wrote:
> > >Likewise, with EEH the device driver could take recovery action on its
> > >own. But we don't want to end up with multiple sets of recovery code
> > >in drivers, if
On Thursday, March 17, 2005 2:58 PM Benjamin Herrenschmidt wrote:
> Does the link side of PCIE provides a way to trigger a hard reset of
the
> rest of the card ? If not, then it's dodgy as there may be no way to
> consistently "reset" the card if it's in a bad state.
The PCI Express spec does
On Friday, March 18, 2005 10:10 AM Grant Grundler wrote:
>A port bus driver does NOT sound like a normal device driver.
>If PCI Express defines a standard register set for a bridge
>device (like PCI COnfig space for PCI-PCI Bridges), then I
>don't see a problem with PCI-Express error handling code
On Fri, Mar 18, 2005 at 09:24:02AM -0800, Nguyen, Tom L wrote:
> >Likewise, with EEH the device driver could take recovery action on its
> >own. But we don't want to end up with multiple sets of recovery code
> >in drivers, if possible. Also we want the recovery code to be as
> >simple as
On Thursday, March 17, 2005 8:01 PM Paul Mackerras wrote:
> Does the PCI Express AER specification define an API for drivers?
No. That is why we agree a general API that works for all platforms.
>Likewise, with EEH the device driver could take recovery action on its
>own. But we don't want to
On Thursday, March 17, 2005 6:44 PM Benjamin Herrenschmidt wrote:
>I have difficulties following all of your previous explanations, I must
>admit. My point here is I'd like you to find out if the API can fit on
>the driver side, and if not, what would need to be changed.
In summary, we agreed
On Thursday, March 17, 2005 6:44 PM Benjamin Herrenschmidt wrote:
I have difficulties following all of your previous explanations, I must
admit. My point here is I'd like you to find out if the API can fit on
the driver side, and if not, what would need to be changed.
In summary, we agreed that
On Thursday, March 17, 2005 8:01 PM Paul Mackerras wrote:
Does the PCI Express AER specification define an API for drivers?
No. That is why we agree a general API that works for all platforms.
Likewise, with EEH the device driver could take recovery action on its
own. But we don't want to end
On Fri, Mar 18, 2005 at 09:24:02AM -0800, Nguyen, Tom L wrote:
Likewise, with EEH the device driver could take recovery action on its
own. But we don't want to end up with multiple sets of recovery code
in drivers, if possible. Also we want the recovery code to be as
simple as possible,
On Friday, March 18, 2005 10:10 AM Grant Grundler wrote:
A port bus driver does NOT sound like a normal device driver.
If PCI Express defines a standard register set for a bridge
device (like PCI COnfig space for PCI-PCI Bridges), then I
don't see a problem with PCI-Express error handling code
On Thursday, March 17, 2005 2:58 PM Benjamin Herrenschmidt wrote:
Does the link side of PCIE provides a way to trigger a hard reset of
the
rest of the card ? If not, then it's dodgy as there may be no way to
consistently reset the card if it's in a bad state.
The PCI Express spec does not
On Fri, 2005-03-18 at 11:10 -0700, Grant Grundler wrote:
On Fri, Mar 18, 2005 at 09:24:02AM -0800, Nguyen, Tom L wrote:
Likewise, with EEH the device driver could take recovery action on its
own. But we don't want to end up with multiple sets of recovery code
in drivers, if possible. Also
On Sat, Mar 19, 2005 at 10:13:02AM +1100, Benjamin Herrenschmidt was heard to
remark:
Additionally, in real life, very few errors are cause by known errata.
If the drivers know about the errata, they usually already work around
them. Afaik, most of the errors are caused by transcient
On Fri, 2005-03-18 at 18:35 -0600, Linas Vepstas wrote:
On Sat, Mar 19, 2005 at 10:13:02AM +1100, Benjamin Herrenschmidt was heard to
remark:
Additionally, in real life, very few errors are cause by known errata.
If the drivers know about the errata, they usually already work around
Nguyen, Tom L writes:
> We decided to implement PCI Express error handling based on the PCI
> Express specification in a platform independent manner. This allows any
> platform that implements PCI Express AER per the PCI SIG specification
> can take advantage of the advanced features, much like
Nguyen, Tom L writes:
> Is EEH a PCI-SIG specification? Is EEH specs available in public?
No and no (not yet anyway).
> It seems that a PCI-PCI bridge per slot is hardware implementation
> specific. The fact that the PCI-PCI Bridge can isolate the slot is
> hardware feature specific.
Well,
On Thu, 2005-03-17 at 10:53 -0800, Nguyen, Tom L wrote:
> To support the AER driver calling an upstream device to initiate a reset
> of the link we need a specific callback since the driver doing the reset
> is not the driver who got the error. In the case of general PCI this
> could be useful
On Wednesday, March 16, 2005 7:20 PM Benjamin Herrenschmidt wrote:
>> What mechanism (message??) is used to perform the bus and/or link
>> level reset? For PCI Express the reset is performed by the upstream
>> port driver. My API takes this into account. Are you assuming the
PCI
>> device on
> On a fatal error the interface is down. No matter what the driver
> supports (AER aware, EEH aware, unaware) all IO is likely to fail.
> Resetting a bus in a point-to-point environment like PCI Express or EEH
> (as you describe) should have little adverse effect. The risk is the
> bus reset
On Wednesday, March 16, 2005 7:52 PM Paul Mackerras wrote:
>> We need some PCI
>> based error flows to understand the details of the flow so we can
>> develop an interface compatible with both.
>
>Here is a basic outline of what happens with EEH (Enhanced Error
>Handling) on IBM PPC64 platforms.
On Wednesday, March 16, 2005 7:52 PM Paul Mackerras wrote:
We need some PCI
based error flows to understand the details of the flow so we can
develop an interface compatible with both.
Here is a basic outline of what happens with EEH (Enhanced Error
Handling) on IBM PPC64 platforms. This
On a fatal error the interface is down. No matter what the driver
supports (AER aware, EEH aware, unaware) all IO is likely to fail.
Resetting a bus in a point-to-point environment like PCI Express or EEH
(as you describe) should have little adverse effect. The risk is the
bus reset will
On Wednesday, March 16, 2005 7:20 PM Benjamin Herrenschmidt wrote:
What mechanism (message??) is used to perform the bus and/or link
level reset? For PCI Express the reset is performed by the upstream
port driver. My API takes this into account. Are you assuming the
PCI
device on the bus
On Thu, 2005-03-17 at 10:53 -0800, Nguyen, Tom L wrote:
To support the AER driver calling an upstream device to initiate a reset
of the link we need a specific callback since the driver doing the reset
is not the driver who got the error. In the case of general PCI this
could be useful if a
Nguyen, Tom L writes:
Is EEH a PCI-SIG specification? Is EEH specs available in public?
No and no (not yet anyway).
It seems that a PCI-PCI bridge per slot is hardware implementation
specific. The fact that the PCI-PCI Bridge can isolate the slot is
hardware feature specific.
Well, it's a
Nguyen, Tom L writes:
We decided to implement PCI Express error handling based on the PCI
Express specification in a platform independent manner. This allows any
platform that implements PCI Express AER per the PCI SIG specification
can take advantage of the advanced features, much like SHPC
28 matches
Mail list logo
