From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk 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) Date: Fri, 16 Sep 2011 13:38:14 -0400 Message-ID: <20110916173814.GB29389@phenom.oracle.com> References: <201107231426.56811.jim_burn@bellsouth.net> <20110915075358.GA4396@phenom.oracle.com> <2531823.kDgpVeQNv3@dell4550> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <2531823.kDgpVeQNv3@dell4550> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xen-bounces@lists.fedoraproject.org Errors-To: xen-bounces@lists.fedoraproject.org To: jim burns Cc: Ian Campbell , xen-devel@lists.xensource.com, xen-users@lists.xensource.com, Fedora Xen List List-Id: xen-devel@lists.xenproject.org > 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 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..