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: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booti

To: jim burns <jim_burn@xxxxxxxxxxxxx>
Subject: Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port)
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Fri, 16 Sep 2011 13:38:14 -0400
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, M A Young <m.a.young@xxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx, Fedora Xen List <fedora-xen@xxxxxxxxxx>
Delivery-date: Fri, 16 Sep 2011 10:39:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <2531823.kDgpVeQNv3@dell4550>
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: <201107231426.56811.jim_burn@xxxxxxxxxxxxx> <alpine.LFD.2.02.1109150027020.22927@xxxxxxxxxxxxxxx> <20110915075358.GA4396@xxxxxxxxxxxxxxxxx> <2531823.kDgpVeQNv3@dell4550>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
> Testing out myoung's 3.1.0 was not as straight forward as I had hoped. It did 
> boot up without any BUG:s, but I did get the occasional Lock Order message. 
> Log snippet at the end of the post. It doesn't seem to be directly related to 
> starting guests.

Yeah, those look like the network card (b44 driver) is at fault.
> 
> The real problem comes in starting up guests. Performance is very bad. I knew 
> from working with rawhide 3.0.0 (long since replaced) that performance would 
> suffer - rawhide kernels are debug kernels:

Right. They are horrendously slow.

> 
> jimb@insp6400 09/16/11 10:16AM:~
> [511] > grep DEBUG /boot/config-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64|grep 
> -v 
> 'is not set'|wc -l
> 91
> jimb@insp6400 09/16/11 10:16AM:~
> [512] > grep DEBUG /boot/config-2.6.40.4-5.fc15.x86_64|grep -v 'is not 
> set'|wc 
> -l           
> 54
> jimb@insp6400 09/16/11 10:18AM:~
> [513] > grep DEBUG /boot/config-3.0.1-3.fc16.x86_64|grep -v 'is not set'|wc 
> -l 
> 90
> 
> Starting guests is much slower under myoung's 3.1.0 than under rawhide's 
> 3.1.0 
> or 3.0.{0,1}. A cifs backed pv domu took 6 min. for 'xm create' to exit, 

a debug kernel which will indeed be quite slow.

> root@insp6400 09/16/11 12:09AM:~
> [544] > xl create Documents/winxp; brctl show;  ps -A|grep qemu; netstat -tlp|
> grep 59; renice -11 `pidof qemu-dm`;  ps -A|grep vncv; ifconfig vif1.0 mtu 
> 9000
> Parsing config file Documents/winxp
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000017b270
>   TOTAL:         0000000000000000->000000003fc00000
>   ENTRY ADDRESS: 00000000001015a0
> xc: error: Could not allocate memory for HVM guest. (16 = Device or resource 
> busy): Internal error
> libxl: error: libxl_dom.c:284:libxl__build_hvm hvm building failed

How much memory do you have used for your dom0/domU?
> 
> and my serial debug log had several:
> 
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (1 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 
> of 
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=1 memflags=0 (439 
> of 2048)
> 
> Then I remembered that I recently upped the memory allocation for my winxp 
> domu, from 512 to 768. This works fine under 2.6.40, the f15 non-debug 
> production kernel. None the less, I knocked the allocation back down to 512, 
> and my winxp domu did start up, getting to the qemu splash screen in about 2 
> - 
> 3 min., during part of which dom0 was unresponsive. However, I'm still 
> getting 
> the '(XEN) memory.c' errors, and some frequent GPF errors (a few a min.) in 
> my 
> serial debug log:
> 
> (XEN) traps.c:2956: GPF (0060): ffff82c48015354a -> ffff82c480200131
> 
> Then, rawhide and gplpv don't get along. Specifically, the xennet receive 
> side 
> driver stops working, and I have to fall back to qemu emulation. It takes 
> about an hour for the winxp desktop to finish initializing, with dom0 cpu 
> load 
> on one cpu core at 72% - yum! But I'll just have to live with it - it's not 
> your problem. I'll leave it up for at least a day to see if any other 
> messages 
> pop up.

Keep in mind that the patch for the <title> is going in 3.1, so it will show
up in FC16 at some point.

You can also rebuild your kernel without the debug options..

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

<Prev in Thread] Current Thread [Next in Thread>