Re: [PATCH] x86-64: disable the GART early v2

2008-01-14 Thread Ingo Molnar

* Yinghai Lu <[EMAIL PROTECTED]> wrote:

> please check the one against x86.git it will use fix e820 for gart.

thanks, applied.

Sidenote - there were a few checkpatch failures:

 ERROR: use tabs not spaces
 #121: FILE: arch/x86/kernel/aperture_64.c:233:
 +return 0;$

 ERROR: use tabs not spaces
 #173: FILE: arch/x86/kernel/aperture_64.c:285:
 +fix = 1;$

i fixed them up. (please run "scripts/checkpatch.pl your.patch" in the 
future.)

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


Re: [PATCH] x86-64: disable the GART early v2

2008-01-12 Thread Yinghai Lu
please check the one against x86.git
it will use fix e820 for gart.

YH

[PATCH] x86-64: fix e820 for GART or disable the GART early

For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed.

when try to use kexec second kernel, and the first doesn't include 
gart_shutdown.
the second kernel could have different aper position than the first kernel. and 
second
kernel could use that hole as RAM that is still used by GART set by the first 
kernel.
esp. when try to kexec 2.6.24 with sparse mem enable from previous kernel (from 
RHEL 5
or SLES 10). the new kernel will use aper by GART (set by first kernel) for 
vmemmap.
and after new kernel setting one new GART. the position will be real RAM. the 
_mapcount
set is lost.


Bad page state in process 'swapper'
page:e2000e600020 flags:0x mapping: 
mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13

Call Trace:
 [] bad_page+0x63/0x8d
 [] __free_pages_ok+0x7c/0x2a5
 [] free_all_bootmem_core+0xd0/0x198
 [] numa_free_all_bootmem+0x3b/0x76
 [] mem_init+0x3b/0x152
 [] start_kernel+0x236/0x2c2
 [] _sinittext+0x11a/0x121

and
 [e2000e60-e2000e7f] PMD ->81001c20 on node 0
phys addr is : 0x1c20

RHEL 5.1 kernel -53 said:
PCI-DMA: aperture base @ 1c00 size 65536 KB

new kernel said:
Mapping aperture over 65536 KB of RAM @ 3c00

So could try to disable that GART if possible.

According to Ingo

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

add e820 modification for gart inconsistent setting.

gart_fix_e820=off could be used to disable e820 fix.

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

Index: linux-2.6/arch/x86/kernel/aperture_64.c
===
--- linux-2.6.orig/arch/x86/kernel/aperture_64.c
+++ linux-2.6/arch/x86/kernel/aperture_64.c
@@ -218,6 +218,95 @@ static __u32 __init search_agp_bridge(u3
return 0;
 }
 
+static int gart_fix_e820 __initdata = 1;
+
+static int __init parse_gart_mem(char *p)
+{
+   if (!p)
+   return -EINVAL;
+
+   if (!strncmp(p, "off", 3))
+   gart_fix_e820 = 0;
+   else if (!strncmp(p, "on", 2))
+   gart_fix_e820 = 1;
+
+return 0;
+}
+early_param("gart_fix_e820", parse_gart_mem);
+
+void __init early_gart_iommu_check(void)
+{
+   /*
+* in case it is enabled before, esp for kexec/kdump,
+* previous kernel already enable that. 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
+* or BIOS forget to put that in reserved.
+* try to update e820 to make that region as reserved.
+*/
+   int fix, num;
+   u32 ctl;
+   u32 aper_size = 0, aper_order = 0, last_aper_order = 0;
+   u64 aper_base = 0, last_aper_base = 0;
+   int aper_enabled = 0, last_aper_enabled = 0;
+
+   if (!early_pci_allowed())
+   return;
+
+   fix = 0;
+   for (num = 24; num < 32; num++) {
+   if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+   continue;
+
+   ctl = read_pci_config(0, num, 3, 0x90);
+   aper_enabled = ctl & 1;
+   aper_order = (ctl >> 1) & 7;
+   aper_size = (32 * 1024 * 1024) << aper_order;
+   aper_base = read_pci_config(0, num, 3, 0x94) & 0x7fff;
+   aper_base <<= 25;
+
+   if ((last_aper_order && aper_order != last_aper_order) ||
+   (last_aper_base && aper_base != last_aper_base) ||
+   (last_aper_enabled && aper_enabled != last_aper_enabled)) {
+   fix = 1;
+   break;
+   }
+   last_aper_order = aper_order;
+   last_aper_base = aper_base;
+   last_aper_enabled = aper_enabled;
+   

Re: [PATCH] x86-64: disable the GART early v2

2008-01-11 Thread Yinghai Lu
On Jan 11, 2008 12:14 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> 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)
>
good, i will update the patch to check that hole with e820 map.

that also make code short so don't need to check if agp is there or not.

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


Re: [PATCH] x86-64: disable the GART early v2

2008-01-11 Thread Ingo Molnar

* Yinghai Lu <[EMAIL PROTECTED]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] x86-64: disable the GART early v2

2008-01-10 Thread Yinghai Lu
please check the one that can be applied to x86.git -mm

YH

[PATCH] x86-64: disable the GART early v2

For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed.

when try to use kexec second kernel, and the first doesn't include 
gart_shutdown.
the second kernel could have different aper position than the first kernel. and 
second
kernel could use that hole as RAM that is still used by GART set by the first 
kernel.
esp. when try to kexec 2.6.24 with sparse mem enable from previous kernel (from 
RHEL 5
or SLES 10). the new kernel will use aper by GART (set by first kernel) for 
vmemmap.
and after new kernel setting one new GART. the position will be real RAM. the 
_mapcount
set is lost.


Bad page state in process 'swapper'
page:e2000e600020 flags:0x mapping: 
mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13

Call Trace:
 [] bad_page+0x63/0x8d
 [] __free_pages_ok+0x7c/0x2a5
 [] free_all_bootmem_core+0xd0/0x198
 [] numa_free_all_bootmem+0x3b/0x76
 [] mem_init+0x3b/0x152
 [] start_kernel+0x236/0x2c2
 [] _sinittext+0x11a/0x121

and
 [e2000e60-e2000e7f] PMD ->81001c20 on node 0
phys addr is : 0x1c20

RHEL 5.1 kernel -53 said:
PCI-DMA: aperture base @ 1c00 size 65536 KB

new kernel said:
Mapping aperture over 65536 KB of RAM @ 3c00

So try to disable that GART as early as possible.


Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>


diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 52d2bea..6e7af45 100644
--- 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
+*/
+   int fix, num;
+   u32 ctl;
+   u32 aper_size, aper_alloc = 0, aper_order = 0, last_aper_order = 0;
+   u64 aper_base, last_aper_base = 0;
+   int valid_agp = 0;
+
+   if (!early_pci_allowed())
+   return;
+
+   fix = 0;
+   for (num = 24; num < 32; num++) {
+   if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+   continue;
+
+   aper_order = (read_pci_config(0, num, 3, 0x90) >> 1) & 7;
+   aper_size = (32 * 1024 * 1024) << aper_order;
+   aper_base = read_pci_config(0, num, 3, 0x94) & 0x7fff;
+   aper_base <<= 25;
+
+   if (!aperture_valid(aper_base, aper_size)) {
+   fix = 1;
+   break;
+   }
+
+   if ((last_aper_order && aper_order != last_aper_order) ||
+   (last_aper_base && aper_base != last_aper_base)) {
+   fix = 1;
+   break;
+   }
+   last_aper_order = aper_order;
+   last_aper_base = aper_base;
+   }
+
+   if (!fix)
+   return;
+
+   aper_alloc = search_agp_bridge(&aper_order, &valid_agp);
+
+   if (aper_alloc) {
+   /*
+* could get aper later or before from the AGP bridge,
+* so it is safe
+*/
+   return;
+   }
+
+   for (num = 24; num < 32; num++) {
+   if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+   continue;
+
+   ctl = read_pci_config(0, num, 3, 0x90);
+   ctl &= ~1;
+   write_pci_config(0, num, 3, 0x90, ctl);
+   }
+
+}
+
 void __init gart_iommu_hole_init(void)
 {
u32 aper_size, aper_alloc = 0, aper_order = 0, last_aper_order = 0;
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 998ce03..da82065 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -54,6 +54,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -358,6 +359,8 @@ void __init setup_arch(char **cmdline_p)
 
discover_ebda();
 
+   early_gart_iommu_disable();
+
init_memory_mapping(0, (end_pfn_map << PAGE_SHIFT));
if (efi_enabled)
efi_init();
diff --git a/include/asm-x86/gart.h b/include/asm-x86/gart.h
index f704c50..2ca68c6 100644
--- a/include/asm-x86/gart.h
+++ b/include/asm-x86/gart.h
@@ -9,6 +9,7 @@ extern int iommu_detected;
 extern void gart_iommu_init(void);
 extern vo

[PATCH] x86-64: disable the GART early

2008-01-10 Thread Yinghai Lu
this one is against to linus tree.
in case some one need to use kexec to new kernel from old kernel with 
gart_shutdown.

YH

[PATCH] x86-64: disable the GART early

For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed.

when try to use kexec second kernel, and the first doesn't include 
gart_shutdown.
the second kernel could have different aper position than the first kernel. and 
second
kernel could use that hole as RAM that is still used by GART set by the first 
kernel.
esp. when try to kexec 2.6.24 with sparse mem enable from previous kernel (from 
RHEL 5
or SLES 10). the new kernel will use aper by GART (set by first kernel) for 
vmemmap.
and after new kernel setting one new GART. the position will be real RAM. the 
_mapcount
set is lost.


Bad page state in process 'swapper'
page:e2000e600020 flags:0x mapping: 
mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13

Call Trace:
 [] bad_page+0x63/0x8d
 [] __free_pages_ok+0x7c/0x2a5
 [] free_all_bootmem_core+0xd0/0x198
 [] numa_free_all_bootmem+0x3b/0x76
 [] mem_init+0x3b/0x152
 [] start_kernel+0x236/0x2c2
 [] _sinittext+0x11a/0x121

and
 [e2000e60-e2000e7f] PMD ->81001c20 on node 0
phys addr is : 0x1c20

RHEL 5.1 kernel -53 said:
PCI-DMA: aperture base @ 1c00 size 65536 KB

new kernel said:
Mapping aperture over 65536 KB of RAM @ 3c00

So try to disable that GART as early as possible.


Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

Index: linux-2.6/arch/x86/kernel/aperture_64.c
===
--- linux-2.6.orig/arch/x86/kernel/aperture_64.c
+++ linux-2.6/arch/x86/kernel/aperture_64.c
@@ -204,6 +204,73 @@ static __u32 __init search_agp_bridge(u3
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
+*/
+   int fix, num;
+   u32 ctl;
+u32 aper_size, aper_alloc = 0, aper_order = 0, last_aper_order = 0;
+u64 aper_base, last_aper_base = 0;
+int valid_agp = 0;
+
+if (!early_pci_allowed())
+return;
+
+   fix = 0;
+for (num = 24; num < 32; num++) {
+if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+continue;
+
+aper_order = (read_pci_config(0, num, 3, 0x90) >> 1) & 7;
+aper_size = (32 * 1024 * 1024) << aper_order;
+aper_base = read_pci_config(0, num, 3, 0x94) & 0x7fff;
+aper_base <<= 25;
+
+if (!aperture_valid(aper_base, aper_size)) {
+fix = 1;
+break;
+}
+
+if ((last_aper_order && aper_order != last_aper_order) ||
+(last_aper_base && aper_base != last_aper_base)) {
+fix = 1;
+break;
+}
+last_aper_order = aper_order;
+last_aper_base = aper_base;
+}
+
+   if (!fix)
+   return;
+
+   aper_alloc = search_agp_bridge(&aper_order, &valid_agp);
+
+   if (aper_alloc) {
+   /*
+* could get aper later or before from the AGP bridge,
+* so it is safe
+*/
+   return;
+   }
+
+   for (num = 24; num < 32; num++) {
+   if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+   continue;
+
+   ctl = read_pci_config(0, num, 3, 0x90);
+   ctl &= ~1;
+   write_pci_config(0, num, 3, 0x90, 0);
+   }
+
+}
+
 void __init gart_iommu_hole_init(void)
 { 
int fix, num; 
Index: linux-2.6/arch/x86/kernel/setup_64.c
===
--- linux-2.6.orig/arch/x86/kernel/setup_64.c
+++ linux-2.6/arch/x86/kernel/setup_64.c
@@ -256,6 +256,8 @@ static void discover_ebda(void)
ebda_size = 64*1024;
 }
 
+extern void early_gart_iommu_disable(void);
+
 void __init setup_arch(char **cmdline_p)
 {
printk(KERN_INFO "Command line: %s\n", boot_command_line);
@@ -309,6 +311,8 @@ void __init setup_arch(char **cmdline_p)
 
discover_ebda();
 
+   early_gart_iommu_disable();
+
init_memory_mapping(0, (end_pfn_map << PAGE_SHIFT));
 
dmi_scan_machine();
--
To unsubscribe from th