Re: PATCH: Further aacraid work

[Christoph Hellwig <hch@infradead.org>]

On Thu, Jun 17, 2004 at 08:53:36AM -0400, Salyzyn, Mark wrote:
> I *must* admit that the driver functions perfectly in other systems with
> more than 4G of memory; however we *are* having troubles specifically
> with AMD64 systems with more than 4G of memory in 2.6 kernels (the issue
> does not occur on 2.4 kernels). I have yet to investigate why this
> specific problem exists.

So what exactly is the firmware doing with this information?  What I
expected is that if the memory is smaller 4GB it's just use 32bit
descriptors.  If you want to keep that heck do the check _before_ setting
the dma_mask.  If you have a > 32bit dma mask but the firmware can't deal
with the high bits in the dma address actually set it's a bug.  It won't
show up on PCs but pretty much on any complex architecture with an iommu
(like AMD64)

> One would expect that if we erroneously got the memory model wrong (ie,
> <4GB of memory, one slice at 0-2G, another slice at 4G-6G) that the 32
> dma limit would protect us from functional problems in this delicate
> area but with a performance hit resulting from the scsi layer providing
> bounce buffers. Ideally we would like to have a mechanism to know if the
> DMAable area is limited to a 32 bit address space in order to take
> advantage of the more efficient FIB utilization.

Again, memory model doesn't matter.  For many plattforms dma address
aren't memory addresses.