David S. Miller wrote: > From: Hugh Dickins > Date: Mon, 6 Feb 2006 09:32:54 +0000 (GMT) > >> From looking at the source, the architectures I found to be doing >> scatterlist coalescing in some cases were alpha, ia64, parisc (some >> code under drivers), powerpc, sparc64 and x86_64. >> >> I agree with you that it would be possible for them to do the coalescing >> by just adjusting dma_address and dma_length (though it's architecture- >> dependent whether there are such fields at all), not interfering with >> the input page and length; and maybe some of them do proceed that way. >> I didn't find the coalescing code in any of them very easy to follow. >> >> So please examine arch/x86_64/kernel/pci_gart.c gart_map_sg (and >> dma_map_cont which it calls): x86_64 was the architecture on which >> the problem was really found with drivers/scsi/st.c, and avoided >> by that boot option iommu=nomerge. >> >> Lines like "*sout = *s;" and "*sout = sg[start];" are structure- >> copying whole scallerlist entries from one position in the list >> to another, without explicit mention of the page and length fields. > > That's a bug, frankly. Sparc64 doesn't need to do anything like > that. Spamming the page pointers is really really bogus and I'm > surprised this doesn't make more stuff explode. > > It was never the intention to allow the DMA mapping support code > to modify the page, offset, and length members of the scatterlist. > Only the DMA components. > > I'd really prefer that those assignments get fixed and an explicit > note added to Documentation/DMA-mapping.txt about this. How about this for a documentation fix? Brian -- Brian King eServer Storage I/O IBM Linux Technology Center