September 2011 - xen - Fedora Mailing-Lists

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)

by Konrad Rzeszutek Wilk

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

12 years, 7 months

1
0
0 / 0

Re: [Fedora-xen] Virtualization Test Day for F16 and Xen

by Richard W.M. Jones

On Fri, Sep 16, 2011 at 12:14:23PM +0300, Myroslav Opyr wrote: > Hi, > > What Xen implementation is considered "supported" for FC16 DomU? Any commonly available upstream Xen releases. Fedora itself (ie. https://fedoraproject.org/wiki/Features/XenPvopsDom0). Also Xen in RHEL 5, although that's more of a thing for Red Hat to worry about. > I'm asking because on "Xen implementation" we were testing yesterday > FC16 DomU installation failed compared to FC15 DomU success on the > very same Dom0. Are failures like we've encountered candidates for > bugreports? Yes. > Is there a place (wikipage, bugzilla keyword, etc.) to collect > Fedora 16 Xen issues? https://bugzilla.redhat.com/ Product: Fedora. Component: depends on what is failing but common ones would be "kernel", "anaconda", "grubby", "grub2", "xen", and "libvirt". There is also a Fedora Xen mailing list where you can get more detailed help: https://lists.fedoraproject.org/mailman/listinfo/xen Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

12 years, 7 months

2
1
0 / 0

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)

by Konrad Rzeszutek Wilk

On Wed, Sep 14, 2011 at 09:18:25PM -0400, jim burns wrote: > On Thu September 15 2011, 12:38:26 AM, M A Young wrote: > > I have a (temporary) F17 kernel with the patch from > > http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a64 > > 04ed2106315327fff6be3464d10814e7 (which I assume is the same patch) applied > > building at > > http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367 > > if you want to test it. > > Oh - the patch is to the kernel, not to xen. I misread it. > > Ok - I downloaded > http://koji.fedoraproject.org/koji/getfile?taskID=3352368&name=kernel-3.1... > > I hope that's right. I'll try it tomorrow. Thanx. ping?

12 years, 7 months

1
0
0 / 0

Re: [Fedora-xen] Virtualization Test Day for F16 and Xen

by Pasi Kärkkäinen

On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote: > Hi, Hello, > Virtualization Test day is expected to be on September 15th this year > ([1]https://fedorahosted.org/fedora-qa/ticket/232). > So that's tomorrow! Luckily Xen Hackathon (@Munich) event is just happening, so hopefully we can get some more testing from people in that event. > We are willing to help test > [2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too little > information about test methods > ([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us > to setup test environment, and would be good to have some info in advance. > Regards, > I just added some Xen related mailinglists to the CC list, so we can get more feedback. Thanks, -- Pasi

12 years, 7 months

3
4
0 / 0

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)

by Konrad Rzeszutek Wilk

On Wed, Sep 14, 2011 at 05:07:28PM -0400, jim burns wrote: > On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk wrote: > > On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk wrote: > > > > Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the > > > > BUG:s are still the same as in the last log I sent. However, as > > > > promised I have attached the initcall_debug log, but for rc6. > > > > > > > > > > > > Hey Jim, > > > > > > > > > > > > We are quite sure we know the cause of this. I was wondering if you > > > would be up for beta-testing a patch for this? > > > > Specifically this patch seems to fix it for me: > > > > > > commit 690dc11498b192db25762de77988224753517c96 > > Author: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> > > Date: Wed Sep 14 05:10:00 2011 -0400 > > xen/irq: Alter the locking to be a mutex. > > I'll try to apply this to fedora's xen src rpm over the weekend. In case it > doesn't apply, would you remind me of the git commands for the code you > applied this patch to? Thanx. I just save the email in some mbox file and then do git am < <the saved mbox file> and it should automatically add it. Or you can just do patch -p1 <the saved mbox file> and it will apply it too.

12 years, 7 months

2
2
0 / 0

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)

by Konrad Rzeszutek Wilk

> Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the BUG:s are > still the same as in the last log I sent. However, as promised I have attached > the initcall_debug log, but for rc6. Hey Jim, We are quite sure we know the cause of this. I was wondering if you would be up for beta-testing a patch for this?

12 years, 7 months

1
1
0 / 0

Re: [Fedora-xen] [Xen-users] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port)

by Pasi Kärkkäinen

On Mon, Sep 12, 2011 at 04:07:21PM -0400, jim burns wrote: > On Mon September 12 2011, 10:36:23 AM, Pasi Kärkkäinen wrote: > > > Sure, thanx, attached. Do you need a debug log also (initcall_debug > > > debug loglevel=10)? > > > > > > > Sure, it doesn't hurt.. > > I'll get it to you in a couple of days. > Ok, thanks! also: I assume you won't get any BUGs when booting the same kernel on baremetal/native? > > > The last four BUG:s (from Sep 8 17:12:20 on) were from starting a winxp > > > domu (first 3 BUG:s), and destroying it at grub (the last BUG:). > > > > Ok, so there are BUGs when booting up, and also when starting HVM guests. > > Right, from Sep 8, 17:12 on. The 'comm:'s referenced are xenstored (2x) and > qemu-dm (1x) when starting the guest (as far as grub), and xenconsoled when > 'xm destroy'-ing it. > > Thanx for your interest. > -- Pasi

12 years, 7 months

1
0
0 / 0

Re: [Fedora-xen] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc's (was Summary: Experiences setting up a debug serial port)

by Pasi Kärkkäinen

Hello, Added xen-devel to CC.. On Thu, Sep 08, 2011 at 08:36:04PM -0400, jim burns wrote: > > Rawhide is up to 3.1.0-0.rc5.git0.0.fc17 , and still the same dom0 boot bugs > as in rc4. Can you please post the full Xen + 3.1-rc5 dom0 boot logs again.. -- Pasi

12 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xen September 2011