> 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 mailing list
xen@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/xen
