Re: [PATCH 2.6.13-rc1 03/10] IOCHK interface for I/O error handling/detecting

[Linas Vepstas <linas@austin.ibm.com>]

Hi,

Yes, but ...

On Wed, Jul 13, 2005 at 10:18:57AM +1000, Benjamin Herrenschmidt was heard to remark:
> 
> > Are you assuming that a device driver will use an iochk_read() for
> > every DMA operation? for every MMIO to the card?  
> > 
> > For high performance devices, it seems to me that this will cause
> > a rather large performance burden, especially if its envisioned that
> > all architectures will do something similar.
> > 
> > My concern is that (at least on ppc64) the call pci_read_config_word()
> > requires a call into "firmware" aka "BIOS", which takes thousands upon
> > thousands of cpu cycles.  There are hundreds of cycles of gratuitous
> > crud just to get into the firmware, and then lord-knows-what the
> > firmware does while its in there; probably doing all sorts of crazy
> > math to compute bus addresses and other arcane things.  I would imagine
> > that most architectures, includig ia64, are similar.
> > 
> > Thus, one wouldn't want to perform an iochk_read() in this way unless
> > one was already pretty sure that an error had already occured ... 
> > 
> > Am I misunderstanding something?
> 
> I would expect pSeries not to use the "default" error checking (that
> tests the status register) but rather use EEH.


OK, it wasn't clear to me if every possible case of the "detected parity
error" bit being set on the pci adapter is converted into an EEH error.
I had the impression that the adapter can set the bit, but not signal a 
#PERR, adn thus have no EEH event.   I am investigating this now.

If a given device driver is expecting iochk_read() to catch this situation, 
then we'd be screwed.

--linas
-
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/