Re: [PATCH] x86-64: dma_ops for DMA mapping - K3

[Muli Ben-Yehuda <mulix@mulix.org>]

On Sun, Nov 06, 2005 at 06:18:44PM +0100, Andi Kleen wrote:
> On Sunday 06 November 2005 18:06, Matti Aarnio wrote:
> 
> >
> > git7 blows up like git2, git9 plain was not tested at all.
> > I am applying the debug patch and compiling right now for a test.
> 
> Please just test plain git9 and post full boot log if it fails.

On git2 and git7 (and probably also git9) we die on Matti's machine
because we fall back to gart with no_iommu set when we find we don't
have an IOMMU in init_k8gatt(). That causes to a panic when we try to
DMA above 4GB due to the USB controller being only 32-bit-DMA
capable.

I think that the right thing to do at that point is fall back to
swiotlb[0]. Now, We could theoretically switch to swiotlb in
pci_iommu_init() when init_k8_gatt() fails, but at that point it's too
late to call swiotlb_init() (it causes a crash in the bootmem
allocator in my tests). That leaves the following options:

- realize earlier, when we can still call the standard swiotlb_init()
that we are going to need it (is this possible?)

- switch to having our own swiotlb_init() which relies on either
GPF_DMA32 or allocating the swiotlb scratch space statically in
vmlinux (thanks Arjan), and use it when init_k8_gatt() fails.

- call swiotb_init() unconditionally in mem_init(), and free it later
if we don't need it.

Thoughts?

As a side note, none of this is related to my dma_ops patch - we die
on Matti's machine the same way with and without it and we can fix it
roughly the same way with and without it. I do think the dma_ops patch
makes the potential fixes cleaner, though.

[0] Matti machine dies at the moment even with swiotlb=soft. I think
that's a seperate, orthogonal bug.

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/