kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Ciaran McCreesh]

[-- Attachment #1.1: Type: text/plain, Size: 858 bytes --]

The commit 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f (x86:
insert_resorce for lapic addr after e820_reserve_resources) causes my
x86_64 box to to lock up early on in the boot process. Reverting only
this commit with current git head gives a successful boot.

The last messages outputted to the screen with a failed boot are:

    pci 0000:00:13.2: OHCI: BIOS handoff failed (BIOS bug?) 00000184
    Clocksource tsc unstable (delta = 475235503 ns)

The handoff message appears not to be related, and occurs with all
kernels. The 'clocksource' message appears only with the above commit.

The box has an Abit F-190HD motherboard with a Q6600 CPU. A .config,
dmesg from git head with the above commit reverted and lspci -v are
attached.

What further information can I provide to help work this issue out?

Many thanks,
-- 
Ciaran McCreesh

[-- Attachment #1.2: config.txt.gz --]
[-- Type: application/octet-stream, Size: 12235 bytes --]

[-- Attachment #1.3: dmesg.txt.gz --]
[-- Type: application/octet-stream, Size: 9277 bytes --]

[-- Attachment #1.4: lspci.txt.gz --]
[-- Type: application/octet-stream, Size: 1244 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

On Sat, May 17, 2008 at 5:41 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> The commit 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f (x86:
> insert_resorce for lapic addr after e820_reserve_resources) causes my
> x86_64 box to to lock up early on in the boot process. Reverting only
> this commit with current git head gives a successful boot.
>
> The last messages outputted to the screen with a failed boot are:
>
>    pci 0000:00:13.2: OHCI: BIOS handoff failed (BIOS bug?) 00000184
>    Clocksource tsc unstable (delta = 475235503 ns)
>
> The handoff message appears not to be related, and occurs with all
> kernels. The 'clocksource' message appears only with the above commit.
>
> The box has an Abit F-190HD motherboard with a Q6600 CPU. A .config,
> dmesg from git head with the above commit reverted and lspci -v are
> attached.
>
> What further information can I provide to help work this issue out?

can you try to boot with apic=verbose? please don't revert that patch...

wonder if init_apic_mapping need some delay with that strange chipset.

YH

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Ciaran McCreesh]

[-- Attachment #1.1: Type: text/plain, Size: 932 bytes --]

On Sat, 17 May 2008 20:55:20 -0700
"Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> On Sat, May 17, 2008 at 5:41 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > The commit 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f (x86:
> > insert_resorce for lapic addr after e820_reserve_resources) causes
> > my x86_64 box to to lock up early on in the boot process. Reverting
> > only this commit with current git head gives a successful boot.
>
> can you try to boot with apic=verbose? please don't revert that
> patch...
> 
> wonder if init_apic_mapping need some delay with that strange chipset.

I don't see any additional information with apic=verbose with the
broken kernel (although I only have a screen's worth of text that I can
see -- the kernel doesn't get far enough to let me grab it). I've
attached dmesg from a working kernel with apic=verbose in case that
helps.

Thanks,
-- 
Ciaran McCreesh

[-- Attachment #1.2: dmesg-apic-verbose.txt.gz --]
[-- Type: application/octet-stream, Size: 10315 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

On Sun, May 18, 2008 at 8:41 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 17 May 2008 20:55:20 -0700
> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>> On Sat, May 17, 2008 at 5:41 PM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> > The commit 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f (x86:
>> > insert_resorce for lapic addr after e820_reserve_resources) causes
>> > my x86_64 box to to lock up early on in the boot process. Reverting
>> > only this commit with current git head gives a successful boot.
>>
>> can you try to boot with apic=verbose? please don't revert that
>> patch...
>>
>> wonder if init_apic_mapping need some delay with that strange chipset.
>
> I don't see any additional information with apic=verbose with the
> broken kernel (although I only have a screen's worth of text that I can
> see -- the kernel doesn't get far enough to let me grab it). I've
> attached dmesg from a working kernel with apic=verbose in case that
> helps.

or try to boot with initcall_debug to see where did it hang.

YH

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

On Sun, 18 May 2008 14:00:16 -0700
"Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> >> wonder if init_apic_mapping need some delay with that strange
> >> chipset.
> >
> > I don't see any additional information with apic=verbose with the
> > broken kernel (although I only have a screen's worth of text that I
> > can see -- the kernel doesn't get far enough to let me grab it).
> > I've attached dmesg from a working kernel with apic=verbose in case
> > that helps.
> 
> or try to boot with initcall_debug to see where did it hang.

The last initcall_debug messages are:

    calling atiixp_ide_init+0x0/0x20
    initcall atiixp_ide_init+0x0/0x20 returned 0 after 0 msecs
    calling piix_ide_init+0x0/0xc0
    initcall piix_ide_init+0x0/0xc0 returned 0 after 0 msecs
    calling ide_scan_pcibus+0x0/0x100

ide_scan_pcibus doesn't return. I tried shoving some printks in there,
but as soon as I did it instead locked up in pci_init. Is it worth
continuing this approach or will doing so not give useful results
anyway?

Thanks,
-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

On Sun, May 18, 2008 at 3:23 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 18 May 2008 14:00:16 -0700
> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>> >> wonder if init_apic_mapping need some delay with that strange
>> >> chipset.
>> >
>> > I don't see any additional information with apic=verbose with the
>> > broken kernel (although I only have a screen's worth of text that I
>> > can see -- the kernel doesn't get far enough to let me grab it).
>> > I've attached dmesg from a working kernel with apic=verbose in case
>> > that helps.
>>
>> or try to boot with initcall_debug to see where did it hang.
>
> The last initcall_debug messages are:
>
>    calling atiixp_ide_init+0x0/0x20
>    initcall atiixp_ide_init+0x0/0x20 returned 0 after 0 msecs
>    calling piix_ide_init+0x0/0xc0
>    initcall piix_ide_init+0x0/0xc0 returned 0 after 0 msecs
>    calling ide_scan_pcibus+0x0/0x100
>
> ide_scan_pcibus doesn't return. I tried shoving some printks in there,
> but as soon as I did it instead locked up in pci_init. Is it worth
> continuing this approach or will doing so not give useful results
> anyway?

could be pci iomem conflicts...
please enable CONFIG_PCI_DEBUG=y
and apply the following two debug patches

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: debug_extra_pci_res_range.patch --]
[-- Type: text/x-patch; name=debug_extra_pci_res_range.patch, Size: 1787 bytes --]

Index: linux-2.6/drivers/pci/probe.c
===================================================================
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -275,6 +275,7 @@ static void pci_read_bases(struct pci_de
 			}
 			res->start = l64 & PCI_BASE_ADDRESS_MEM_MASK;
 			res->end = res->start + sz64;
+			printk(KERN_INFO "PCI: %s reg %x 64bit mmio: [%llx, %llx]\n", pci_name(dev), reg, res->start, res->end);
 #else
 			if (sz64 > 0x100000000ULL) {
 				printk(KERN_ERR "PCI: Unable to handle 64-bit "
@@ -290,6 +291,8 @@ static void pci_read_bases(struct pci_de
 				res->end = sz;
 			}
 #endif
+		} else {
+			printk(KERN_INFO "PCI: %s reg %x %s: [%llx, %llx]\n", pci_name(dev), reg, (res->flags & IORESOURCE_IO)? "io port":"32bit mmio", res->start, res->end);
 		}
 	}
 	if (rom) {
@@ -357,6 +360,7 @@ 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);
 	}
 
 	res = child->resource[1];
@@ -368,6 +372,7 @@ 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);
 	}
 
 	res = child->resource[2];
@@ -402,6 +407,7 @@ void __devinit pci_read_bridge_bases(str
 		res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
 		res->start = base;
 		res->end = limit + 0xfffff;
+		printk(KERN_INFO "PCI: bridge %s %sbit mmio pref: [%llx, %llx]\n", pci_name(dev), (res->flags & PCI_PREF_RANGE_TYPE_64)?"64":"32",res->start, res->end);
 	}
 }
 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: debug_extra_pci_bus_res.patch --]
[-- Type: text/x-patch; name=debug_extra_pci_bus_res.patch, Size: 1299 bytes --]

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -537,6 +537,36 @@ void __ref pci_bus_assign_resources(stru
 }
 EXPORT_SYMBOL(pci_bus_assign_resources);
 
+static void pci_bus_dump_res(struct pci_bus *bus)
+{
+        int i;
+
+        for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
+                struct resource *res = bus->resource[i];
+                if (!res)
+                        continue;
+
+		printk(KERN_INFO "bus: %02x index %x %s: [%llx, %llx]\n", bus->number, i, (res->flags & IORESOURCE_IO)? "io port":"mmio", res->start, res->end);
+        }
+}
+
+static void pci_bus_dump_resources(struct pci_bus *bus)
+{
+	struct pci_bus *b;
+	struct pci_dev *dev;
+
+
+	pci_bus_dump_res(bus);
+
+	list_for_each_entry(dev, &bus->devices, bus_list) {
+		b = dev->subordinate;
+		if (!b)
+			continue;
+
+		pci_bus_dump_resources(b);
+	}
+}
+
 void __init
 pci_assign_unassigned_resources(void)
 {
@@ -552,4 +582,9 @@ pci_assign_unassigned_resources(void)
 		pci_bus_assign_resources(bus);
 		pci_enable_bridges(bus);
 	}
+
+	/* dump the resource on buses */
+	list_for_each_entry(bus, &pci_root_buses, node) {
+		pci_bus_dump_resources(bus);
+	}
 }

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Ciaran McCreesh]

[-- Attachment #1.1: Type: text/plain, Size: 500 bytes --]

On Sun, 18 May 2008 20:43:09 -0700
"Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> > ide_scan_pcibus doesn't return. I tried shoving some printks in
> > there, but as soon as I did it instead locked up in pci_init. Is it
> > worth continuing this approach or will doing so not give useful
> > results anyway?
> 
> could be pci iomem conflicts...
> please enable CONFIG_PCI_DEBUG=y
> and apply the following two debug patches

dmesg with debugging attached.

Thanks.
-- 
Ciaran McCreesh

[-- Attachment #1.2: dmesg-pci-debug.txt.gz --]
[-- Type: application/octet-stream, Size: 12584 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

On Mon, May 19, 2008 at 5:44 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 18 May 2008 20:43:09 -0700
> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>> > ide_scan_pcibus doesn't return. I tried shoving some printks in
>> > there, but as soon as I did it instead locked up in pci_init. Is it
>> > worth continuing this approach or will doing so not give useful
>> > results anyway?
>>
>> could be pci iomem conflicts...
>> please enable CONFIG_PCI_DEBUG=y
>> and apply the following two debug patches
>
> dmesg with debugging attached.
>

the iomem allocation seems good...

can you send out /proc/iomem?

Thanks

YH

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

On Mon, 19 May 2008 18:22:00 -0700
"Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> >> could be pci iomem conflicts...
> >> please enable CONFIG_PCI_DEBUG=y
> >> and apply the following two debug patches
> >
> > dmesg with debugging attached.
> 
> the iomem allocation seems good...
> 
> can you send out /proc/iomem?

00000000-0009ffff : pnp 00:09
000f0000-000fffff : pnp 00:09
00100000-d7feffff : pnp 00:09
d7ff0000-d7ffffff : pnp 00:09
d8000000-dfffffff : PCI Bus 0000:01
  d8000000-dfffffff : 0000:01:05.0
e0000000-efffffff : PCI MMCONFIG 0
  e0000000-efffffff : pnp 00:08
fdb00000-fdbfffff : PCI Bus 0000:03
fdc00000-fdcfffff : PCI Bus 0000:03
  fdcff000-fdcff0ff : 0000:03:05.0
    fdcff000-fdcff0ff : 8139too
fdd00000-fddfffff : PCI Bus 0000:02
  fdd00000-fdd1ffff : 0000:02:00.0
fde00000-fdefffff : PCI Bus 0000:02
  fdeff000-fdefffff : 0000:02:00.0
    fdeff000-fdefffff : r8169
fdf00000-fdffffff : PCI Bus 0000:01
  fdf00000-fdf03fff : 0000:01:05.2
    fdf00000-fdf03fff : ICH HD audio
  fdff0000-fdffffff : 0000:01:05.0
fe024000-fe027fff : 0000:00:14.2
  fe024000-fe027fff : ICH HD audio
fe029000-fe0290ff : 0000:00:13.5
  fe029000-fe0290ff : ehci_hcd
fe02a000-fe02afff : 0000:00:13.4
  fe02a000-fe02afff : ohci_hcd
fe02b000-fe02bfff : 0000:00:13.3
  fe02b000-fe02bfff : ohci_hcd
fe02c000-fe02cfff : 0000:00:13.2
  fe02c000-fe02cfff : ohci_hcd
fe02d000-fe02dfff : 0000:00:13.1
  fe02d000-fe02dfff : ohci_hcd
fe02e000-fe02efff : 0000:00:13.0
  fe02e000-fe02efff : ohci_hcd
fe02f000-fe02f3ff : 0000:00:12.0
  fe02f000-fe02f3ff : ahci
fec00000-fec00fff : IOAPIC 0
  fec00000-fec00fff : pnp 00:09
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : 0000:00:14.0
    fed00000-fed000ff : pnp 00:09
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : pnp 00:09
ffff0000-ffffffff : pnp 00:09
100000000-11fffffff : System RAM
  00200000-005d348d : Kernel code
  005d348e-00771927 : Kernel data
  007df000-0085f74f : Kernel bss

Thanks,
-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

On Mon, May 19, 2008 at 6:24 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 19 May 2008 18:22:00 -0700
> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>> >> could be pci iomem conflicts...
>> >> please enable CONFIG_PCI_DEBUG=y
>> >> and apply the following two debug patches
>> >
>> > dmesg with debugging attached.
>>
>> the iomem allocation seems good...
>>
>> can you send out /proc/iomem?
>
> 00000000-0009ffff : pnp 00:09
> 000f0000-000fffff : pnp 00:09
> 00100000-d7feffff : pnp 00:09
> d7ff0000-d7ffffff : pnp 00:09
> d8000000-dfffffff : PCI Bus 0000:01
>  d8000000-dfffffff : 0000:01:05.0
> e0000000-efffffff : PCI MMCONFIG 0
>  e0000000-efffffff : pnp 00:08
> fdb00000-fdbfffff : PCI Bus 0000:03
> fdc00000-fdcfffff : PCI Bus 0000:03
>  fdcff000-fdcff0ff : 0000:03:05.0
>    fdcff000-fdcff0ff : 8139too
> fdd00000-fddfffff : PCI Bus 0000:02
>  fdd00000-fdd1ffff : 0000:02:00.0
> fde00000-fdefffff : PCI Bus 0000:02
>  fdeff000-fdefffff : 0000:02:00.0
>    fdeff000-fdefffff : r8169
> fdf00000-fdffffff : PCI Bus 0000:01
>  fdf00000-fdf03fff : 0000:01:05.2
>    fdf00000-fdf03fff : ICH HD audio
>  fdff0000-fdffffff : 0000:01:05.0
> fe024000-fe027fff : 0000:00:14.2
>  fe024000-fe027fff : ICH HD audio
> fe029000-fe0290ff : 0000:00:13.5
>  fe029000-fe0290ff : ehci_hcd
> fe02a000-fe02afff : 0000:00:13.4
>  fe02a000-fe02afff : ohci_hcd
> fe02b000-fe02bfff : 0000:00:13.3
>  fe02b000-fe02bfff : ohci_hcd
> fe02c000-fe02cfff : 0000:00:13.2
>  fe02c000-fe02cfff : ohci_hcd
> fe02d000-fe02dfff : 0000:00:13.1
>  fe02d000-fe02dfff : ohci_hcd
> fe02e000-fe02efff : 0000:00:13.0
>  fe02e000-fe02efff : ohci_hcd
> fe02f000-fe02f3ff : 0000:00:12.0
>  fe02f000-fe02f3ff : ahci
> fec00000-fec00fff : IOAPIC 0
>  fec00000-fec00fff : pnp 00:09
> fed00000-fed003ff : HPET 0
>  fed00000-fed003ff : 0000:00:14.0
>    fed00000-fed000ff : pnp 00:09
> fee00000-fee00fff : Local APIC
>  fee00000-fee00fff : pnp 00:09
> ffff0000-ffffffff : pnp 00:09
> 100000000-11fffffff : System RAM
>  00200000-005d348d : Kernel code
>  005d348e-00771927 : Kernel data
>  007df000-0085f74f : Kernel bss


seems acpi pnp resource cause some problem....

please try attached patch and send out /proc/mtrr

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ram_reserve.patch --]
[-- Type: text/x-patch; name=ram_reserve.patch, Size: 1993 bytes --]

[PATCH] x86: use request instead of insert resource for e820 - 64bit

to prevent acpi pnp messing it up later with request.
otherwise some system will show
00000000-0009ffff : pnp 00:09
000f0000-000fffff : pnp 00:09
00100000-d7feffff : pnp 00:09
d7ff0000-d7ffffff : pnp 00:09

instead of System RAM...

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

Index: linux-2.6/arch/x86/kernel/e820_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820_64.c
+++ linux-2.6/arch/x86/kernel/e820_64.c
@@ -88,7 +88,7 @@ void __init e820_reserve_resources(void)
 		res->start = e820.map[i].addr;
 		res->end = res->start + e820.map[i].size - 1;
 		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-		insert_resource(&iomem_resource, res);
+		request_resource(&iomem_resource, res);
 		res++;
 	}
 }
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
@@ -361,11 +361,6 @@ void __init setup_arch(char **cmdline_p)
 
 	finish_e820_parsing();
 
-	/* after parse_early_param, so could debug it */
-	insert_resource(&iomem_resource, &code_resource);
-	insert_resource(&iomem_resource, &data_resource);
-	insert_resource(&iomem_resource, &bss_resource);
-
 	early_gart_iommu_check();
 
 	e820_register_active_regions(0, 0, -1UL);
@@ -471,6 +466,11 @@ void __init setup_arch(char **cmdline_p)
 		}
 	}
 #endif
