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
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
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
> 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
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.