Fwd: xenbusb_nop_confighook_cb timeout and cd issue

2012-12-06 Thread Egoitz Aurrekoetxea Aurre 
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

2012-12-04 Thread Egoitz Aurrekoetxea Aurre 
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

2012-12-03 Thread Egoitz Aurrekoetxea Aurre 
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

2012-11-14 Thread Egoitz Aurrekoetxea Aurre 
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

2012-10-14 Thread Egoitz Aurrekoetxea Aurre 
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

2012-10-11 Thread Egoitz Aurrekoetxea Aurre 
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

2012-10-10 Thread Egoitz Aurrekoetxea Aurre 
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

2012-10-10 Thread Egoitz Aurrekoetxea Aurre 
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

2012-10-10 Thread Egoitz Aurrekoetxea Aurre 
...

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: Citrix Xenserver and FreeBSD migration/suspend scripts

2012-08-17 Thread Egoitz Aurrekoetxea Aurre 




El 17/08/2012, a las 16:07, Mark Felder f...@feld.me escribió:

 On Thu, 16 Aug 2012 17:01:41 -0500, Egoitz Aurrekoetxea 
 ego...@ramattack.net wrote:
 
 Sorry in this last mails I was talking about making a port with my own
 scripts and adaptation
 http://wiki.xen.org/wiki/FreeBSD_9.0_64-bit_HVM_on_XCP_1.1
 I assume I didn't know about you're project at this date... when I
 answered this mail...
 
 My work is an improvement on yours. Please take a look at it and feel free 
 contribute additional changes :-) I'm very glad you were able to get this 
 working and post it for everyone to use.


I'll take a look Mark :) sure... Was just clarifying that what I have been 
spoken about is about the code adapted by me... You know, I'm on holiday and 
most of times answering from the smartphone... Sometimes you don't read in the 
street and in so a little screen the contents as you should :)

Just that..,

But sure although I have my code in production and working :) everything is 
improvable :) :)

Bye!!

P.S.: FreeBSD rules!!!___
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: Citrix Xenserver and FreeBSD migration/suspend scripts

2012-08-14 Thread Egoitz Aurrekoetxea Aurre 
I was assuming here you were using my script's... Well anyway all right if 
solved.. But what are you then running now?



El 13/08/2012, a las 03:53, moto kawasaki m...@kawasaki3.org escribió:

 
 Hi Egoitz-san,
 
 Thank you very much for your reply!!
 
 Year, I've tried that in xe-update-guest-attrs:
 
xenstore_write_cached attr/PVAddons/MajorVersion 6
xenstore_write_cached attr/PVAddons/MinorVersion 0
xenstore_write_cached attr/PVAddons/MicroVersion 2
 
 But still XenCenter recognises it as old version of xenserver-tools.
 
 
 
 was Xenserver 6.2.0 wasn't it??
 No, it was 6.0.2. I haven't had a chance to figure this out as I
 don't have a 6.0.2 XenServer available right now.
 
 This is true. XenServer version is 6.0.2. just for clarification.
 
 
 Best Regards,
 
 
 
 -- 
 moto kawasaki m...@kawasaki3.org 090-2464-8454
___
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 8.2-RELEASE Xen error xennet_get_responses: too many frags 7 max 5

2011-09-27 Thread Egoitz Aurrekoetxea Aurre 

Good afternoon,

I'm doing some checks on a FreeBSD 8.2-RELEASE VM running XENHVM kernel in 
a XenCloud Virtualization host machine. I'm starting to see this errors :


xennet_get_responses: too many frags 6  max 5
xennet_get_responses: too many frags 7  max 5
xennet_get_responses: too many frags 6  max 5
xennet_get_responses: too many frags 6  max 5
xennet_get_responses: too many frags 6  max 5
xennet_get_responses: too many frags 6  max 5
xennet_get_responses: too many frags 7  max 5
xennet_get_responses: too many frags 6  max 5
xennet_get_responses: too many frags 6  max 5
xennet_get_responses: too many frags 6  max 5
xennet_get_responses: too many frags 6  max 5


I have read about this error and know that under future 9.0-RELEASE this 
will be fixed. I have seen which patch is applied and so... but this 
brings me to the following question... could this affect under 8.2-RELEASE 
to the VM network performance?.


Thanks a lot for you're answer.

Godd bye!

___
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: FreeBSD 8.2 XENHVM Kernel on Xencloud

2011-09-21 Thread Egoitz Aurrekoetxea Aurre 



On Wed, 21 Sep 2011, laurent.cli...@gmail.com wrote:


I currently use XenCloud Platform 1.0 on a Dell R210 server hosting 4
VMs. 3 FreeBSD 8.2 with XENHVM kernel and 1 Linux Debian. At first I was
willing to have only FreeBSD VMs, but I had a strange problem when NAT
was enabled on the front FreeBSD Vm that had the public IP address.
Network bandwidth from backend FreeBSD VMs to Internet and from Internet
to backend VMs was incredibly slow, tested with NAT feature of PF and
with natd, same problem, also with GENERIC kernel. Bandwidth between all
VMs was correct, only when passing the NATed public interface caused
problem. That's why I put a Linux box for NAT, which is working
perfectly now.


It would have been nice if you had tested (for the test only), one 
physichal machine with FreeBSD doing nat and the other three vm under Xen 
with FreeBSD, to see if problem persists...this way we could figure now if 
the problem was something to do with Xen or with the own FreeBSD 
configuration... although I assume the problem is in the last one...




So far it was the only problem I had with FreeBSD and Xen Cloud Platform.

My FreeBSD VMs are serving nginx + rails and python apps, PostgreSQL and
MySQL databases, and the perf is good for now. VMs disks are LVM
partitions of XenCloud, not files.




Hope this helps.


Of course!!
Thanks a lot mate,
Good bye!



Regards,

Laurent Cligny







___
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: FreeBSD 8.2 XENHVM Kernel on Xencloud

2011-09-20 Thread Egoitz Aurrekoetxea Aurre 
Sorry, the from header of the last message was wrong... this is the proper 
one




On Tue, 20 Sep 2011, Egoitz Aurrekoetxea Aurre wrote:


Good afternoon,

The subject practically is saying what I'm trying to ask but... does anyone 
tried FreeBSD 8.2 or similar under Cytrix Xenserver or XenCloud?. I have been 
doing some benchmarks and seems to perform pretty nice... and seems to be 
stable too; the only thing would be nice to be available for FreeBSD at 
Xenserver/Xencloud would be the Xenserver/Xencloud's Xentools; although I 
assume Xentools are basically for having info of the ip of the machine 
(hostname, if the machine has been cloned...) and so... because I assume a xe 
migrate and so commands make use of lvm and so... for hot migrations and 
so... should work the same way although are not officially supported in the 
xenserver/xencloud https api.


Has anyone ever had some experience with FreeBSD in this environments?. Which 
of them?, and which FreeBSD version?. The XenCloud version I tried is 
Xencloud 1.0, which makes use of :


Includes Xen hypervisor version 3.4.2
Includes Linux 2.6.32 privileged domain


Thank you very much.
Good bye!.
___
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