+	e820_reserve_resources();
+	insert_resource(&iomem_resource, &code_resource);
+	insert_resource(&iomem_resource, &data_resource);
+	insert_resource(&iomem_resource, &bss_resource);
+
 	reserve_crashkernel();
 
 	reserve_ibft_region();
@@ -502,7 +502,6 @@ void __init setup_arch(char **cmdline_p)
 	/*
 	 * We trust e820 completely. No explicit ROM probing in memory.
 	 */
-	e820_reserve_resources();
 	e820_mark_nosave_regions();
 
 	/* request I/O space for devices used on all i[345]86 PCs */

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Mon, 19 May 2008 19:48:38 -0700
"Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> >> >> could be pci iomem conflicts...
> >> >> please enable CONFIG_PCI_DEBUG=y
> >> >> and apply the following two debug patches
> >> >
> >> > dmesg with debugging attached.
> >>
> >> the iomem allocation seems good...
> >>
> >> can you send out /proc/iomem?
> >
> > 00000000-0009ffff : pnp 00:09
> > <snip>
> 
> seems acpi pnp resource cause some problem....
> 
> please try attached patch and send out /proc/mtrr

The patch doesn't help I'm afraid.

/proc/mtrr is:

reg00: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg01: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg02: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg03: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg04: base=0xd0000000 (3328MB), size= 128MB: write-back, count=1

