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

[Mark Lord <liml@rtr.ca>]

Mark Lord wrote:
> 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.
..

Mmm.. looks like ppc is already fixed in mainline,
commit 740c3ce66700640a6e6136ff679b067e92125794

Ben?