Re: [RFC/PATCH, 1/4] readX_check() performance evaluation

[Grant Grundler <iod00d@hp.com>]

On Wed, Jan 28, 2004 at 08:17:01PM +0100, Andi Kleen wrote:
> This would likely 
> improve the quality of linux drivers long term and make your
> job as maintainer of an "anal IO error" platform easier.

yup. The key drivers we deal with reached that point last year.
Drivers could always be better. But those issues have been discussed
and presented:
o LinuxTag 2002 keynote by Alan Cox, "Submitting new Kernel drivers"
	(http://gsyprf11.external.hp.com/porting_zx1/mgp/Code.mgp)
o OLS 2002 talk by Arjan van de Ven, "How not to write kernel drivers"
o OLS 2002 talk by Greg K-H, "Documentation/CodingStyle and Beyond"
o OLS 2002 talk by myself, "Porting Drivers to HP ZX1"

It helps to "enforce" driver quality through "anal IO Error containment"
but it's too late when it happens on a customer box.

> Just it should not be enabled by default in production kernels.
> And finding out where it works reliably will be some work.

agreed.

> There is no reason pci_map_single() has to panic on overflow. On x86-64
> it returns an unmapped address that is guaranteed to cause an bus abort
> for 128KB.

parisc and ia64 will also bus abort. And then HPMC/MCA respectively.
We could reserve a "safe page" and then hand that back I guess.
But that sounds like a very broken error containment strategy to me.
(ie outbound data will be garbage).

This really isn't an issue for HP ZX1/IA64 since most drivers (64-bit)
can bypass the IOMMU and directly address memory. parisc-linux still
isn't commercially interesting.

> And you have an macro to test for it (pci_dma_error()). 

I didn't know about pci_dma_error.
Google found two references: One is:
	http://www.x86-64.org/lists/discuss/msg03841.html

> I believe ppc64 has adopted it too. Of course most drivers don't 
> use it yet.

<search 2.6.2-rc2 source tree>
grundler <502>find -name '*.[chS]' | xargs fgrep pci_dma_error
./include/asm-x86_64/pci.h:#define pci_dma_error(x) ((x) ==
bad_dma_address)
grundler <503>

That explains why most drivers don't use it yet.
It's only supported on one arch.
Maybe propose this to linux-pci mailing list?

grant