lkml.org 
[lkml]   [2008]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86-64: disable the GART early v2

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

> --- 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


\
 
 \ /
  Last update: 2008-01-11 09:17    [from the cache]
©2003-2011 Jasper Spaans