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
Re: xenbusb_nop_confighook_cb timeout
Hi guys,
I've been in contact with Bob Ball at Citrix and he's passed on this
information after confirming the bug we're seeing. I was hoping
someone on the list could help track this down.
I experienced the CDROM issue on XenServer 6.0 and 6.1. I've seen
http://www.mail-archive.com/freebsd-xen@freebsd.org/msg01369.html which
suggests that there was a fix in Xen 4.1.2, which is surprising since
XenServer 6.1 uses Xen 4.1.3 and still exhibits the problem.
http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=effd5676225761abdab90becac519716515c3be4
refers to another regression from 4.1.2 to 4.1.3 relating to the CDROM,
but it appears as though this regression was not merged into XenServer
(i.e. the Xen 4.1.3 used in XenServer did not require this further patch).
http://xen.1045712.n5.nabble.com/Xen-4-1-1-HVM-guest-cdrom-trouble-lost-interrupts-ata-failed-commands-frozen-td4953147.html#a5028910
gives one potential fix, which I believe is the one referenced in the
release notes for 4.1 - however, I've applied this to my Xen and it
does not appear to enable FreeBSD guests to boot with CDs attached.
Could you confirm this from the other perspective and try the
equivalent guest kernel patch?
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 8214724..6b57f90 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -308,8 +308,7 @@ int __init pci_xen_init(void)
int __init pci_xen_hvm_init(void)
{
- if (!xen_feature(XENFEAT_hvm_pirqs))
- return 0;
+ return 0;
#ifdef CONFIG_ACPI
/*
This appears to be a patch for Linux, and I've not located the
equivalent file in FreeBSD (I'm assuming this is down to my
inexperience in FreeBSD!)
I believe that this probably means we have a problem in Xen with
booting FreeBSD guests that hasn't been tracked down, would you agree?
Have either of you seen this working on later versions of OpenSource
Xen? (i.e. not XenServer?)
___
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: xenbusb_nop_confighook_cb timeout
I'm going to take a look at it tomorrow… today impossible as told you before…
but if anyone too has some time to check it too, could be nice… because I'm
pretty busy this days :)
El 14/11/2012, a las 17:51, Mark Felder f...@feld.me escribió:
Hi guys,
I've been in contact with Bob Ball at Citrix and he's passed on this
information after confirming the bug we're seeing. I was hoping
someone on the list could help track this down.
I experienced the CDROM issue on XenServer 6.0 and 6.1. I've seen
http://www.mail-archive.com/freebsd-xen@freebsd.org/msg01369.html which
suggests that there was a fix in Xen 4.1.2, which is surprising since
XenServer 6.1 uses Xen 4.1.3 and still exhibits the problem.
http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=effd5676225761abdab90becac519716515c3be4
refers to another regression from 4.1.2 to 4.1.3 relating to the CDROM,
but it appears as though this regression was not merged into XenServer
(i.e. the Xen 4.1.3 used in XenServer did not require this further patch).
http://xen.1045712.n5.nabble.com/Xen-4-1-1-HVM-guest-cdrom-trouble-lost-interrupts-ata-failed-commands-frozen-td4953147.html#a5028910
gives one potential fix, which I believe is the one referenced in the
release notes for 4.1 - however, I've applied this to my Xen and it
does not appear to enable FreeBSD guests to boot with CDs attached.
Could you confirm this from the other perspective and try the
equivalent guest kernel patch?
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 8214724..6b57f90 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -308,8 +308,7 @@ int __init pci_xen_init(void)
int __init pci_xen_hvm_init(void)
{
- if (!xen_feature(XENFEAT_hvm_pirqs))
- return 0;
+ return 0;
#ifdef CONFIG_ACPI
/*
This appears to be a patch for Linux, and I've not located the
equivalent file in FreeBSD (I'm assuming this is down to my
inexperience in FreeBSD!)
I believe that this probably means we have a problem in Xen with
booting FreeBSD guests that hasn't been tracked down, would you agree?
Have either of you seen this working on later versions of OpenSource
Xen? (i.e. not XenServer?)
___
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
___
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: xenbusb_nop_confighook_cb timeout
I assume this should be a Citrix bug…. Seems like the bug : Xen 4.1.1 has a bug where the emulated CDROM/DVD drive in an HVM guest fails to work properly. This bug has been fixed in Xen 4.1.2 and later versions. The symptoms of this bug are lost interrupts and frozen ata commands in the kernel dmesg log. See this email thread for more information: http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg02147.html documented in : http://wiki.xen.org/wiki/Xen_4.1_Release_Notes does not get corrected… El 14/10/2012, a las 15:52, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Hi, I get finally a decent workaround. Xen 4.1.3 serves the cdrom in a way that seems not to like to FreeBSD. The workaround is basically remove the cd drive between offered devices to the vm…. Just to follow this on xcp/xenserver…. http://support.citrix.com/article/CTX132411 And it boots…. without modifying any source…. First time I debugged probably did something wrong and didn't see the printfs set by me to print any variable %s content… later yes…. was intr config….. and the boot proccess was stopped here… it stops always in the cd initialization part…. it's not able to make the cd to come online…. Just removing it… you can boot properly…. This is not the solution…. it's just a workaround…. I'll try to find a solution…. but seems here the Xen people… has changed something…. Continue investigating…… Regards, El 12/10/2012, a las 02:27, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Hi Mark, I assume are better (and fur more safer) ways... Seems some Xen pv specific device has some issue being attached... I'm debuging it to see which device is the one is causing the problem Then I could (depending on the device) avoid attaching it or try to see how to handle it properly... Regards, Egoirz Aurrekoetxea Aurre ego...@ramattack.net El 11/10/2012, a las 21:53, Mark Felder f...@feld.me escribió: On Wed, 10 Oct 2012 16:18:57 -0500, Gót András got.and...@deployis.eu wrote: The patched worked for me also. I hope somehow it'll make to into 9.1rc if send a reply to the previous PR. Can we get a confirmation from any devs about whether or not this patch is the right way to fix it? If so, I'd also appreciate seeing this slip into 9.1 so the latest stable FreeBSD release works reliably with the latest stable XenServer/XCP release... ___ 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 ___ 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 ___ 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 ___ 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: xenbusb_nop_confighook_cb timeout
On Wed, 10 Oct 2012 16:18:57 -0500, Gót András got.and...@deployis.eu wrote: The patched worked for me also. I hope somehow it'll make to into 9.1rc if send a reply to the previous PR. Can we get a confirmation from any devs about whether or not this patch is the right way to fix it? If so, I'd also appreciate seeing this slip into 9.1 so the latest stable FreeBSD release works reliably with the latest stable XenServer/XCP release... ___ 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: xenbusb_nop_confighook_cb timeout
Hi Mark, I assume are better (and fur more safer) ways... Seems some Xen pv specific device has some issue being attached... I'm debuging it to see which device is the one is causing the problem Then I could (depending on the device) avoid attaching it or try to see how to handle it properly... Regards, Egoirz Aurrekoetxea Aurre ego...@ramattack.net El 11/10/2012, a las 21:53, Mark Felder f...@feld.me escribió: On Wed, 10 Oct 2012 16:18:57 -0500, Gót András got.and...@deployis.eu wrote: The patched worked for me also. I hope somehow it'll make to into 9.1rc if send a reply to the previous PR. Can we get a confirmation from any devs about whether or not this patch is the right way to fix it? If so, I'd also appreciate seeing this slip into 9.1 so the latest stable FreeBSD release works reliably with the latest stable XenServer/XCP release... ___ 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 ___ 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: xenbusb_nop_confighook_cb timeout
Hi!, I have reproduced it in my environment too…. XCP 1.6-BETA and FreeBSD 9.0-RELENG_9_0 (from June compiled by myself release) and 9.1-RC2….. This is the state it arrives : http://snag.gy/izByC.jpg I'm trying to see too what's happening… Regards, El 10/10/2012, a las 15:40, Gót András got.and...@deployis.eu escribió: Dear All, I've encountered the xenbusb_nop_confighook_cb timeout with FreeBSD 9.1RC2 on XenServer 6.1. This time mounting a CD-ROM didn't help. In an earlier thread on this someone requested a xenstore-ls output, so here it is: http://pastebin.com/XCgAfHKY This is the only running VM on the machine besides the DVS Xen vm. Of course it's a GENERIC kernel, but some unwanted things thrown out like wifi-usb, wifi etc. Regards, Andras ___ 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 ___ 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: xenbusb_nop_confighook_cb timeout
I have seen this is old… and I assume it was happening too on this Xen version… kern/164630 Any workaround??? unless?? El 10/10/2012, a las 19:19, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Hi!, I have reproduced it in my environment too…. XCP 1.6-BETA and FreeBSD 9.0-RELENG_9_0 (from June compiled by myself release) and 9.1-RC2….. This is the state it arrives : http://snag.gy/izByC.jpg I'm trying to see too what's happening… Regards, El 10/10/2012, a las 15:40, Gót András got.and...@deployis.eu escribió: Dear All, I've encountered the xenbusb_nop_confighook_cb timeout with FreeBSD 9.1RC2 on XenServer 6.1. This time mounting a CD-ROM didn't help. In an earlier thread on this someone requested a xenstore-ls output, so here it is: http://pastebin.com/XCgAfHKY This is the only running VM on the machine besides the DVS Xen vm. Of course it's a GENERIC kernel, but some unwanted things thrown out like wifi-usb, wifi etc. Regards, Andras ___ 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 ___ 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 ___ 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: xenbusb_nop_confighook_cb timeout
Hi, If needed I can provide test VM-s on a XenServer 6.1 cluster with full access to the VM-s. Unfortunately the Web Self Service cannot be installed, because there's a bad link in the trial email, so we cannot even do the test we want and hopefully proceed to buy the enterprise licence. Regards, Andras On 10/10/2012 08:56 PM, Mark Felder wrote: This is also preventing my XCP 1.5beta to 1.6 testing :-( Any suggestions are appreciated! ___ 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: xenbusb_nop_confighook_cb timeout
This is also preventing my XCP 1.5beta to 1.6 testing :-( Any suggestions are appreciated! ___ 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: xenbusb_nop_confighook_cb timeout
Hi, I've made some tests and even if I disable USB support in the kernel the hang occurs. The XENHVM drivers finds the virtual USB anyway. Regards, Andras On 10/10/2012 07:19 PM, Egoitz Aurrekoetxea Aurre wrote: Hi!, I have reproduced it in my environment too…. XCP 1.6-BETA and FreeBSD 9.0-RELENG_9_0 (from June compiled by myself release) and 9.1-RC2….. This is the state it arrives : http://snag.gy/izByC.jpg I'm trying to see too what's happening… Regards, El 10/10/2012, a las 15:40, Gót András got.and...@deployis.eu escribió: Dear All, I've encountered the xenbusb_nop_confighook_cb timeout with FreeBSD 9.1RC2 on XenServer 6.1. This time mounting a CD-ROM didn't help. In an earlier thread on this someone requested a xenstore-ls output, so here it is: http://pastebin.com/XCgAfHKY This is the only running VM on the machine besides the DVS Xen vm. Of course it's a GENERIC kernel, but some unwanted things thrown out like wifi-usb, wifi etc. Regards, Andras ___ 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 ___ 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 ___ 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: xenbusb_nop_confighook_cb timeout
...
one thing mates… I need to check this in a more slower and conscientiously way
but...
I think… in subr_autoconf.c file in function
boot_run_interrupt_driven_config_hooks it's entering in a while causing to be
looped there forever… because it doesn't see the NULL it's awaiting the while
and apart of this, seems nothing changes in the given structures when calling
msleep…. because perhaps… nothing should change and it's always basically not
seen NULL too….. So loops six times and gets there…. panicked… Look…
root@pruebas:/root # diff -u /usr/src/sys/kern/subr_autoconf.c-defecto
/usr/src/sys/kern/subr_autoconf.c
--- /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) {
+ printf(\n\n SARENET Individual lock name antes de
unlock es : %s, intr_config_hook_lock.lock_object.lo_name);
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);
}
TAILQ_EMPTY is at queue.h :
#define STAILQ_EMPTY(head) ((head)-stqh_first == NULL)
With the printf line entered by me… have not seen any text in
intr_config_hook_lock.lock_object.lo_name struct element… So…. I commented the
while as seen in the patch….
and the system is booting :)
root@pruebas:/root #
root@pruebas:/root #
root@pruebas:/root #
root@pruebas:/root # uptime
7:08PM up 23 secs, 1 user, load averages: 0.96, 0.25, 0.09
root@pruebas:/root # uname -ar
FreeBSD pruebas.sare.net 9.1-RC2 FreeBSD 9.1-RC2 #0: Wed Oct 10 18:33:54 CEST
2012 r...@pruebas.sare.net:/usr/obj/usr/src/sys/XENHVM11 amd64
root@pruebas:/root #
So…. I'm guessing perhaps enters in the loop because the value is not exactly
NULL and stays there till it attempts six times… and get there indefinitely
like panicked….
Have tried it too with FreeBSD 9.0 RELENG_9_0….
As said at the beginning need to investigate further… but seems like we're
going in the proper direction….
Cheers,
El 10/10/2012, a las 20:56, Mark Felder f...@feld.me escribió:
This is also preventing my XCP 1.5beta to 1.6 testing :-(
Any suggestions are appreciated!
___
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: xenbusb_nop_confighook_cb timeout
Hi,
The patched worked for me also. I hope somehow it'll make to into 9.1rc
if send a reply to the previous PR. :)
Andras
On 10/10/2012 10:16 PM, Egoitz Aurrekoetxea Aurre wrote:
...
one thing mates… I need to check this in a more slower and conscientiously way
but...
I think… in subr_autoconf.c file in function
boot_run_interrupt_driven_config_hooks it's entering in a while causing to be
looped there forever… because it doesn't see the NULL it's awaiting the while
and apart of this, seems nothing changes in the given structures when calling
msleep…. because perhaps… nothing should change and it's always basically not
seen NULL too….. So loops six times and gets there…. panicked… Look…
root@pruebas:/root # diff -u /usr/src/sys/kern/subr_autoconf.c-defecto
/usr/src/sys/kern/subr_autoconf.c
--- /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) {
+ printf(\n\n SARENET Individual lock name antes de unlock es
: %s, intr_config_hook_lock.lock_object.lo_name);
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);
}
TAILQ_EMPTY is at queue.h :
#define STAILQ_EMPTY(head) ((head)-stqh_first == NULL)
With the printf line entered by me… have not seen any text in
intr_config_hook_lock.lock_object.lo_name struct element… So…. I commented the
while as seen in the patch….
and the system is booting :)
root@pruebas:/root #
root@pruebas:/root #
root@pruebas:/root #
root@pruebas:/root # uptime
7:08PM up 23 secs, 1 user, load averages: 0.96, 0.25, 0.09
root@pruebas:/root # uname -ar
FreeBSD pruebas.sare.net 9.1-RC2 FreeBSD 9.1-RC2 #0: Wed Oct 10 18:33:54 CEST
2012 r...@pruebas.sare.net:/usr/obj/usr/src/sys/XENHVM11 amd64
root@pruebas:/root #
So…. I'm guessing perhaps enters in the loop because the value is not exactly
NULL and stays there till it attempts six times… and get there indefinitely
like panicked….
Have tried it too with FreeBSD 9.0 RELENG_9_0….
As said at the beginning need to investigate further… but seems like we're
going in the proper direction….
Cheers,
El 10/10/2012, a las 20:56, Mark Felder f...@feld.me escribió:
This is also preventing my XCP 1.5beta to 1.6 testing :-(
Any suggestions are appreciated!
___
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: xenbusb_nop_confighook_cb timeout
Hi Justin, I am using FreeBSD as the OS on a VPS (Xen HVM). Do you think the VPS provider will provide that information without too much drama? On 29/01/11 10:26, Justin T. Gibbs wrote: On 1/27/2011 2:29 PM, Alex wrote: I've had that geom warning before on real hardware and it's never stopped it from working. In my screenshot, it appears the time out is originating from: xenbusb.c:xenbusb_nop_confighook_cb This means that one of the PV devices is not transitioning into either the Connected or Closed state. Can you provide the output of xenstore-ls from your DOM0 to me privately so I can help you track this down? Thanks, Justin ___ 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: xenbusb_nop_confighook_cb timeout
This problem seems to have disappeared, the only thing i have done in
the config at my VPS provider was mount a cdrom image..
On 28/01/11 08:29, Alex wrote:
I've had that geom warning before on real hardware and it's never
stopped it from working.
In my screenshot, it appears the time out is originating from:
xenbusb.c:xenbusb_nop_confighook_cb
xenbusb_nop_confighook_cb(void *arg __unused)
{
}
called in xenbusb_attach(device_t dev, char *bus_node, u_int
id_components)
/*
* Since XenBus busses are attached to the XenStore, and
* the XenStore does not probe children until after interrupt
* services are available, this config hook is used solely
* to ensure that the remainder of the boot process (e.g.
* mount root) is deferred until child devices are adequately
* probed. We unblock the boot process as soon as the
* connecting child count in our softc goes to 0.
*/
xbs-xbs_attach_ch.ich_func = xenbusb_nop_confighook_cb;
Regarding the partitioning, I am not sure what you mean. I have this
configured as a VPS so I want to avoid doing anything that may destroy
data on the disk.
On 28/01/11 06:29, Nick Sayer wrote:
On Jan 27, 2011, at 1:43 AM, Alex wrote:
I've applied this patch, I now get past the ethernet issue, and have
run into another problem, see screenshot:
http://ahhyes.net/xen1.jpg
any ideas?
The disk geometry differs from the PV device and the emulated
hardware, I suspect.
I was using GPT when I migrated, so I suspect that the issue was
moot. What is your partitioning schema for this disk? Can you switch
over to GPT... uh...
somehow?___
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
___
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
___
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: xenbusb_nop_confighook_cb timeout
I've had that geom warning before on real hardware and it's never
stopped it from working.
In my screenshot, it appears the time out is originating from:
xenbusb.c:xenbusb_nop_confighook_cb
xenbusb_nop_confighook_cb(void *arg __unused)
{
}
called in xenbusb_attach(device_t dev, char *bus_node, u_int id_components)
/*
* Since XenBus busses are attached to the XenStore, and
* the XenStore does not probe children until after interrupt
* services are available, this config hook is used solely
* to ensure that the remainder of the boot process (e.g.
* mount root) is deferred until child devices are adequately
* probed. We unblock the boot process as soon as the
* connecting child count in our softc goes to 0.
*/
xbs-xbs_attach_ch.ich_func = xenbusb_nop_confighook_cb;
Regarding the partitioning, I am not sure what you mean. I have this
configured as a VPS so I want to avoid doing anything that may destroy
data on the disk.
On 28/01/11 06:29, Nick Sayer wrote:
On Jan 27, 2011, at 1:43 AM, Alex wrote:
I've applied this patch, I now get past the ethernet issue, and have run into
another problem, see screenshot:
http://ahhyes.net/xen1.jpg
any ideas?
The disk geometry differs from the PV device and the emulated hardware, I
suspect.
I was using GPT when I migrated, so I suspect that the issue was moot. What is
your partitioning schema for this disk? Can you switch over to GPT... uh...
somehow?___
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
___
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: xenbusb_nop_confighook_cb timeout
On Jan 27, 2011, at 1:29 PM, Alex wrote: I've had that geom warning before on real hardware and it's never stopped it from working. Ah, well, then never mind. I thought maybe it was germane to the hang. I don't know which differences we might have between us that would account for it working for me, but not for you. My machine is GPT+ZFS and it had no trouble transitioning to XENHVT once the do something smart panic went away. ___ 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: xenbusb_nop_confighook_cb timeout
Hi Nick, Would you mind showing me a copy of your dmesg for the XENHVM kernel? I just want to make a comparison with mine. Perhaps this subject may get someone else's attention, otherwise I'll file a PR. :) On 28/01/2011 9:40 AM, Nick Sayer wrote: On Jan 27, 2011, at 1:29 PM, Alex wrote: I've had that geom warning before on real hardware and it's never stopped it from working. Ah, well, then never mind. I thought maybe it was germane to the hang. I don't know which differences we might have between us that would account for it working for me, but not for you. My machine is GPT+ZFS and it had no trouble transitioning to XENHVT once the do something smart panic went away. ___ 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 ___ 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
