From: linas@austin.ibm.com (Linas Vepstas)
To: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Greg KH <greg@kroah.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
linux-ia64@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [PATCH 1/6] PCIERR : interfaces for synchronous I/O error detection on driver
Date: Fri, 24 Mar 2006 23:43:06 +0000 [thread overview]
Message-ID: <20060324234306.GC21895@austin.ibm.com> (raw)
In-Reply-To: <4423A40D.3080906@jp.fujitsu.com>
On Fri, Mar 24, 2006 at 04:47:25PM +0900, Hidetoshi Seto wrote:
>
> At 2.6.16-rc1, Linux kernel accepts and provides "PCI-bus error event
> callbacks" that enable RAS-aware drivers to notice errors asynchronously,
> and to join following kernel-initiated PCI-bus error recovery.
> This callbacks work well on PPC64 where it was designed to fit.
>
> However, some difficulty still remains to cover all possible error
> situations even if we use callbacks. It will not help keeping data
> integrity, passing no broken data to drivers and user lands, preventing
> applications from going crazy or sudden death.
This is not true. Although there are some subtle issues, (which
I invite you to describe), the goal of the current design is to
insure data integrity, and make sure that neither the driver nor
the userland gets corrupted data. There shouldn't be any "crazy
or sudden death" if the device drivers are any good.
Of course, this depends on the hardware implementation. If
your PCI bus sends corrupt data up to the driver ... all bets
are off. The design is predicated on the assumption that the
hardware sends either good data or no data, ad that the latter
is associated with a bus state indicating an error has ocurred.
> - It will be useful if arch chooses panic on bus errors not to pass
> any broken data to un-reliable drivers.
I assume you meant "if arch chooses NOT to panic on bus errors ..."
I'll review the rest of the patch via sepaate email
--linas
next prev parent reply other threads:[~2006-03-24 23:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-22 8:38 [PATCH] PCIERR : interfaces for synchronous I/O error detection on Hidetoshi Seto
2006-03-22 21:01 ` [PATCH] PCIERR : interfaces for synchronous I/O error detection on driver Greg KH
2006-03-24 7:47 ` [PATCH 1/6] PCIERR : interfaces for synchronous I/O error detection Hidetoshi Seto
2006-03-24 23:43 ` Linas Vepstas [this message]
2006-03-27 2:37 ` Hidetoshi Seto
2006-03-31 22:01 ` [PATCH 1/6] PCIERR : interfaces for synchronous I/O error detection on driver Linas Vepstas
2006-04-03 4:54 ` [PATCH 1/6] PCIERR : interfaces for synchronous I/O error detection Hidetoshi Seto
2006-03-24 7:48 ` [PATCH 2/6] " Hidetoshi Seto
2006-03-24 7:49 ` [PATCH 3/6] " Hidetoshi Seto
2006-03-24 7:50 ` [PATCH 4/6] " Hidetoshi Seto
2006-03-24 7:51 ` [PATCH 5/6] " Hidetoshi Seto
2006-03-24 7:52 ` [PATCH 6/6] " Hidetoshi Seto
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=20060324234306.GC21895@austin.ibm.com \
--to=linas@austin.ibm.com \
--cc=greg@kroah.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=seto.hidetoshi@jp.fujitsu.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox