WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: RE: [Xen-devel] 2.6.32.27 dom0 + latest xen staging boot failure
From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Date: Tue, 25 Jan 2011 18:41:30 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 25 Jan 2011 18:42:28 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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: <987664A83D2D224EAE907B061CE93D5301943055D7@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110125143950.GA7238@xxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D530194305B18@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110125190751.GA5723@xxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D530194305BEA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110125201008.GA18756@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acu8y/Gh7fA8r5chTnOWcScElppvHQACi2IAAAsKUoA=
Thread-topic: [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
<Prev in Thread] Current Thread [Next in Thread>