On Fri September 16 2011, 1:38:14 PM, Konrad Rzeszutek Wilk wrote:
> > 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.
Yeah, I see that now, plus references to nf_conntrack and bonding. These
components don't present problems under 2.6.40, so I'll just assume that this
is a timing problem introduced by the debug kernel.
> > 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.
But the point I was emphasizing was that myoung's 3.1.0 is slower than even
rawhide's 3.1.0. The '(XEN) memory.c' errors have stopped, but I'm still
getting a few '(XEN) traps.c:2956: GPF' errors a min. with a winxp domu up,
also something that did not happen under previous rawhide kernels. (I assume
GPF=General Protection Fault, which would really slow things down to trap.)
> > 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?
Dom0 has 2 GB, which is enough to run one domu at a time (which usually has
512 MB). (One of these days I'll spring for a multi GB, IOMMU machine.)
> > 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)
> > [snip]
> > 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.
The patch for who? What's <title>? Plus I have no interest in updating to an
alpha release. I'll wait till the final release. (And I REALLY have no
interest in upgrading to grub2 :-) )
> You can also rebuild your kernel without the debug options..
Yeah - what's the fastest way to do that? 2.6.40 has 54 active DEBUG options,
3.1.0 has 91. Short of deactivating 37 DEBUG options, is there a master DEBUG
option that will do the trick?
Not that it's important. 2.6.40 has what I need for now. I can do without pci
passthrough for awhile. Just curious about the fastest way to turn off the
extra 37 DEBUG options, or at least the most time consuming culprits.
OK, if your confident that these problems will go away in a production kernel,
especially the GPF error, I can wait. If you don't need anything else, I'll
bring down the system, and retreat to 2.6.40 in a couple of hours. Thanx for
you attention.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home