Re: xenbusb_nop_confighook_cb timeout and cd issue
Good morning, For sure Sean, I have today a more or less busy day but as far as I get again some (even little :) ) more time… I'll tell here how the progress goes…. Best regards, Egoitz Aurrekoetxea Departamento de sistemas ego...@sarenet.es El 04/12/2012, a las 05:33, Sean Bruno sean...@yahoo-inc.com escribió: On Mon, 2012-12-03 at 19:04 +0100, Egoitz Aurrekoetxea Aurre wrote: Good morning, After doing some checks and debugs about this problem, I can conclude that : under Xen 4.1.3 on Debian Wheezy it works properly although in XCP1.6 if you remove the cd drive from the vm works too. I'm going to describe the two test environments have used for debugging this : ENV 1.- XCP 1.6 XEN 4.1.3 + FREEBSD 9.1-RC3 : As you can see with an iso image mounted and without it, the boot process gets stuck there….. (I paste here both screenshot location). http://postfixquotareject.ramattack.net/PastedGraphic-8.tiff http://postfixquotareject.ramattack.net/PastedGraphic-11.tiff I have placed here two examples, with an empty (but existing) cd drive and with a iso mounted in the drive. BUT If I do a in the XCP shell : xe vm-cd-remove uuid=08aec342-9572-8690-5e58-91d1b1f0aab2 cd-name=xs-tools.iso The drive is being removed from the vm and it boots normally. This is the workaround I'm using for the moment. Another debugging check I have done too is to apply this patch (although it's just for testing purposes and for checking if cd drive works) to see how the drive behaves after booting but without stopping in that loop of the FreeBSD kernel source code. --- /usr/src/sys/kern/subr_autoconf.c-defecto2012-10-10 13:51:27.0 +0200 +++ /usr/src/sys/kern/subr_autoconf.c2012-10-10 18:21:51.0 +0200 @@ -133,16 +133,17 @@ /* Block boot processing until all hooks are disestablished. */ mtx_lock(intr_config_hook_lock); warned = 0; -while (!TAILQ_EMPTY(intr_config_hook_list)) { +/* while (!TAILQ_EMPTY(intr_config_hook_list)) { */ if (msleep(intr_config_hook_list, intr_config_hook_lock, 0, conifhk, WARNING_INTERVAL_SECS * hz) == EWOULDBLOCK) { mtx_unlock(intr_config_hook_lock); warned++; run_interrupt_driven_config_hooks_warning(warned); mtx_lock(intr_config_hook_lock); } -} +/* } */ mtx_unlock(intr_config_hook_lock); } After applying this patch, kernel boots under XCP 1.6Beta and cd can be mounted in the shell (should say I have not noticed about IRQ problems after this). It seems like FreeBSD domU is not able to continue the boot process because it's not able to finish up some test related to THIS (the cd drive) device setup (IRQ assigning tests I assume concretely) that should succeed before being able to continue the boot process. ENV 2.- Debian Wheezy (testing) XEN 4.1.3 + FreeBSD 9.1-RC3 : Here is the concrete environment and config : root@pruebas-xen-egoitz:~# uname -ar Linux pruebas-xen-egoitz 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux root@pruebas-xen-egoitz:~# cat /etc/issue Debian GNU/Linux wheezy/sid \n \l root@pruebas-xen-egoitz:~# dpkg -l | grep -i xen ii libxen-4.1 4.1.3-4 amd64 Public libs for Xen ii libxenstore3.0 4.1.3-4 amd64 Xenstore communications library for Xen ri linux-image-2.6.32-5-xen-amd64 2.6.32-46 amd64 Linux 2.6.32 for 64-bit PCs, Xen dom0 support rc xen-hypervisor-4.0-amd64 4.0.1-5.4 amd64 The Xen Hypervisor on AMD64 ii xen-hypervisor-4.1-amd64 4.1.3-4 amd64 Xen Hypervisor on AMD64 ii xen-linux-system-3.2.0-4-amd64 3.2.32-1 amd64 Xen system with Linux 3.2 on 64-bit PCs (meta-package) ii xen-linux-system-amd64 3.2+46amd64 Xen system with Linux for 64-bit PCs (meta-package) ii xen-system-amd64 4.1.3-4 amd64 Xen System on AMD64 (meta-package) ii xen-tools 4.3.1-1 all Tools to manage Xen virtual servers ii xen-utils-4.1 4.1.3-4 amd64 XEN administrative tools ii xen-utils-common 4.1.3-4 all Xen administrative tools - common files ii xenstore-utils 4.1.3-4 amd64 Xenstore utilities for Xen root@pruebas-xen-egoitz:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 6908 8 r- 1526.2
Re: xenbusb_nop_confighook_cb timeout and cd issue
On Mon, 2012-12-03 at 19:04 +0100, Egoitz Aurrekoetxea Aurre wrote: Good morning, After doing some checks and debugs about this problem, I can conclude that : under Xen 4.1.3 on Debian Wheezy it works properly although in XCP1.6 if you remove the cd drive from the vm works too. I'm going to describe the two test environments have used for debugging this : ENV 1.- XCP 1.6 XEN 4.1.3 + FREEBSD 9.1-RC3 : As you can see with an iso image mounted and without it, the boot process gets stuck there….. (I paste here both screenshot location). http://postfixquotareject.ramattack.net/PastedGraphic-8.tiff http://postfixquotareject.ramattack.net/PastedGraphic-11.tiff I have placed here two examples, with an empty (but existing) cd drive and with a iso mounted in the drive. BUT If I do a in the XCP shell : xe vm-cd-remove uuid=08aec342-9572-8690-5e58-91d1b1f0aab2 cd-name=xs-tools.iso The drive is being removed from the vm and it boots normally. This is the workaround I'm using for the moment. Another debugging check I have done too is to apply this patch (although it's just for testing purposes and for checking if cd drive works) to see how the drive behaves after booting but without stopping in that loop of the FreeBSD kernel source code. --- /usr/src/sys/kern/subr_autoconf.c-defecto 2012-10-10 13:51:27.0 +0200 +++ /usr/src/sys/kern/subr_autoconf.c 2012-10-10 18:21:51.0 +0200 @@ -133,16 +133,17 @@ /* Block boot processing until all hooks are disestablished. */ mtx_lock(intr_config_hook_lock); warned = 0; - while (!TAILQ_EMPTY(intr_config_hook_list)) { + /* while (!TAILQ_EMPTY(intr_config_hook_list)) { */ if (msleep(intr_config_hook_list, intr_config_hook_lock, 0, conifhk, WARNING_INTERVAL_SECS * hz) == EWOULDBLOCK) { mtx_unlock(intr_config_hook_lock); warned++; run_interrupt_driven_config_hooks_warning(warned); mtx_lock(intr_config_hook_lock); } - } + /* } */ mtx_unlock(intr_config_hook_lock); } After applying this patch, kernel boots under XCP 1.6Beta and cd can be mounted in the shell (should say I have not noticed about IRQ problems after this). It seems like FreeBSD domU is not able to continue the boot process because it's not able to finish up some test related to THIS (the cd drive) device setup (IRQ assigning tests I assume concretely) that should succeed before being able to continue the boot process. ENV 2.- Debian Wheezy (testing) XEN 4.1.3 + FreeBSD 9.1-RC3 : Here is the concrete environment and config : root@pruebas-xen-egoitz:~# uname -ar Linux pruebas-xen-egoitz 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux root@pruebas-xen-egoitz:~# cat /etc/issue Debian GNU/Linux wheezy/sid \n \l root@pruebas-xen-egoitz:~# dpkg -l | grep -i xen ii libxen-4.1 4.1.3-4 amd64 Public libs for Xen ii libxenstore3.0 4.1.3-4 amd64 Xenstore communications library for Xen ri linux-image-2.6.32-5-xen-amd64 2.6.32-46 amd64 Linux 2.6.32 for 64-bit PCs, Xen dom0 support rc xen-hypervisor-4.0-amd64 4.0.1-5.4 amd64 The Xen Hypervisor on AMD64 ii xen-hypervisor-4.1-amd64 4.1.3-4 amd64 Xen Hypervisor on AMD64 ii xen-linux-system-3.2.0-4-amd64 3.2.32-1 amd64 Xen system with Linux 3.2 on 64-bit PCs (meta-package) ii xen-linux-system-amd64 3.2+46amd64 Xen system with Linux for 64-bit PCs (meta-package) ii xen-system-amd64 4.1.3-4 amd64 Xen System on AMD64 (meta-package) ii xen-tools 4.3.1-1 all Tools to manage Xen virtual servers ii xen-utils-4.1 4.1.3-4 amd64 XEN administrative tools ii xen-utils-common 4.1.3-4 all Xen administrative tools - common files ii xenstore-utils 4.1.3-4 amd64 Xenstore utilities for Xen root@pruebas-xen-egoitz:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 6908 8 r- 1526.2 freebsd90js.ramattack.net 24 512 2 -b 59.9 I normally create the life cycle with a xm new, later xm start……. the config file is : root@pruebas-xen-egoitz:~# cat /etc/xen/freebsd90rjs.ramattack.net.cfg kernel = '/usr/lib/xen-4.1/boot/hvmloader' builder = 'hvm' vcpus = 2 memory