Thanks,
-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

On Mon, May 19, 2008 at 8:16 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 19 May 2008 19:48:38 -0700
> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>> >> >> could be pci iomem conflicts...
>> >> >> please enable CONFIG_PCI_DEBUG=y
>> >> >> and apply the following two debug patches
>> >> >
>> >> > dmesg with debugging attached.
>> >>
>> >> the iomem allocation seems good...
>> >>
>> >> can you send out /proc/iomem?
>> >
>> > 00000000-0009ffff : pnp 00:09
>> > <snip>
>>
>> seems acpi pnp resource cause some problem....
>>
>> please try attached patch and send out /proc/mtrr
>
> The patch doesn't help I'm afraid.

sorry, please send /proc/iomem

after check request_resource and insert resource...

it seems if you insert or request one small one, and request big one,
then only have big one, but if you insert the big one, the small one
will because big one's child...

so at that case, could be pnp res return from acpi (dsdt) is bigger
than e820 region...

so it seems the offending patch just reveal problem cause by pnp code.

YH

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

On Mon, May 19, 2008 at 8:22 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Mon, May 19, 2008 at 8:16 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Mon, 19 May 2008 19:48:38 -0700
>> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>>> >> >> could be pci iomem conflicts...
>>> >> >> please enable CONFIG_PCI_DEBUG=y
>>> >> >> and apply the following two debug patches
>>> >> >
>>> >> > dmesg with debugging attached.
>>> >>
>>> >> the iomem allocation seems good...
>>> >>
>>> >> can you send out /proc/iomem?
>>> >
>>> > 00000000-0009ffff : pnp 00:09
>>> > <snip>
>>>
>>> seems acpi pnp resource cause some problem....
>>>
>>> please try attached patch and send out /proc/mtrr
>>
>> The patch doesn't help I'm afraid.
>
> sorry, please send /proc/iomem
>
> after check request_resource and insert resource...
>
> it seems if you insert or request one small one, and request big one,
> then only have big one, but if you insert the big one, the small one
> will because big one's child...
>
> so at that case, could be pnp res return from acpi (dsdt) is bigger
> than e820 region...
>
> so it seems the offending patch just reveal problem cause by pnp code.

