Red Hat Bugzilla – Bug 225157
sytem crashes on dma_map_sg()
Last modified: 2008-03-14 01:30:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20060601 Firefox/220.127.116.11 (Ubuntu-edgy)
Description of problem:
When calling dma_map_sg() for a region more than 1 GB the kernel panics. To workaround this problem, need to call multiple times dma_map_sg() with a single entry rather than calling once with multiple entries.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. call dma_map_sg() with several entries for more than 1 GB
Here are the specs agian since I am not sure I put then correctly:
component: kernel, IOMMU
Please forward to HP.
This happens because sba_alloc_range(), which is called in the dma_map_sg()
path, panics instead of returning an allocation failure.
I think this was originally done because some drivers didn't check the
return code of dma_map_sg(). But it looks like most other IOTLB drivers
return failure instead of panicking, and it shouldn't be hard to fix
sba_iommu.c to do the same thing. Then it's "just" a question of
testing the supported drivers to make sure they have the right error
Rather than fail the request, maybe it is better to fall back on registering
multiple chunks as if dma_map_single was called multiple times.
If the device can directly address all the buffers in the sglist,
we could bypass the IOMMU. This has some effect on performance, so
would have to be evaluated. You win some by not having to set up the
IOMMU mappings, but you also lose the benefit of coalescing many
sglist buffers into a few.
But for devices that can't reach all the buffers (e.g., 32-bit cards),
we can't bypass the IOMMU, so we have to either panic or return failure.
Are there any update on this issue?
What is the upstream status?
Is there any patch needs to be back ported?
Since __no__ update for these bug for about half year. Closing it...