From: Hugh Dickins <hugh@xxxxxxxxxxx> 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. It's rediculious that these generic subsystem drivers need to know about this. :) - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
