[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.