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

[M A Young <m.a.young@xxxxxxxxxxxx>]

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