Hello, Unfortunately, I don't have the failing piece of HW.... So this is all by code inspection. > For a block device that is misbehaving you want to check > > 1. That the DMA allocations done by the driver (eg the IDE > PRD) are coming in below 4GB as expected Well, the 32bit DMA mask appears to be set correctly by the IDE driver in drivers/ide/setup-pci.c (around line 312) -- so it would seem that if large (>32-bit) addresses were being attempted by the driver, either the code path including the call to pci_set_dma_mask() wasn't invoked, or something within the driver or memory allocator went wrong. What I'm not clear about is what part of this -- if any -- actually involves the architecture specific code. In particular, when you say architecture specific here, do you mean "MIPS" or "SB1 on MIPS"? It seems like all of this is handled in the arch independent code. FWIW, the SB1 uses the fairly generic dma-coherent.c support under arch/mips/mm. The only troubling thing I saw in Documentation/DMA-mapping.txt was what looked like an assumption that 64-bit systems with 32-bit devices would have an IOMMU to redirect (arbitrary) 32-bit PCI bus addresses to (arbitrary) 64-bit physical memory addresses. I've seen (and programmed) such things on UltraSPARC systems, but none exists on the SB1. But, the later comments about the automatic bounce buffering and the PCI DMA mask seemed to imply that the IOMMU wasn't required/assumed in all cases. > > 2. Take a look then at block/ll_rw_blk.c which deals with the > block layer. Dump the calls to blk_queue_block_limit and make > sure the things it does are looking sane. > > 3. Take a look at what is going on in blk_rq_map_sg which > deals with mapping scatter gather lists to the device, while > handling the bounce limits. (dma_unmap_sg is the clean up end of this) > > 4. This lot then gets used by ide_build_sglist in > drivers/ide/ide-dma.c and the related ide_build_dmatable > function. These might also be worth dropping debug into to > see what is cooking. Unfortunately, 2-4 above requires that I have the failing HW on hand, which I don't at the moment. Martin - any chance you can take a look at this? 64-bit capable devices are known to work correctly in this system (and known to use >32-bit physical addresses for DMA targets), so it seems like the issue would mostly lie with the allocation of DMA buffers from the lower 4G of physical memory. Of course, I'm probably a bit lost here. Chuckle. Thx, Mark
