Re: Problem with DMA on x86_64 with 3 GB RAM

[Andi Kleen <ak@suse.de>]

> The documentation is correct, the implementation is broken. The
> documented behaviour works for all platforms except one whose maintainer
> has a problem with it and refuses to follow the spec.

The reference is still what i386 does.

> > Possibly, but devices that cannot address at least 4GB are normally
> > categorized as "hardware bugs" (or less polite descriptions) and those don't 
> > tend to get much airtime in documentation.
> 
> The rest of the kernel deals with hardware limitations, 

Yes, but you don't find it normally in the documentation, just
in some very dark corners of the code.

> 30bit DMA works 
> on the other platforms. This is an x86-64 platform problem. It
> misimplements the basic pci_ functionality. 

Well, if you claim that then i386 misimplements it too. 

Normally people don't hit it on 32bit because with the default user/kernel split
the limit is 900MB, which tends to be ok for most hardware. But you
could easily hit it with non standard __PAGE_OFFSET as it is now
possible to configure. 

I claim x86-64 is bug to bug compatible to i386 as far as possible. 
Since that is what drivers are typically written for it's the most
important specification.

> If it doesn't wish to 
> implement the stuff (and there btw Andi I do think your view has
> considerable merit) it should fail the set_mask requests.

If it did like you're recommending a huge number of drivers
in the tree wouldn't work anymore (just think about what pci_alloc_consistent
does) 

I have a long term master plan to merge GFP_DMA and swiotlb
into a single pool -- if that ever happens it might be possible
to fix it properly. But probably most of the drivers who needed
it wouldn't work anyways because they typically tend to forget
enough *_sync calls to make software bounce buffering work.

-Andi