can you boot with pnpacpi=off ?

YH

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

(Apologies for the delay. I've not had physical access to the box for a
few days.)

On Mon, 19 May 2008 20:22:45 -0700
"Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> >> seems acpi pnp resource cause some problem....
> >>
> >> please try attached patch and send out /proc/mtrr
> >
> > The patch doesn't help I'm afraid.
> 
> sorry, please send /proc/iomem

Sorry, I'm getting confused here. I can't send /proc/iomem with the
ram_reserve patch applied since the system won't boot (and it appears
to collide with the original commit, so I can't revert that and apply
the patch to get a booting system). Without the ram_reserve
patch, /proc/iomem is as it was earlier in the discussion.

> can you boot with pnpacpi=off ?

No, that doesn't help either.

Thanks,
-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

On Fri, May 23, 2008 at 4:50 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> (Apologies for the delay. I've not had physical access to the box for a
> few days.)
>
> On Mon, 19 May 2008 20:22:45 -0700
> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>> >> seems acpi pnp resource cause some problem....
>> >>
>> >> please try attached patch and send out /proc/mtrr
>> >
>> > The patch doesn't help I'm afraid.
>>
>> sorry, please send /proc/iomem
>
> Sorry, I'm getting confused here. I can't send /proc/iomem with the
> ram_reserve patch applied since the system won't boot (and it appears
> to collide with the original commit, so I can't revert that and apply
> the patch to get a booting system).

