From owner-freebsd-xen@FreeBSD.ORG Mon Dec 3 18:11:00 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88F9A2B9 for ; Mon, 3 Dec 2012 18:11:00 +0000 (UTC) (envelope-from egoitz@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id BC3418FC12 for ; Mon, 3 Dec 2012 18:10:58 +0000 (UTC) Received: from [172.16.2.46] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id D46939DD371 for ; Mon, 3 Dec 2012 19:04:10 +0100 (CET) From: Egoitz Aurrekoetxea Aurre Subject: xenbusb_nop_confighook_cb timeout and cd issue Message-Id: Date: Mon, 3 Dec 2012 19:04:20 +0100 To: "freebsd-xen@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:11:00 -0000 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=85.. (I paste here both screenshot location). =09 http://postfixquotareject.ramattack.net/PastedGraphic-8.tiff http://postfixquotareject.ramattack.net/PastedGraphic-11.tiff = =20 =20 I have placed here two examples, with an empty (but existing) cd drive = and with a iso mounted in the drive.=20 BUT If I do a in the XCP shell :=20 xe vm-cd-remove uuid=3D08aec342-9572-8690-5e58-91d1b1f0aab2 = cd-name=3Dxs-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.000000000 +0200 +++ /usr/src/sys/kern/subr_autoconf.c 2012-10-10 18:21:51.000000000 = +0200 @@ -133,16 +133,17 @@ /* Block boot processing until all hooks are disestablished. */ mtx_lock(&intr_config_hook_lock); warned =3D 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) =3D=3D 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 :=20 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+46 amd64 = 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 Name ID 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=85=85. = the config file is :=20 root@pruebas-xen-egoitz:~# cat /etc/xen/freebsd90rjs.ramattack.net.cfg kernel =3D '/usr/lib/xen-4.1/boot/hvmloader' builder =3D 'hvm' vcpus =3D 2 memory =3D 512 name =3D 'freebsd90js.ramattack.net' vif =3D [ 'bridge=3Deth0, mac=3D00:13:3E:19:88:22, type=3Dioemu' ] disk =3D [ 'file:/servidores/freebsd90r/freebsd90js.img,hda,w', = 'file:/imagenes-cd/FreeBSD-9.1-RC3-amd64-disc1.iso,hdc:cdrom,r' ] boot =3D 'cd' device_model =3D 'qemu-dm' sdl =3D 0 vnc =3D 1 vncpasswd =3D 'agoodpassword' serial =3D 'pty' And after booting properly and from the own vm inside the Dom0 running = Debian and Xen :=20 root@pruebas:/root # uname -ar FreeBSD pruebas.sare.net 9.1-RC3 FreeBSD 9.1-RC3 #0: Fri Nov 30 12:14:50 = CET 2012 root@pruebas.sare.net:/usr/obj/usr/src/sys/XENHVM amd64 root@pruebas:/root # xen-detect=20 Running in HVM context on Xen v4.1. root@pruebas:/root # dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RC3 #0: Fri Nov 30 12:14:50 CET 2012 root@pruebas.sare.net:/usr/obj/usr/src/sys/XENHVM amd64 CPU: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz (1862.83-MHz = K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x106e5 Family =3D 6 Model =3D 1e = Stepping =3D 5 = Features=3D0x1781fbff = Features2=3D0x81b82201 AMD Features=3D0x28100800 AMD Features2=3D0x1 real memory =3D 536870912 (512 MB) avail memory =3D 492093440 (469 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a0000 (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 1.3 (no driver attached) vgapci0: mem = 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 xenpci0: port 0xc000-0xc0ff mem = 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0 xenstore0: on xenpci0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on = acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 fdc0: No FDOUT register! ctl: CAM Target Layer loaded Timecounters tick every 10.000 msec xenbusb_front0: on xenstore0 xn0: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:13:3e:19:88:22 xenbusb_back0: on xenstore0 xctrl0: on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xbd0: 40920MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 xbd1: 685MB at device/vbd/5632 on xenbusb_front0 xbd1: attaching as ad2 GEOM: ad0s1: geometry does not match label (16h,63s !=3D 255h,63s). cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [350977 x 2048 byte records] SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a [rw]... xn0: 2 link states coalesced A test showing how I'm able to mount an iso image : =20 root@pruebas:/root # mount /dev/ad0s1a on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ad2 on /puntomontajes (cd9660, local, read-only) root@pruebas:/root # ls -la /puntomontajes/ total 638 drwxr-xr-x 17 root wheel 4096 Jan 1 1970 . drwxr-xr-x 19 root wheel 1024 Dec 3 11:42 .. -rw-r--r-- 2 root wheel 1011 Oct 30 02:48 .cshrc -rw-r--r-- 2 root wheel 253 Oct 30 02:48 .profile drwxr-xr-x 2 root wheel 4096 Oct 30 02:47 .rr_moved -r--r--r-- 1 root wheel 6200 Oct 30 02:48 COPYRIGHT -r--r--r-- 1 root wheel 13814 Oct 30 02:48 ERRATA.HTM -r--r--r-- 1 root wheel 8442 Oct 30 02:48 ERRATA.TXT -r--r--r-- 1 root wheel 201433 Oct 30 02:48 HARDWARE.HTM -r--r--r-- 1 root wheel 122955 Oct 30 02:48 HARDWARE.TXT -r--r--r-- 1 root wheel 20807 Oct 30 02:48 README.HTM -r--r--r-- 1 root wheel 14764 Oct 30 02:48 README.TXT -r--r--r-- 1 root wheel 118904 Oct 30 02:48 RELNOTES.HTM -r--r--r-- 1 root wheel 61896 Oct 30 02:48 RELNOTES.TXT drwxr-xr-x 2 root wheel 6144 Oct 30 02:47 bin drwxr-xr-x 7 root wheel 6144 Oct 30 02:48 boot dr-xr-xr-x 2 root wheel 2048 Oct 30 02:47 dev -r--r--r-- 1 root wheel 4143 Oct 30 02:48 docbook.css drwxr-xr-x 20 root wheel 12288 Oct 30 02:48 etc drwxr-xr-x 3 root wheel 6144 Oct 30 02:48 lib drwxr-xr-x 3 root wheel 2048 Oct 30 02:48 libexec drwxr-xr-x 2 root wheel 2048 Oct 30 02:47 media drwxr-xr-x 2 root wheel 2048 Oct 30 02:47 mnt dr-xr-xr-x 2 root wheel 2048 Oct 30 02:47 proc drwxr-xr-x 2 root wheel 2048 Oct 30 02:47 rescue drwxr-xr-x 2 root wheel 2048 Oct 30 02:48 root drwxr-xr-x 2 root wheel 16384 Oct 30 02:48 sbin lrwxr-xr-x 1 root wheel 11 Oct 30 02:47 sys -> usr/src/sys drwxrwxrwt 2 root wheel 2048 Oct 30 02:47 tmp drwxr-xr-x 15 root wheel 2048 Oct 30 02:48 usr drwxr-xr-x 23 root wheel 4096 Oct 30 02:47 var root@pruebas:/root # fgrep -r -i aa /puntomontajes/* = /puntomontajes/HARDWARE.HTM:"http://www.FreeBSD.org/cgi/man.cgi?query=3Daa= c&sektion=3D4&manpath=3DFreeBSD+9-current"> /puntomontajes/HARDWARE.HTM:aac(4) driver /puntomontajes/HARDWARE.HTM:

Adaptec AAC-364

/puntomontajes/HARDWARE.HTM:

Newer ServeRAID controllers are supported = by the aac(4) or mfi(4) driver.

/puntomontajes/HARDWARE.HTM:

RAIDarray 230 controllers, aka the = Ultra-SCSI DEC KZPAC-AA (1-ch, 4MB cache), KZPAC-CA /puntomontajes/HARDWARE.HTM:

Texas Instruments TSB43AA22

/puntomontajes/HARDWARE.HTM:

Texas Instruments TSB82AA2

/puntomontajes/HARDWARE.TXT: [i386,ia64,amd64] Controllers supported = by the aac(4) driver /puntomontajes/HARDWARE.TXT: * Adaptec AAC-364 /puntomontajes/HARDWARE.TXT: Newer ServeRAID controllers are sup . . . . etc etc=85 So, summarizing : =20 Seems like under Debian with the same version of Xen works properly, so=85= I have taken a look at the patches applied to Xen sources for composing = the Debian package and concretely one of them drew my attention :=20 If someone at Citrix or XEN development team is reading this could tell = us something?. Could this give a clue for solving the problem?. I can = further investigate too if no one knows about it=85 but I assume this = should be much easier and faster to if could be checked by some of the = Xen development staff.=20 Let us know something please, Very thankful, Best regards. Egoitz Aurrekoetxea Departamento de sistemas egoitz@sarenet.es