Re: libata .sg_tablesize: why always dividing by 2 ?

[Mark Lord <liml@rtr.ca>]

Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
>>> I suppose so. I don't remember all of the details, but iirc, it has to
>>> do with crossing 64K boundaries. Some controllers can't handle it.
>>>
>>> It's not only the _size_ of the segments, it's their alignment.
>>>
>>> The iommu will not keep alignement beyond the page size (and even
>>> then... on powerpc with a 64k base page size, you may still end up with
>>> a 4k aligned result, but let's not go there now).
>> ..
>>
>> That's just not possible, unless the IOMMU *splits* segments.
>> And the IOMMU experts here say that it never does that.
> 
> It is totally possible, and I know as wrote part of the powerpc iommu
> code :-)
> 
> The iommu code makes no guarantee vs. preserving the alignment of a
> segment, at least not below PAGE_SIZE.
> 
> Thus if you pass to dma_map_sg() a 64K aligned 64K segment, you may well
> get back a 4K aligned 64K segment.
> 
> Enforcing natural alignment in the iommu code only happens for
> dma_alloc_coherent (it uses order-N allocations anyway), it doesn't
> happen for map_sg. If we were to do that, we would make it very likely
> for iommu allocations to fail on machine with small DMA windows.
> 
> Ben.
..

That's interesting.  Can you point us to the exact file::lines where
this happens?  It would be good to ensure that this gets fixed.

I'm copying Fujita Tomonori on this thread now -- he's the dude who's
trying to sort out the IOMMU mess.

Thanks