You don't need that patch...

> Without the ram_reserve
> patch, /proc/iomem is as it was earlier in the discussion.
>
>> can you boot with pnpacpi=off ?
>
> No, that doesn't help either.
how about /proc/iomem with pnpacpi=off?

YH

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Ciaran McCreesh]

[-- Attachment #1.1: Type: text/plain, Size: 440 bytes --]

On Fri, 23 May 2008 17:05:34 -0700
"Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> > Without the ram_reserve
> > patch, /proc/iomem is as it was earlier in the discussion.
> >
> >> can you boot with pnpacpi=off ?
> >
> > No, that doesn't help either.
>
> how about /proc/iomem with pnpacpi=off?

I've attached /proc/iomem from current head minus the original patch,
with and without pnpacpi=off.

Thanks,
-- 
Ciaran McCreesh

[-- Attachment #1.2: iomem-normal.txt --]
[-- Type: text/plain, Size: 1657 bytes --]

00000000-0009ffff : pnp 00:09
000f0000-000fffff : pnp 00:09
00100000-d7feffff : pnp 00:09
d7ff0000-d7ffffff : pnp 00:09
d8000000-dfffffff : PCI Bus 0000:01
  d8000000-dfffffff : 0000:01:05.0
e0000000-efffffff : PCI MMCONFIG 0
  e0000000-efffffff : pnp 00:08
fdb00000-fdbfffff : PCI Bus 0000:03
fdc00000-fdcfffff : PCI Bus 0000:03
  fdcff000-fdcff0ff : 0000:03:05.0
    fdcff000-fdcff0ff : 8139too
fdd00000-fddfffff : PCI Bus 0000:02
  fdd00000-fdd1ffff : 0000:02:00.0
fde00000-fdefffff : PCI Bus 0000:02
  fdeff000-fdefffff : 0000:02:00.0
    fdeff000-fdefffff : r8169
fdf00000-fdffffff : PCI Bus 0000:01
  fdf00000-fdf03fff : 0000:01:05.2
    fdf00000-fdf03fff : ICH HD audio
  fdff0000-fdffffff : 0000:01:05.0
fe024000-fe027fff : 0000:00:14.2
  fe024000-fe027fff : ICH HD audio
fe029000-fe0290ff : 0000:00:13.5
  fe029000-fe0290ff : ehci_hcd
fe02a000-fe02afff : 0000:00:13.4
  fe02a000-fe02afff : ohci_hcd
fe02b000-fe02bfff : 0000:00:13.3
  fe02b000-fe02bfff : ohci_hcd
fe02c000-fe02cfff : 0000:00:13.2
  fe02c000-fe02cfff : ohci_hcd
fe02d000-fe02dfff : 0000:00:13.1
  fe02d000-fe02dfff : ohci_hcd
fe02e000-fe02efff : 0000:00:13.0
  fe02e000-fe02efff : ohci_hcd
fe02f000-fe02f3ff : 0000:00:12.0
  fe02f000-fe02f3ff : ahci
fec00000-fec00fff : IOAPIC 0
  fec00000-fec00fff : pnp 00:09
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : 0000:00:14.0
    fed00000-fed000ff : pnp 00:09
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : pnp 00:09
ffff0000-ffffffff : pnp 00:09
100000000-11fffffff : System RAM
  00200000-005d356d : Kernel code
  005d356e-00770927 : Kernel data
  007df000-0085f74f : Kernel bss

[-- Attachment #1.3: iomem-pnpacpi-off.txt --]
[-- Type: text/plain, Size: 1368 bytes --]

d8000000-dfffffff : PCI Bus 0000:01
  d8000000-dfffffff : 0000:01:05.0
e0000000-efffffff : PCI MMCONFIG 0
fdb00000-fdbfffff : PCI Bus 0000:03
fdc00000-fdcfffff : PCI Bus 0000:03
  fdcff000-fdcff0ff : 0000:03:05.0
    fdcff000-fdcff0ff : 8139too
fdd00000-fddfffff : PCI Bus 0000:02
  fdd00000-fdd1ffff : 0000:02:00.0
fde00000-fdefffff : PCI Bus 0000:02
  fdeff000-fdefffff : 0000:02:00.0
    fdeff000-fdefffff : r8169
fdf00000-fdffffff : PCI Bus 0000:01
  fdf00000-fdf03fff : 0000:01:05.2
    fdf00000-fdf03fff : ICH HD audio
  fdff0000-fdffffff : 0000:01:05.0
fe024000-fe027fff : 0000:00:14.2
  fe024000-fe027fff : ICH HD audio
fe029000-fe0290ff : 0000:00:13.5
  fe029000-fe0290ff : ehci_hcd
fe02a000-fe02afff : 0000:00:13.4
  fe02a000-fe02afff : ohci_hcd
fe02b000-fe02bfff : 0000:00:13.3
  fe02b000-fe02bfff : ohci_hcd
fe02c000-fe02cfff : 0000:00:13.2
  fe02c000-fe02cfff : ohci_hcd
fe02d000-fe02dfff : 0000:00:13.1
  fe02d000-fe02dfff : ohci_hcd
fe02e000-fe02efff : 0000:00:13.0
  fe02e000-fe02efff : ohci_hcd
fe02f000-fe02f3ff : 0000:00:12.0
  fe02f000-fe02f3ff : ahci
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : 0000:00:14.0
fee00000-fee00fff : Local APIC
100000000-11fffffff : System RAM
  00200000-005d356d : Kernel code
  005d356e-00770927 : Kernel data
  007df000-0085f74f : Kernel bss

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

On Fri, May 23, 2008 at 6:09 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Fri, 23 May 2008 17:05:34 -0700
> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>> > Without the ram_reserve
>> > patch, /proc/iomem is as it was earlier in the discussion.
>> >
>> >> can you boot with pnpacpi=off ?
>> >
>> > No, that doesn't help either.
>>
>> how about /proc/iomem with pnpacpi=off?
>
> I've attached /proc/iomem from current head minus the original patch,
> with and without pnpacpi=off.

it's weird,

you should have

00000 - 9f400: System RAM  ===> is not showing up
100000 - d7ff0000: System RAM ===> is not showing up
100000000-11fffffff : System RAM

YH

Re: kernel boot hangs after x86: insert_resorce for lapic addr after e820_reserve_resources

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Fri, May 23, 2008 at 6:51 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Fri, May 23, 2008 at 6:09 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Fri, 23 May 2008 17:05:34 -0700
>> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>>> > Without the ram_reserve
>>> > patch, /proc/iomem is as it was earlier in the discussion.
>>> >
>>> >> can you boot with pnpacpi=off ?
>>> >
>>> > No, that doesn't help either.
>>>
>>> how about /proc/iomem with pnpacpi=off?
>>
>> I've attached /proc/iomem from current head minus the original patch,
>> with and without pnpacpi=off.
>
> it's weird,
>
> you should have
>
> 00000 - 9f400: System RAM  ===> is not showing up
> 100000 - d7ff0000: System RAM ===> is not showing up
> 100000000-11fffffff : System RAM

please try to revert attached commit...

it seems that your compiler is not happy...

YH

[-- Attachment #2: commit-0156126 --]
[-- Type: application/octet-stream, Size: 1186 bytes --]

commit 01561264bd1ea1d654d09babe02d784a5b150124
Author: Yinghai Lu <yhlu.kernel.send@gmail.com>
Date:   Thu Mar 20 23:57:21 2008 -0700

    x86: allocate e820 resource struct all together
    
    don't need to allocate that one by one
    
    Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/x86/kernel/e820_64.c b/arch/x86/kernel/e820_64.c
index 4509757..9184e64 100644
--- a/arch/x86/kernel/e820_64.c
+++ b/arch/x86/kernel/e820_64.c
@@ -300,9 +300,10 @@ unsigned long __init e820_end_of_ram(void)
 void __init e820_reserve_resources(void)
 {
 	int i;
+	struct resource *res;
+
+	res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
 	for (i = 0; i < e820.nr_map; i++) {
-		struct resource *res;
-		res = alloc_bootmem_low(sizeof(struct resource));
 		switch (e820.map[i].type) {
 		case E820_RAM:	res->name = "System RAM"; break;
 		case E820_ACPI:	res->name = "ACPI Tables"; break;
@@ -313,6 +314,7 @@ void __init e820_reserve_resources(void)
 		res->end = res->start + e820.map[i].size - 1;
 		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		insert_resource(&iomem_resource, res);
+		res++;
 	}
 }