On 09/23/09 12:32, Konrad Rzeszutek Wilk wrote:

Synchronized in what sense? ioremap_* is all common code, so I would expect it to fail or not fail. I guess the possibilities are that that the physaddr is getting truncated to 32-bits somewhere, or _PAGE_PCD is getting masked out (either from __supported_pte_flags, or elsewhere in the process).

But you mention in the bug that the appears to be problems with the AGP aperture. Do you get the "Aperture pointing to e820 RAM. Ignoring" message when booting native?

We use the real BIOS-provided e820 map and then trim it according to the provided memory size, so there should always be the same holes in the E820 map that BIOS provides.

arch/x86/kernel/aperture_64.c has the test:

if (!no_iommu && max_pfn > MAX_DMA32_PFN && !printed_gart_size_msg) { printk(KERN_ERR "you are using iommu with agp, but GART size is less than
64M\n"); printk(KERN_ERR "please increase GART size in your BIOS setup\n"); printk(KERN_ERR "if BIOS doesn't have that option, contact your HW
vendor!\n"); printed_gart_size_msg = 1; }

I guess the "!no_iommu" clause is triggering because we have swiotlb set, but I wonder if that's specifically testing for the presence of a GART IOMMU?

How does ioremap_nocache fit into this? Is the mapping failing in some way and causing this code to fail? Or am I misunderstanding?

The test above also tests "max_pfn > MAX_DMA32_PFN" which limiting memory would avoid.

J