* Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:

quoted text
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -218,6 +218,73 @@ static __u32 __init search_agp_bridge(u32 *order, int *valid_agp)
>  	return 0;
>  }
>  
> +void __init early_gart_iommu_disable(void)
> +{
> +	/*
> +	 * disable it in case it is enabled before, esp for kexec/kdump,
> +	 * previous kernel already enable that. otherwise memset called
> +	 * by allocate_aperture/__alloc_bootmem_nopanic cause restart.
> +	 * or second kernel have different position for GART hole. and new
> +	 * kernel could use hole as RAM that is still used by GART set by
> +	 * first kernel
> +	 */

hm, i'm wondering, instead of modifying the GART, why dont we simply 
_detect_ whatever GART settings we have inherited, and propagate that 
into our e820 maps? I.e. if there's inconsistency, then punch that out 
from the memory maps and just dont use that memory.

that way it would not matter whether the GART settings came from a [old 
or crashing] Linux kernel that has not called gart_iommu_shutdown(), or 
whether it's a BIOS that has set up an aperture hole inconsistent with 
the memory map it passed. (or the memory map we _think_ i tried to pass 
us)

it would also be more robust to only read and do a memory map quirk 
based on that, than actively trying to change the GART so early in the 
bootup. Later on we have to re-enable the GART _anyway_ and have to 
punch a hole for it.

and as a bonus, we would have shored up our defenses against crappy 
BIOSes as well.

	Ingo
--
unsubscribe notice
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/