This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Crash on boot with 2.6.37-rc8-git3

On Fri, 21 Jan 2011, Konrad Rzeszutek Wilk wrote:

We should find out why that PTE is not being setup.... And I think
this might be a missing entry in the MFN (thanks to Stefan Bader
finding a bug there).  Looking at your E820:

[    0.000000]  Xen: 0000000000100000 - 000000003b0e2000 (usable)

Mine is
[    0.000000]  Xen: 0000000000100000 - 00000000df66d800 (usable)

Your memory ends a 3b0e, which is not on a nice page boundary.

Mine isn't on a page boundary at all!

Can you try this patch (you will need to re-gigger as in 2.6.38-rc1
the p2m code moved out of xen/mmu.c to xen/p2m.c):

It doesn't help, and crashes at the same place as the unaltered kernel. My problem may not be happening in the xen code at all. From the boot logs of one of my hack attempts that actually booted I have

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009f000 (usable)
[    0.000000]  Xen: 000000000009f000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 00000000df66d800 (usable)
[    0.000000]  Xen: 00000000df66d800 - 00000000e0000000 (reserved)
[    0.000000]  Xen: 00000000f8000000 - 00000000fc000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec10000 (reserved)
[    0.000000]  Xen: 00000000fed18000 - 00000000fed1c000 (reserved)
[    0.000000]  Xen: 00000000fed20000 - 00000000fed90000 (reserved)
[    0.000000]  Xen: 00000000feda0000 - 00000000feda6000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffe00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000001342cb000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x1342cb max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0xdf66d max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: 0000000000000000-00000000df66d000
[    0.000000] init_memory_mapping: 0000000100000000-00000001342cb000

The last_pfn figure above is actually one more than the last pfn that is initialized and is obtained by right-shifting the start memory address plus the length of the memory piece. That is fine if the memory ends on a page boundary, but not if it doesn't because the partial page doesn't get a pfn. Thus it is available for early allocations such as the NODE DATA chunk. Xen goes for the memory chunk just below the 4GB mark and hits this region, bare metal (2.6.35) starts the NODE DATA at the 4GB mark and doesn't.

I am not sure if bare metal is clever enough not to try to use this partial page, or whether it could but misses it because of how it places the NODE_DATA (at the bottom end of a memory region rather than the top end).

        Michael Young

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>