Re: [Xen-devel] Fwd: xenbusb_nop_confighook_cb timeout and cd issue
On 17/01/13 07:36, Christoph Egger wrote: On 14.01.13 07:43, Steven Chamberlain wrote: Hi, kernel: run_interrupt_driven_hooks: still waiting after 60 seconds for xenbusb_nop_confighook_cb boot hangs before mounting root fs It is not really a FreeBSD bug but some regression in Xen 4.1.3. It only affects FreeBSD kernels if built with the XENHVM option. On 06/12/12 11:04, Egoitz Aurrekoetxea Aurre wrote: The patch of the URL is : http://postfixquotareject.ramattack.net/xen-x86-interrupt-pointer-missmatch.diff Thank you! I just tested it on a NetBSD-6 Xen dom0 and it does indeed fix this (I started seeing this problem after an upgrade to pkgsrc-2012Q4; Christoph: would you be interested in this patch?) The patch originally comes from: http://patch-tracker.debian.org/patch/series/view/xen/4.1.3-7/xen-x86-interrupt-pointer-missmatch.diff A lot of Debian-FreeBSD-NetBSD collaboration seems to be happening here :) Regards, Thanks for this patch. I am adding xen-devel for upstream. Christoph config.h defines asmlinkage as nothing. So I am really struggling to find how this code will alter the code in Xen at all once the preprocessor has been completed. ~Andrew ___ Xen-devel mailing list xen-de...@lists.xen.org http://lists.xen.org/xen-devel ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
Hi, A little more background to this: An error was first seen on Debian's i386 autobuilders when building Xen 4.1.2 (Debian package 4.1.2-7), but only after a switch from gcc-4.6 to gcc-4.7 which seems to be what prompted this. I'm not sure if it would have affected amd64 builds as we don't have logs for those: https://buildd.debian.org/status/fetch.php?pkg=xenarch=i386ver=4.1.3-7stamp=1355254810 : gcc -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -Wno-unused-but-set-variable -DNDEBUG -nostdinc -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/build/buildd-xen_4.1.3~rc1+hg-20120614.a9c0a89c08f2-1-i386-iqa4wM/xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/debian/build/build-hypervisor_i386_i386/xen/include -I/build/buildd-xen_4.1.3~rc1+hg-20120614.a9c0a89c08f2-1-i386-iqa4wM/xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/debian/build/build-hypervisor_i386_i386/xen/include/asm-x86/mach-generic -I/build/buildd-xen_4.1.3~rc1+hg-20120614.a9c0a89c08f2-1-i386-iqa4wM/xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/debian/build/build-hypervisor_i386_i386/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -g -D__XEN__ -MMD -MF .i8259.o.d -c i8259.c -o i8259.o i8259.c:66:9: error: initialization from incompatible pointer type [-Werror] i8259.c:66:9: error: (near initialization for 'interrupt[0]') [-Werror] i8259.c:66:9: error: initialization from incompatible pointer type [-Werror] i8259.c:66:9: error: (near initialization for 'interrupt[1]') [-Werror] i8259.c:66:9: error: initialization from incompatible pointer type [-Werror] i8259.c:66:9: error: (near initialization for 'interrupt[2]') [-Werror] In order to fix the build issue, this patch was written, and is still used when building Debian's Xen 4.1.3 packages: http://patch-tracker.debian.org/patch/series/view/xen/4.1.3-7/xen-x86-interrupt-pointer-missmatch.diff Since October 2012 many FreeBSD (9.x) users reported an issue booting on Xenserver 6.1 / XCP 1.6 (incl. -BETA) but not affecting XCP 1.5: http://lists.freebsd.org/pipermail/freebsd-xen/2012-October/001374.html There were prior reports of identical symptoms triggered by guest CD-ROM drives without media, but this seems to be an unrelated bug. Egoitz, who has done a lot of work porting FreeBSD to XCP recently, found that Debian's (Wheezy) Xen kernel didn't have this bug; realised that the above patch fixes it. I experienced the bug when booting the FreeBSD 9.0 kernel on a NetBSD 6.0.1 dom0 after upgrading to pkgsrc-2012Q4 (Xen 4.1.3, from a binary package, unsure which compiler was used to build it). Likewise the patch fixed the issue for me; I used gcc 4.5.3. Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
On 17/01/13 14:53, Mark Felder wrote: Citrix has an open internal bug for this because of my incessant nagging. I'm going to direct them to this patch. I'm afraid the patch can't be what really fixed this. Andrew Cooper is right that the pre-processed output is identical (except for a space), and so are all the object files except for version.o My gcc 4.5 builds on NetBSD; and gcc 4.7 on Debian Wheezy; seem to be the same with/without the patch. Maybe it was something as trivial as the reboot that made it go away? I notice now that gcc 4.7 was updated on Debian buildds, so a compiler bugfix may be what really fixed the issue there. My NetBSD pkgsrc build still differs from the distributed binary package in a strange way, when the chroot build environments should be the same. (This is a diff of 'strings') --- netbsd-binary/xen41-kernel/xen.s 2013-01-17 13:45:08.0 + +++ netbsd-local-unpatched/xen41-kernel/xen.s 2013-01-17 13:45:13.0 + @@ -9641,10 +9636,10 @@ hadow_ pars allo -page_ ched_ ister compa +page_ entr .clone. clone. @@ -12250,7 +12245,6 @@ PoD entries=%d cachesize=%d %s: Out of populate-on-demand memory! tot_pages %u pod_entries %i pg error: %s(): p2m already allocated for this domain -%s: gfn_to_mfn returned type %d! G1%s:%d:d%d Adding bad mfn to p2m map (%#lx - %#lx) G0%s:%d:d%d set_mmio_p2m_entry: set_p2m_entry failed! mfn=%08lx G0%s:%d:d%d clear_mmio_p2m_entry: gfn_to_mfn failed! gfn=%08lx Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
I no longer have that environment that I was using to test the viability of upgrading to XCP 1.6 but it was reproducible every boot. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
On 17/01/13 15:24, Mark Felder wrote: I no longer have that environment that I was using to test the viability of upgrading to XCP 1.6 but it was reproducible every boot. Just to clarify - you rebooted the dom0/hypervisor also? I know the bug is reproducible on every FreeBSD domU boot, at least. Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
For anyone running XCP 1.6 please try to use these RPMs which are patched. I'll be trying this myself later today. http://downloads.xen.org/XCP/freebsd-xen-fix/ Cheers! ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: [Xen-devel] Fwd: xenbusb_nop_confighook_cb timeout and cd issue
On Thu, 17 Jan 2013 09:56:33 -0600, Steven Chamberlain ste...@pyro.eu.org wrote: On 17/01/13 15:24, Mark Felder wrote: I no longer have that environment that I was using to test the viability of upgrading to XCP 1.6 but it was reproducible every boot. Just to clarify - you rebooted the dom0/hypervisor also? I know the bug is reproducible on every FreeBSD domU boot, at least. We did reboot the dom0 more than once but I didn't test that specifically to see if the problem would subside after a few reboots. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
On 14.01.13 07:43, Steven Chamberlain wrote: Hi, kernel: run_interrupt_driven_hooks: still waiting after 60 seconds for xenbusb_nop_confighook_cb boot hangs before mounting root fs It is not really a FreeBSD bug but some regression in Xen 4.1.3. It only affects FreeBSD kernels if built with the XENHVM option. On 06/12/12 11:04, Egoitz Aurrekoetxea Aurre wrote: The patch of the URL is : http://postfixquotareject.ramattack.net/xen-x86-interrupt-pointer-missmatch.diff Thank you! I just tested it on a NetBSD-6 Xen dom0 and it does indeed fix this (I started seeing this problem after an upgrade to pkgsrc-2012Q4; Christoph: would you be interested in this patch?) The patch originally comes from: http://patch-tracker.debian.org/patch/series/view/xen/4.1.3-7/xen-x86-interrupt-pointer-missmatch.diff A lot of Debian-FreeBSD-NetBSD collaboration seems to be happening here :) Regards, Thanks for this patch. I am adding xen-devel for upstream. Christoph ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
Hi, kernel: run_interrupt_driven_hooks: still waiting after 60 seconds for xenbusb_nop_confighook_cb boot hangs before mounting root fs It is not really a FreeBSD bug but some regression in Xen 4.1.3. It only affects FreeBSD kernels if built with the XENHVM option. On 06/12/12 11:04, Egoitz Aurrekoetxea Aurre wrote: The patch of the URL is : http://postfixquotareject.ramattack.net/xen-x86-interrupt-pointer-missmatch.diff Thank you! I just tested it on a NetBSD-6 Xen dom0 and it does indeed fix this (I started seeing this problem after an upgrade to pkgsrc-2012Q4; Christoph: would you be interested in this patch?) The patch originally comes from: http://patch-tracker.debian.org/patch/series/view/xen/4.1.3-7/xen-x86-interrupt-pointer-missmatch.diff A lot of Debian-FreeBSD-NetBSD collaboration seems to be happening here :) Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Fwd: xenbusb_nop_confighook_cb timeout and cd issue
I resend the whole mail because seems the attached patch below didn't arrive
before….
Regards,
Egoitz Aurrekoetxea
Departamento de sistemas
ego...@sarenet.es
Inicio del mensaje reenviado:
De: Egoitz Aurrekoetxea Aurre ego...@sarenet.es
Asunto: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
Fecha: 4 de diciembre de 2012 08:56:17 GMT+01:00
Para: Bob Ball bob.b...@citrix.com, Mark Felder f...@feld.me
This is the mail sent to freebsd-xen mailing list.
Best regards,
Egoitz Aurrekoetxea
Departamento de sistemas
ego...@sarenet.es
Inicio del mensaje reenviado:
De: Egoitz Aurrekoetxea Aurre ego...@sarenet.es
Asunto: xenbusb_nop_confighook_cb timeout and cd issue
Fecha: 3 de diciembre de 2012 19:04:20 GMT+01:00
Para: freebsd-xen@freebsd.org freebsd-xen@freebsd.org
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
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
xenbusb_nop_confighook_cb timeout and cd issue
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 = 512
name = 'freebsd90js.ramattack.net'
vif = [ 'bridge=eth0, mac=00:13:3E:19:88:22, type=ioemu' ]
disk = [
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
