Hi,
[Sorry for the late reply and for not following the whole thread, I'm
just busy.]
* John Keller [2008-11-18 08:08]:
>
> This patch addresses a problem on SN Altix systems with < 4GB, where
> device drivers using the dma_get_required_mask() API would be told
> to use 32 bit DMA, when 64 bit is more efficient.
>
> How exactly the use of dma_get_required_mask() relates to the crash
> kernel code you refer to is unclear to me.
I'm not sure myself. The crashkernel reservation code on IA64 (for
other architectures I don't know any machines that have basically their
whole memory except a small amount which is used for booting mapped
above 4 GiB physical address space) needs to check if it's okay to
use memory for the crashkernel that is *all* above 4 GiB.
This is only possible if a hardware IO/MMU is present (and working
correctly in the kdump case which isn't the case on HP IA64) and SWIOTBL
is not used because SWIOTBL needs some memory below that 4 GiB margin.
Now I thought that there's a relationship between "memory above 4 GiB
can be used for DMA" and the return value of dma_get_required_mask().
My assumption was:
(dma_get_required_mask() & 0xffffffff00000000ull) > 0
-> memory above 4 GiB can be used for DMA and so the
crashkernel memory can reside above 4 GiB
(dma_get_required_mask() & 0xffffffff00000000ull) == 0
-> memory above 4 GiB can not be used for DMA and so the
crashkernel memory can not all reside above 4 GiB
Is that wrong?
> If, for all platforms, the crash kernel code could use the mask returned
> from dma_get_required_mask() to do its check, then switching the code
> might be OK. But, if that's not possible for some platforms, then I'd
> wonder if dma_get_required_mask() is being used in the wrong context in
> this case.
The crashkernel reservation code is different for every platform, so it
does not matter. However, in theory I think the check would return
correct results.
Regards,
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|