RE: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure

I noticed one of my e820 entry is not page aligned:

> (XEN)  0000000000000000 - 000000000009bc00 (usable)

It might be similar to the problem reported by Michael Young in attached email.

-----Original Message-----
From: Kay, Allen M 
Sent: Tuesday, January 25, 2011 1:26 PM
To: 'Konrad Rzeszutek Wilk'
Cc: xen-devel
Subject: RE: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure

I do not see any message from mm.c if dom0_mem param is used.  If dom0_mem is 
not used, then I see following error messages in the serial console log.  It is 
part of the log I sent out in my original bug report:

(XEN) mm.c:802:d0 Bad L1 flags 400000
(XEN) mm.c:1204:d0 Failure in alloc_l1_table: entry 365
(XEN) mm.c:2142:d0 Error while validating mfn 1c3eb4 (pfn 1454c) for type 100000

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx] 
Sent: Tuesday, January 25, 2011 12:10 PM
To: Kay, Allen M
Cc: xen-devel
Subject: Re: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure

On Tue, Jan 25, 2011 at 11:24:54AM -0800, Kay, Allen M wrote:
> The machine is an Intel Sandybridge Desktop SDP (Software Development 
> Platform).
> 
> Setting 'dom0_mem=max:1024MB' worked.  Booting with "dom0_mem=max:512MB" 
> panic'ed in mount_block_root().

OK, do you see anything on the Xen console (if you up the debug options?)

I wondering if you see something akin to this:

(XEN) mm.c:889:d0 Error getting mfn 110000 (pfn 5555555555555555) from L1 entry 
8000000110000463 for l1e_owner=0, pg_owner=0
(Xrror while pinning mfn 20c8c0

> 
> Allen
> 
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx] 
> Sent: Tuesday, January 25, 2011 11:08 AM
> To: Kay, Allen M
> Cc: xen-devel
> Subject: Re: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure
> 
> On Tue, Jan 25, 2011 at 10:49:52AM -0800, Kay, Allen M wrote:
> > Looks like it translates to pin_pagetable_pfn.  I have also attached the 
> > entire System.map file.
> > 
> > ...
> > ffffffff8100cce2 t pin_pagetable_pfn
> > ffffffff8100cd1e t p2m_mid_mfn_init
> 
> Ok, then it probably is related to the issues we had with the P2M
> or MFN list being incorrect... and your E820:
> 
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009bc00 (usable)
> (XEN)  000000000009bc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 0000000020000000 (usable)
> (XEN)  0000000020000000 - 0000000020200000 (reserved)
> (XEN)  0000000020200000 - 0000000040000000 (usable)
> (XEN)  0000000040000000 - 0000000040200000 (reserved)
> (XEN)  0000000040200000 - 000000009acd3000 (usable)
> (XEN)  000000009acd3000 - 000000009ad67000 (reserved)
> (XEN)  000000009ad67000 - 000000009afe7000 (ACPI NVS)
> (XEN)  000000009afe7000 - 000000009afff000 (ACPI data)
> (XEN)  000000009afff000 - 000000009b000000 (usable)
> (XEN)  000000009b000000 - 000000009fa00000 (reserved)
> (XEN)  00000000f8000000 - 00000000fc000000 (reserved)
> (XEN)  00000000fec00000 - 00000000fec01000 (reserved)
> (XEN)  00000000fed10000 - 00000000fed14000 (reserved)
> (XEN)  00000000fed18000 - 00000000fed1a000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ff980000 - 00000000ffc00000 (reserved)
> (XEN)  00000000ffd80000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 00000001de600000 (usable)
> 
> is like swiss-cheese with the RAM regions.
> What machine is this and how can I get my hands on it?
> 
> Does it boot if you have 'dom0_mem=max:512MB' (it is important
> to have the 'max' there)?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

--- Begin Message ---

To:	M A Young <m.a.young@xxxxxxxxxxxx>
Subject:	Re: [Xen-devel] Crash on boot with 2.6.37-rc8-git3
From:	Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date:	Mon, 24 Jan 2011 06:14:53 -0800
Cc:	"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
In-reply-to:	<alpine.LFD.2.02.1101212024460.7991@xxxxxxxxxxxxxxx>
List-help:	<mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id:	Xen developer discussion <xen-devel.lists.xensource.com>
List-post:	<mailto:xen-devel@lists.xensource.com>
List-subscribe:	<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe:	<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References:	<alpine.LFD.2.02.1101072034080.9613@xxxxxxxxxxxxxxx> <20110107212359.GA22976@xxxxxxxxxxxx> <alpine.LFD.2.02.1101080007020.8723@xxxxxxxxxxxxxxx> <20110110184225.GB9837@xxxxxxxxxxxx> <alpine.LFD.2.02.1101180027120.16611@xxxxxxxxxxxxxxx> <alpine.LFD.2.02.1101192249200.30335@xxxxxxxxxxxxxxx> <20110120192434.GA10001@xxxxxxxxxxxx> <alpine.LFD.2.02.1101202223370.13928@xxxxxxxxxxxxxxx> <20110121152751.GA4156@xxxxxxxxxxxx> <alpine.LFD.2.02.1101212024460.7991@xxxxxxxxxxxxxxx>
Sender:	"xen-devel-bounces@xxxxxxxxxxxxxxxxxxx" <xen-devel-bounces@xxxxxxxxxxxxxxxxxxx>
Thread-index:	Acu70VfnG/LCG77CQguQCzt1kcwz9g==
Thread-topic:	[Xen-devel] Crash on boot with 2.6.37-rc8-git3
User-agent:	Mutt/1.5.20 (2009-06-14)

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

--- End Message ---

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

WARNING - OLD ARCHIVES

xen-devel

RE: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure