Home » Mailing list archives » linux-kernel » 2008 » September » 9

Re: [PATCH 1/6] pci: fix merging left out for BAR print out

Previous thread: forcedeth: option to disable 100Hz timer by Mikhail Kshevetskiy on Monday, September 1, 2008 - 3:47 pm. (2 messages)

Next thread: Finding what is stuck... by J.A. on Monday, September 1, 2008 - 5:04 pm. (6 messages)
[view original message]
From: Yinghai Lu
Subject: [PATCH 1/6] pci: fix merging left out for BAR print out
Date: Monday, September 1, 2008 - 4:37 pm

print out for Device BAR address before kernel try to update them.

also change it to KERN_DEBUG instead...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 drivers/pci/probe.c |   16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/pci/probe.c
===================================================================
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -304,6 +304,8 @@ static int __pci_read_base(struct pci_de
 		} else {
 			res->start = l64;
 			res->end = l64 + sz64;
+			printk(KERN_DEBUG "PCI: %s reg %x 64bit mmio: [%llx, %llx]\n",
+				 pci_name(dev), pos, res->start, res->end);
 		}
 	} else {
 		sz = pci_size(l, sz, mask);
@@ -313,6 +315,10 @@ static int __pci_read_base(struct pci_de
 
 		res->start = l;
 		res->end = l + sz;
+		printk(KERN_DEBUG "PCI: %s reg %x %s: [%llx, %llx]\n", pci_name(dev),
+			 pos, (res->flags & IORESOURCE_IO) ? "io port":"32bit mmio",
+			 res->start, res->end);
+
 	}
 
  out:
@@ -383,7 +389,8 @@ void __devinit pci_read_bridge_bases(str
 			res->start = base;
 		if (!res->end)
 			res->end = limit + 0xfff;
-		printk(KERN_INFO "PCI: bridge %s io port: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
+		printk(KERN_DEBUG "PCI: bridge %s io port: [%llx, %llx]\n",
+				 pci_name(dev), res->start, res->end);
 	}
 
 	res = child->resource[1];
@@ -395,7 +402,8 @@ void __devinit pci_read_bridge_bases(str
 		res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
 		res->start = base;
 		res->end = limit + 0xfffff;
-		printk(KERN_INFO "PCI: bridge %s 32bit mmio: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
+		printk(KERN_DEBUG "PCI: bridge %s 32bit mmio: [%llx, %llx]\n",
+				 pci_name(dev), res->start, res->end);
 	}
 
 	res = child->resource[2];
@@ -431,7 +439,9 @@ void __devinit pci_read_bridge_bases(str
 		res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
 ...
[ message continues ]
[view original message]
From: Yinghai Lu
Subject: [PATCH 2/6] x86: split e820 reserved entries record to late v4 - fix v7
Date: Monday, September 1, 2008 - 4:37 pm

try to insert_resource second time, by expand the resource...

for case: e820 reserved entry is partially overlapped with bar res...

hope it will never happen

v2: according to Linus, add insert_resource_expand_to_fit, and change
	__insert_resource to static without lock

v3: use reserve_region_with_split() instead to hand overlapping
	with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
	get
		e0000000-efffffff : PCI MMCONFIG 0
			 e0000000-efffffff : reserved
	in /proc/iomem
	get
		found conflict for reserved [dd800000, efffffff], try to reserve with split
		    __reserve_region_with_split: (PCI Bus #80) [dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
		    __reserve_region_with_split: (PCI Bus #00) [de000000, dfffffff], res: (reserved) [de000000, efffffff]
		initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
	in dmesg

v4: take out __insert_resource and insert_resource_expand_to_fit : Linus already check in.
    use reserve_region_with_split at the first point
    use const char *name

v5: fix checking on overlapping

v6: only reserve common area in conflict
	so got sth in /proc/iomem
		d8000000-dfffffff : PCI Bus #00
		  dc000000-dfffffff : GART
		    dc000000-dfffffff : reserved
		e0000000-efffffff : PCI MMCONFIG 0
		  e0000000-efffffff : reserved
	when we have big range in e820
		00000000dc000000-00000000f0000000 (reserved)

v7: remove wrong removing of write_unlock(&resource_lock) in adjust_resource()

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>

---
 arch/x86/kernel/e820.c |    2 -
 include/linux/ioport.h |    3 ++
 kernel/resource.c      |   68 +++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 72 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1320,7 +1320,7 @@ void ...
[ message continues ]
[view original message]
From: Yinghai Lu
Subject: [PATCH 3/6] x86: unify using pci_mmcfg_insert_resource
Date: Monday, September 1, 2008 - 4:37 pm

even with known_bridge insert them late too.

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

Index: linux-2.6/arch/x86/pci/mmconfig-shared.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/mmconfig-shared.c
+++ linux-2.6/arch/x86/pci/mmconfig-shared.c
@@ -209,7 +209,7 @@ static int __init pci_mmcfg_check_hostbr
 	return name != NULL;
 }
 
-static void __init pci_mmcfg_insert_resources(unsigned long resource_flags)
+static void __init pci_mmcfg_insert_resources(void)
 {
 #define PCI_MMCFG_RESOURCE_NAME_LEN 19
 	int i;
@@ -233,7 +233,7 @@ static void __init pci_mmcfg_insert_reso
 			 cfg->pci_segment);
 		res->start = cfg->address;
 		res->end = res->start + (num_buses << 20) - 1;
-		res->flags = IORESOURCE_MEM | resource_flags;
+		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		insert_resource(&iomem_resource, res);
 		names += PCI_MMCFG_RESOURCE_NAME_LEN;
 	}
@@ -434,11 +434,9 @@ static void __init __pci_mmcfg_init(int
 	    (pci_mmcfg_config[0].address == 0))
 		return;
 
-	if (pci_mmcfg_arch_init()) {
-		if (known_bridge)
-			pci_mmcfg_insert_resources(IORESOURCE_BUSY);
+	if (pci_mmcfg_arch_init())
 		pci_probe = (pci_probe & ~PCI_PROBE_MASK) | PCI_PROBE_MMCONF;
-	} else {
+	else {
 		/*
 		 * Signal not to attempt to insert mmcfg resources because
 		 * the architecture mmcfg setup could not initialize.
@@ -475,7 +473,7 @@ static int __init pci_mmcfg_late_insert_
 	 * marked so it won't cause request errors when __request_region is
 	 * called.
 	 */
-	pci_mmcfg_insert_resources(0);
+	pci_mmcfg_insert_resources();
 
 	return 0;
 }
--


[ message continues ]
[view original message]
From: Yinghai Lu
Subject: [PATCH 4/6] x86: delay early cpu initialization until cpuid is done
Date: Monday, September 1, 2008 - 4:37 pm

From: Krzysztof Helt <krzysztof.h1@wp.pl>

Move early cpu initialization after cpu
early get cap so the early cpu initialization
can fix up cpu caps.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index d3bc82f..f970cbf 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -335,11 +335,11 @@ static void __init early_cpu_detect(void)
 
 	get_cpu_vendor(c, 1);
 
+	early_get_cap(c);
+
 	if (c->x86_vendor != X86_VENDOR_UNKNOWN &&
 	    cpu_devs[c->x86_vendor]->c_early_init)
 		cpu_devs[c->x86_vendor]->c_early_init(c);
-
-	early_get_cap(c);
 }
 
 /*
--


[ message continues ]
[view original message]
From: Yinghai Lu
Subject: [PATCH 5/6] x86: move mtrr cpu cap setting early in early_init_xxxx
Date: Monday, September 1, 2008 - 4:37 pm

Krzysztof Helt <krzysztof.h1@wp.pl> found mtrr is not detected on k6-2

root case:
	we move mtrr_bp_init early for mtrr trimming.
and in early_detect, only read cap from cpuid, so some cpu doesn't have
that bit in cpuid and need to set workaround bit will have problem.

need to add early_init_xxxx to preset those bit before mtrr_bp_init
for those earlier cpus.

this patch is for 2.6.27

Reported-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>

---
 arch/x86/kernel/cpu/amd.c     |    9 +++++----
 arch/x86/kernel/cpu/centaur.c |   11 +++++++++++
 arch/x86/kernel/cpu/cyrix.c   |   32 ++++++++++++++++++++++++++++----
 3 files changed, 44 insertions(+), 8 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/amd.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/amd.c
+++ linux-2.6/arch/x86/kernel/cpu/amd.c
@@ -31,6 +31,11 @@ static void __cpuinit early_init_amd(str
 		if (c->x86_power & (1<<8))
 			set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
 	}
+
+	/*  Set MTRR capability flag if appropriate */
+	if (c->x86_model == 13 || c->x86_model == 9 ||
+	   (c->x86_model == 8 && c->x86_mask >= 8))
+		set_cpu_cap(c, X86_FEATURE_K6_MTRR);
 }
 
 static void __cpuinit init_amd(struct cpuinfo_x86 *c)
@@ -166,10 +171,6 @@ static void __cpuinit init_amd(struct cp
 						mbytes);
 				}
 
-				/*  Set MTRR capability flag if appropriate */
-				if (c->x86_model == 13 || c->x86_model == 9 ||
-				   (c->x86_model == 8 && c->x86_mask >= 8))
-					set_cpu_cap(c, X86_FEATURE_K6_MTRR);
 				break;
 			}
 
Index: linux-2.6/arch/x86/kernel/cpu/centaur.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/centaur.c
+++ linux-2.6/arch/x86/kernel/cpu/centaur.c
@@ -314,6 +314,16 @@ enum {
 		EAMD3D		= 1<<20,
 };
 
+static void __cpuinit early_init_centaur(struct cpuinfo_x86 *c)
+{
+	switch ...
[ message continues ]
[view original message]
From: Ingo Molnar
Subject: Re: [PATCH 5/6] x86: move mtrr cpu cap setting early in early_init_xxxx
Date: Thursday, September 4, 2008 - 12:13 pm

hm, not sure we can do it in v2.6.27 as it depends on the other CPU init 
patches and that is a rather sensitive codepath. This problem should be 
present in v2.6.26 too, right?

	Ingo
--


[ message continues ]
[view original message]
From: Yinghai Lu
Subject: Re: [PATCH 5/6] x86: move mtrr cpu cap setting early in early_init_xxxx
Date: Thursday, September 4, 2008 - 12:17 pm

Yes. old cpus without cpuid bit for mtrr need this patch...
Krzysztof Helt tested it and it works with 2.6.27-rc5 (?)


YH
--


[ message continues ]
[view original message]
From: Krzysztof Helt
Subject: Re: [PATCH 5/6] x86: move mtrr cpu cap setting early in early_init_xxxx
Date: Thursday, September 4, 2008 - 1:14 pm

On Thu, 4 Sep 2008 12:17:14 -0700

Yes, I tested the patches with 2.6.27-rc5.

I was too lazy to find the case of this breakage as the mtrr register
detection was "always" displayed during boot on this machine.
I found the source of the breakage now:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=03ae5768b6...

The  early_cpu_init() called directly amd_init_cpu() which set up mtrr flags on K6 cpus. 
This got removed by this patch with no replacement. This is dated as 2008-04-17.

As the K6 machine is my secondary computer (to test older stuff, ISA, etc) I do not
boot it every day. Add holidays and it could be that it went unnoticed since April.

I hope this is answer your question. If you want I can retest the 2.6.26 kernel version.

Kind regards,
Krzysztof

----------------------------------------------------------------------
Mobilne aplikacje na Twoj telefon!
Sprawdz >> http://link.interia.pl/f1eff 

--


[ message continues ]
[view original message]
From: Ingo Molnar
Subject: Re: [PATCH 5/6] x86: move mtrr cpu cap setting early in early_init_xxxx
Date: Saturday, September 6, 2008 - 8:51 am

ok, i've cherry-picked those two commits over into tip/x86/urgent.

	Ingo
--


[ message continues ]
[view original message]
From: Yinghai Lu
Subject: [PATCH 6/6] x86: make (early)_identify_cpu more the same between 32bit and 64 bit
Date: Monday, September 1, 2008 - 4:37 pm

1. add extended_cpuid_level for 32bit
2. add generic_identify for 64bit
3. add early_identify_cpu for 32bit
4. early_identify_cpu not be called by identify_cpu
5. remove early in get_cpu_vendor for 32bit
6. add get_cpu_cap
7. add cpu_detect for 64bit

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 arch/x86/kernel/cpu/common.c    |  136 ++++++++++++++-------------------------
 arch/x86/kernel/cpu/common_64.c |  139 +++++++++++++++++++++++++---------------
 include/asm-x86/processor.h     |    2 
 3 files changed, 141 insertions(+), 136 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common.c
+++ linux-2.6/arch/x86/kernel/cpu/common.c
@@ -96,7 +96,7 @@ int __cpuinit get_model_name(struct cpui
 	unsigned int *v;
 	char *p, *q;
 
-	if (cpuid_eax(0x80000000) < 0x80000004)
+	if (c->extended_cpuid_level < 0x80000004)
 		return 0;
 
 	v = (unsigned int *) c->x86_model_id;
@@ -125,7 +125,7 @@ void __cpuinit display_cacheinfo(struct
 {
 	unsigned int n, dummy, ecx, edx, l2size;
 
-	n = cpuid_eax(0x80000000);
+	n = c->extended_cpuid_level;
 
 	if (n >= 0x80000005) {
 		cpuid(0x80000005, &dummy, &dummy, &ecx, &edx);
@@ -186,7 +186,7 @@ static char __cpuinit *table_lookup_mode
 }
 
 
-static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c, int early)
+static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c)
 {
 	char *v = c->x86_vendor_id;
 	int i;
@@ -198,8 +198,7 @@ static void __cpuinit get_cpu_vendor(str
 			    (cpu_devs[i]->c_ident[1] &&
 			     !strcmp(v, cpu_devs[i]->c_ident[1]))) {
 				c->x86_vendor = i;
-				if (!early)
-					this_cpu = cpu_devs[i];
+				this_cpu = cpu_devs[i];
 				return;
 			}
 		}
@@ -284,34 +283,30 @@ void __init cpu_detect(struct cpuinfo_x8
 		}
 	}
 }
-static void __cpuinit early_get_cap(struct cpuinfo_x86 *c)
+
+static void __cpuinit get_cpu_cap(struct cpuinfo_x86 *c)
 {
 	u32 tfms, ...
[ message continues ]
[view original message]
From: Jesse Barnes
Subject: Re: [PATCH 1/6] pci: fix merging left out for BAR print out
Date: Tuesday, September 9, 2008 - 11:45 am

Can you resend this against my linux-next branch?  It didn't apply to my 
latest bits...

Thanks,
Jesse
--


[ message continues ]
Previous thread: forcedeth: option to disable 100Hz timer by Mikhail Kshevetskiy on Monday, September 1, 2008 - 3:47 pm. (2 messages)

Next thread: Finding what is stuck... by J.A. on Monday, September 1, 2008 - 5:04 pm. (6 messages)