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)

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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