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
Call for testers: vfork(2) repair for Xen
Hi,
there is plain erronous special case for Xen in the handling of vfork(2)
syscall, which converts it into the fork(2), but only on Xen. I think this
was a bug to commit the change in the course of importing Xen support at all.
Could somebody of you, who use paravirtualized kernels, test the patch
below. After the patched kernel is booted, just running csh(1) and
calling any external command from it, e.g. ls(1), is enough.
I already tried to solicit the testing of the fix in private, but nobody
responded. I am going to commit the change in a week, unless somebody
report a real issue with Xen pmap, uncovered by it.
diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index b8a4825..0d2709f 100644
--- a/sys/kern/kern_fork.c
+++ b/sys/kern/kern_fork.c
@@ -150,11 +150,7 @@ sys_vfork(struct thread *td, struct vfork_args *uap)
int error, flags;
struct proc *p2;
-#ifdef XEN
- flags = RFFDG | RFPROC; /* validate that this is still an issue */
-#else
flags = RFFDG | RFPROC | RFPPWAIT | RFMEM;
-#endif
error = fork1(td, flags, 0, p2, NULL, 0);
if (error == 0) {
td-td_retval[0] = p2-p_pid;
pgpQ0tRlValmW.pgp
Description: PGP signature
Re: Call for testers: vfork(2) repair for Xen
On Tue, 2012-12-04 at 23:02 +0200, Konstantin Belousov wrote:
Hi,
there is plain erronous special case for Xen in the handling of vfork(2)
syscall, which converts it into the fork(2), but only on Xen. I think this
was a bug to commit the change in the course of importing Xen support at all.
Could somebody of you, who use paravirtualized kernels, test the patch
below. After the patched kernel is booted, just running csh(1) and
calling any external command from it, e.g. ls(1), is enough.
I already tried to solicit the testing of the fix in private, but nobody
responded. I am going to commit the change in a week, unless somebody
report a real issue with Xen pmap, uncovered by it.
diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index b8a4825..0d2709f 100644
--- a/sys/kern/kern_fork.c
+++ b/sys/kern/kern_fork.c
@@ -150,11 +150,7 @@ sys_vfork(struct thread *td, struct vfork_args *uap)
int error, flags;
struct proc *p2;
-#ifdef XEN
- flags = RFFDG | RFPROC; /* validate that this is still an issue */
-#else
flags = RFFDG | RFPROC | RFPPWAIT | RFMEM;
-#endif
error = fork1(td, flags, 0, p2, NULL, 0);
if (error == 0) {
td-td_retval[0] = p2-p_pid;
Ack. Will test tonight after dom0.freebsd.org is restored.
Sean
___
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
