Messages in this thread | | | Date | Mon, 07 Nov 2005 10:57:17 +0200 | From | Muli Ben-Yehuda <> | Subject | Re: [PATCH] x86-64: dma_ops for DMA mapping - K3 |
| |
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/
| |