From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-pci@atrey.karlin.mff.cuni.cz,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: PCI Error reporting & recovery
Date: Tue, 08 Feb 2005 17:22:52 +0900 [thread overview]
Message-ID: <420876DC.3040201@jp.fujitsu.com> (raw)
In-Reply-To: <1107835865.7687.78.camel@gaston>
Hi, Ben.
How kind of you to remember.
Benjamin Herrenschmidt wrote:
> I was reading the list archives for the discussion back in September
> about PCI error reporting. Has there been any further progress on this
> since then ?
Now I have a rewrite of the previous "clear/read_pci_errors" patch.
The new one adopts iomap infrastructure, considering generality,
capability and so on. And the part of its implementation for IA64 is
now under test using converted SCSI/NIC drivers.
Soon I'll post the patch to lkml(+IA64ML) with some explanation of the
change and the result of test, and will beg/hear comments.
> I'm looking into adapting something for the need of ppc64 as well
> (which, btw, has 1 slot = 1 bridge on most cases, but not all of them :)
> which uses quite different low level mecanisms. (Basically, we have to
> go through the firmware to get to the errors).
>
> Also, our bridges are automatically isolating slots that had any error
> on them (including DMA) and we have the ability to recover, by
> triggering a reset on a given segment and that sort of thing, for which
> I would like to provide dirvers with an API to control as well.
>
> Finally, I was thinking about some richer semantics for the error
> themselves. For example, on DMA error, we can sometimes get good details
> about the faulting address etc... which may be intersting for the driver
> to log, for diagnostic purpose at least.
Interesting.
Actually I don't have enough knowledge about platforms other than IA32/64,
so it will be helpful if you could tell me practical matters about ppc64
etc.
> So I'd like to start from what you did back then and discuss possible
> APIs for the above ideas / changes. What is the status of that stuff ?
> did it evolve since then ?
It goes slowly but steadily...
I'd also like to start the discussion about PCI error reporting again.
Thanks,
H.Seto
next prev parent reply other threads:[~2005-02-08 8:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-08 4:11 PCI Error reporting & recovery Benjamin Herrenschmidt
2005-02-08 8:22 ` Hidetoshi Seto [this message]
2005-02-08 11:55 ` Andi Kleen
2005-02-10 0:59 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=420876DC.3040201@jp.fujitsu.com \
--to=seto.hidetoshi@jp.fujitsu.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.