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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Jan 21, 2011 at 09:43:34PM +0000, M A Young wrote:
> 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!

Whoa.
> 
> >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

We can fix how the E820 is done.
Look in arch/x86/xen/setup.c for 'xen_memory_setup' function.
Try to wrap make map[i].size be = map[i].szie & ~(PAGE_SIZE-1)
that should trim off the last 2048 bytes.

> 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.

That should be generic and hit both cases - but I think this got
fixed in 2.6.36-ish were going for the region right underneath
4GB is not done (don't remember the details, sadly).

> 
> 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).

If you leave the instrumentation you placed in and add 'memblock=debug'
that should give you a good idea of how it does it?
> 
>       Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel