From owner-freebsd-xen@FreeBSD.ORG Mon Dec 3 11:06:56 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 6C88D10B for ; Mon, 3 Dec 2012 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5878FC20 for ; Mon, 3 Dec 2012 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB3B6un3027790 for ; Mon, 3 Dec 2012 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB3B6t6D027788 for freebsd-xen@FreeBSD.org; Mon, 3 Dec 2012 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Dec 2012 11:06:55 GMT Message-Id: <201212031106.qB3B6t6D027788@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-xen@FreeBSD.org Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org 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 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/171873 xen [xen] xn network device floods warning in dmesg o kern/171138 xen [xen] [panic] Deactivating network interface produces o kern/171118 xen [xen] FreeBSD XENHVM guest doesn't shutdown cleanly o kern/166174 xen [xen] Problems ROOT MOUNT ERROR o kern/165418 xen [xen] Problems mounting root filesystem from XENHVM o kern/164630 xen [xen] XEN HVM kernel: run_interrupt_driven_hooks: stil o kern/164450 xen [xen] Failed to install FreeeBSD 9.0-RELEASE from CD i o kern/162677 xen [xen] FreeBSD not compatible with "Current Stable Xen" o kern/161318 xen [xen] sysinstall crashes with floating point exception o kern/155468 xen [xen] Xen PV i386 multi-kernel CPU system is not worki o kern/155353 xen [xen] [patch] put "nudging TOD" message under boot_ver o kern/154833 xen [xen]: xen 4.0 - DomU freebsd8.2RC3 i386, XEN kernel. o kern/154473 xen [xen] xen 4.0 - DomU freebsd8.1 i386, XEN kernel. Not o kern/154472 xen [xen] xen 4.0 - DomU freebsd8.1 i386 xen kernel reboot o kern/154428 xen [xen] xn0 network interface and PF - Massive performan o kern/153674 xen [xen] i386/XEN idle thread shows wrong percentages o kern/153672 xen [xen] [panic] i386/XEN panics under heavy fork load o kern/153620 xen [xen] Xen guest system clock drifts in AWS EC2 (FreeBS o kern/153477 xen [xen] XEN pmap code abuses vm page queue lock o kern/153150 xen [xen] xen/ec2: disable checksum offloading on interfac o kern/152228 xen [xen] [panic] Xen/PV panic with machdep.idle_mwait=1 o kern/144629 xen [xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor o kern/143398 xen [xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor o kern/143340 xen [xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor f kern/143069 xen [xen] [panic] Xen Kernel Panic - Memory modified after f kern/135667 xen ufs filesystem corruption on XEN DomU system f kern/135421 xen [xen] FreeBSD Xen PVM DomU network failure - netfronc. f kern/135178 xen [xen] Xen domU outgoing data transfer stall when TSO i p kern/135069 xen [xen] FreeBSD-current/Xen SMP doesn't function at all f i386/124516 xen [xen] FreeBSD-CURRENT Xen Kernel Segfaults when config o kern/118734 xen [xen] FreeBSD 6.3-RC1 and FreeBSD 7.0-BETA 4 fail to b 31 problems total. 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 From owner-freebsd-xen@FreeBSD.ORG Tue Dec 4 01:31:45 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 6B926D6B for ; Tue, 4 Dec 2012 01:31:45 +0000 (UTC) (envelope-from prvs=1685a61a7f=evendas@krazer.com.br) Received: from krazer.com.br (usaimport.com.br [74.208.147.131]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7618FC38 for ; Tue, 4 Dec 2012 01:31:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=krazer.com.br; s=MDaemon; t=1354583467; x=1355188267; q=dns/txt; h=DomainKey-Signature: Received:From:To:Subject:Date:MIME-Version:Content-Type: Message-ID; bh=/AGF6JRzB/J7iTsWt8UkF/2jJ0/KNRujXWNnXTa6qHA=; b=b FY2H2FrBnjFX6JmyQvKqD7AFIebx+f7hhCOLAs6/Z0MYpkJO9DsEbd/ryu1ivdKh YAdyyo8SPWiMaJhYN6bPLOpo4AYVbDsAujXmOKbF/h1LgNK+0eKPfdlGGlSzBfsm 4wY2tiJI73qn/pW5k/tFCG8bemBHXE+2ueDkMRy2Rk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=krazer.com.br; c=simple; q=dns; h=from:message-id; b=uRaA1vNhPjPnTeDKrSloLP0ztx5XGYREPgSIohoiNFDE7uydIhpl7pzuZqcr uXEP7dyHuvIEMcqobHOKOIaBGnfs6L+ls62hGkBK0AzMhDAetVAjvY8aj IoH08B1lgOm4i25FXbbWsgQ+KaoJ0Az5b09DHxKAJDyqUURBjRfGtQ=; X-MDAV-Processed: allearth.com.br, Mon, 03 Dec 2012 23:11:07 -0200 Received: from krazer by allearth.com.br (MDaemon PRO v11.0.0) with ESMTP id md50003170670.msg for ; Mon, 03 Dec 2012 23:11:05 -0200 X-Spam-Processed: allearth.com.br, Mon, 03 Dec 2012 23:11:05 -0200 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: evendas@krazer.com.br X-MDRemoteIP: 74.208.167.75 X-Return-Path: prvs=1685a61a7f=evendas@krazer.com.br X-Envelope-From: evendas@krazer.com.br X-MDaemon-Deliver-To: freebsd-xen@freebsd.org From: "Vendas Krazer Technologies" To: Subject: =?utf-8?B?Tm92YSBDUEUgS3JhemVyIFNreSBTdGF0aW9uIDVHSHo=?= =?utf-8?B?IE4gLSBDUEUgQW50ZW5hIEludGVncmFkYSBkZSAxOGRCaQ==?= =?utf-8?B?IGUgQ29tIFNhw61kYSBwYXJhIEFudGVuYSBFeHRlcm5h?= Date: Mon, 03 Dec 2012 22:08:18 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=45652905_3502_4801_0078_850943129657" Message-ID: X-Mailer: Clientes Krazer 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: Tue, 04 Dec 2012 01:31:45 -0000 This is a multi-part message in MIME format. ------=45652905_3502_4801_0078_850943129657 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lan=C3=A7amento CPE Krazer Sky Station 5GHz N Voc=C3=AA cliente pediu que a Krazer fizesse uma nova CPE num formato mais = estiloso, pequena, de menor tamanho e que tivesse novas funcionabilidade, m= ais especificamente acesso f=C3=A1cil ao bot=C3=A3o de reset, prote=C3=A7= =C3=A3o contra queima e a t=C3=A3o desejada SA=C3=8DDA PARA ANTENA EXTERNA!= !! R$ 179.90 Antena Integrada de 18dBi 60=C2=BA Duas Portas de Rede Lan e Wan PA Real de 630mW e LNA Ultra Ganho PoE Passivo com Prote=C3=A7=C3=A3o Dupla de 12 a 24V Fonte Chaveada 12V Full Range 110 a 220V Exclusiva Sa=C3=ADda para Antena Externa Homologa=C3=A7=C3=A3o Anatel 0269-11-5280 Instala=C3=A7=C3=A3o R=C3=A1pida e Simples. Software Amigavel e em Portugu=C3=AAs! Suporte a PPPoE Wisp Cliente! Controle de Banda! Excelente sinal de recep=C3=A7=C3=A3o! Longa Dist=C3=A2ncia! Fa=C3=A7a um teste em sua rede e compare com os concorrentes, muito mais si= nal que UBNT, muito mais dados, transmiss=C3=A3o de quase 90Mbps TCP/IP con= tinuamente! Lat=C3=AAncia de rede de 1 a 5 ms com carga completa! Contate-nos Val Campos // Carla Maria // Eder Roberto Email / MSN: vendas@allearth.com.br Vendas / SAC (19) 3256-5557 (19) 3245-0708 www.krazer.com.br Envio de Email n=C3=A3o autorizado =C3=A9 crime, n=C3=A3o seja o vil=C3=A3o= da hist=C3=B3ria! Email =C3=A9 protegido sobre sigilo fiscal e federal. Le= i Federal Brasil. ------=45652905_3502_4801_0078_850943129657-- From owner-freebsd-xen@FreeBSD.ORG Tue Dec 4 04:44:10 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 3C2A529D for ; Tue, 4 Dec 2012 04:44:10 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id DD50D8FC08 for ; Tue, 4 Dec 2012 04:44:09 +0000 (UTC) Received: from [127.0.0.1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id qB44XqAS015351; Mon, 3 Dec 2012 20:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1354595633; bh=gd09LZOaw199TtF5L3IKrBmZcxCgIgC7IoQB8I5nDSo=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=sFMGgLUXFpGIlASQatpjIlaGpLlVr2VuVlBR0nYEipYdlkAyRsk8/qtmgoEBvI/B5 8lMY6lTgEYwfXPFS+xJ8ET0Ngmq52Q4Zq5MRKBUbrmyZWnqRvDIResA6lZIXkuo6xB YLsDHUVvPVeJzMooe4pYK4c8KKagx9+70nfG9llI= Subject: Re: xenbusb_nop_confighook_cb timeout and cd issue From: Sean Bruno To: Egoitz Aurrekoetxea Aurre In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 03 Dec 2012 20:33:51 -0800 Message-ID: <1354595632.3045.7.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 595632001 Cc: "freebsd-xen@freebsd.org" 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: Tue, 04 Dec 2012 04:44:10 -0000 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.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 = 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+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……. 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 = [ 'file:/servidores/freebsd90r/freebsd90js.img,hda,w', 'file:/imagenes-cd/FreeBSD-9.1-RC3-amd64-disc1.iso,hdc:cdrom,r' ] > boot = 'cd' > device_model = 'qemu-dm' > sdl = 0 > vnc = 1 > vncpasswd = 'agoodpassword' > serial = 'pty' > > And after booting properly and from the own vm inside the Dom0 running Debian and Xen : > > > 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 > 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 = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 > Features=0x1781fbff > Features2=0x81b82201 > AMD Features=0x28100800 > AMD Features2=0x1 > real memory = 536870912 (512 MB) > avail memory = 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=0x300> > 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 != 255h,63s). > cd0 at ata1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > 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 : > > 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=aac&sektion=4&manpath=FreeBSD+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… > > > So, summarizing : > > Seems like under Debian with the same version of Xen works properly, so… 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 : > > > > 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… but I assume this should be much easier and faster to if could be checked by some of the Xen development staff. > > Let us know something please, > Very thankful, > Best regards. If you have the time, can you submit a PR for this issue? I'll try and reproduce it in tomorrow after I get the xen4 hypervisor working again. Sean From owner-freebsd-xen@FreeBSD.ORG Tue Dec 4 08:01:18 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 78C90100 for ; Tue, 4 Dec 2012 08:01:18 +0000 (UTC) (envelope-from egoitz@sarenet.es) Received: from proxypop03b.sare.net (proxypop03b.sare.net [194.30.0.251]) by mx1.freebsd.org (Postfix) with ESMTP id 721188FC12 for ; Tue, 4 Dec 2012 08:01:16 +0000 (UTC) Received: from [172.16.2.46] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id D8B249E0813; Tue, 4 Dec 2012 09:00:53 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: xenbusb_nop_confighook_cb timeout and cd issue From: Egoitz Aurrekoetxea Aurre In-Reply-To: <1354595632.3045.7.camel@powernoodle> Date: Tue, 4 Dec 2012 09:01:15 +0100 Message-Id: <1EC8AB9E-C684-41F3-8467-A27E1165AE03@sarenet.es> References: <1354595632.3045.7.camel@powernoodle> To: Sean Bruno 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 Cc: "freebsd-xen@freebsd.org" 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: Tue, 04 Dec 2012 08:01:18 -0000 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=85 I'll tell here how the = progress goes=85. Best regards, Egoitz Aurrekoetxea Departamento de sistemas egoitz@sarenet.es El 04/12/2012, a las 05:33, Sean Bruno escribi=F3:= > On Mon, 2012-12-03 at 19:04 +0100, Egoitz Aurrekoetxea Aurre wrote: >> Good morning, >>=20 >> 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 : >>=20 >> ENV 1.- XCP 1.6 XEN 4.1.3 + FREEBSD 9.1-RC3 : >>=20 >> 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 >>=20 >> BUT If I do a in the XCP shell :=20 >>=20 >> xe vm-cd-remove uuid=3D08aec342-9572-8690-5e58-91d1b1f0aab2 = cd-name=3Dxs-tools.iso >>=20 >> The drive is being removed from the vm and it boots normally. This = is the workaround I'm using for the moment. >>=20 >> 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. >>=20 >> --- /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); >> } >>=20 >> 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. >>=20 >> ENV 2.- Debian Wheezy (testing) XEN 4.1.3 + FreeBSD 9.1-RC3 : >>=20 >> Here is the concrete environment and config :=20 >>=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 >>=20 >> root@pruebas-xen-egoitz:~# cat /etc/issue >> Debian GNU/Linux wheezy/sid \n \l >>=20 >> 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 >>=20 >> 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 >>=20 >> I normally create the life cycle with a xm new, later xm start=85=85. = the config file is :=20 >>=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' >>=20 >> And after booting properly and from the own vm inside the Dom0 = running Debian and Xen :=20 >>=20 >>=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 >>=20 >> root@pruebas:/root # xen-detect=20 >> Running in HVM context on Xen v4.1. >>=20 >> 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 >>=20 >> A test showing how I'm able to mount an iso image : =20 >>=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) >>=20 >> 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 >>=20 >>=20 >> So, summarizing : =20 >>=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 >>=20 >>=20 >>=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 >>=20 >> Let us know something please, >> Very thankful, >> Best regards. >=20 >=20 > If you have the time, can you submit a PR for this issue? I'll try = and > reproduce it in tomorrow after I get the xen4 hypervisor working = again. >=20 > Sean >=20 From owner-freebsd-xen@FreeBSD.ORG Tue Dec 4 21:03:07 2012 Return-Path: Delivered-To: xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25484EA2 for ; Tue, 4 Dec 2012 21:03:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 855B58FC0C for ; Tue, 4 Dec 2012 21:03:06 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qB4L2tnF019951 for ; Tue, 4 Dec 2012 23:02:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qB4L2tnF019951 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qB4L2tbV019950 for xen@freebsd.org; Tue, 4 Dec 2012 23:02:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Dec 2012 23:02:55 +0200 From: Konstantin Belousov To: xen@freebsd.org Subject: Call for testers: vfork(2) repair for Xen Message-ID: <20121204210255.GS3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jF32gZOFbnzmk3b4" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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: Tue, 04 Dec 2012 21:03:07 -0000 --jF32gZOFbnzmk3b4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 al= l. 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; =20 -#ifdef XEN - flags =3D RFFDG | RFPROC; /* validate that this is still an issue */ -#else flags =3D RFFDG | RFPROC | RFPPWAIT | RFMEM; -#endif =09 error =3D fork1(td, flags, 0, &p2, NULL, 0); if (error =3D=3D 0) { td->td_retval[0] =3D p2->p_pid; --jF32gZOFbnzmk3b4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQvmT+AAoJEJDCuSvBvK1BSJ4P/A1tLbh5f2lG1rJZ18N43QF1 tB80M1jCkM0HFByLuzlZiDmQ1ewSLIhOPChBbCc6HwV5TaqHIm5wZFb0s9KaAjpz 9Hzx9GUGzMaBS0/4/WaK4yAdz3vDx3sPenSeyldOn5VM7Y8twPBOzvN2Cd8nZwMQ IKwKSy7KycBop5jdlEw6LA4HDV5XZNCDgqjolBd0G8QCZroxiI/Wv9aB5npOH1Ia fsLiwUBus6kc8aY4MZqe9J+SzXN7g3WK0/ZXtpzQx5KUxPFgGdXopscQq1CTfhbs X6L4eGMJHP27qaDp3x1B/v+kYX61gujiLNA9sMJcbqs6rgpricjnC1VAbgto/3l4 cLHGPFSPWOmyi5LeEHr6qXyGhZ4LJahufrsUQeYUYCl71W2NrJC9saOaMqlzkTl/ lL1MJcw05d0vMXDrhPwVKOs2weo54EeSZLOjTFZDebKqPBNi5zQHFQ77Mj8r14WN LXBTN4bsV1Xzyj4guI3EZMy0PE/kh61k02F+V4TF0rH4HvOKVQ41lTRVmueXY5Tc pB/AhrpM0EOM54Qizb4VrkJf2iAw7+6LBxYGn3CYLY11+qWbvxn+0i8ieHFdT1oO DtS1sdWfOHmgL0paW7tMp6bRs/tFSyQMiFfCJsD10gefGvlJ44vQSo8LtRhXA2Bd 3SpdVmSRJAJyRwvtKpeN =0Ts+ -----END PGP SIGNATURE----- --jF32gZOFbnzmk3b4-- From owner-freebsd-xen@FreeBSD.ORG Tue Dec 4 21:12:33 2012 Return-Path: Delivered-To: xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45126215 for ; Tue, 4 Dec 2012 21:12:33 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 10F6F8FC13 for ; Tue, 4 Dec 2012 21:12:32 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so3139278pbc.13 for ; Tue, 04 Dec 2012 13:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=QS9imGUfFZk1XMh0my4xE2L90YcvdJhZ3OMvFhWFwYs=; b=s2mGz6Ie+VnhLHssTmLK7H4J8hhBx5y9RE8o5wUk2/oF5v89YuKporVEH2Q+fEnUHc 25h0MbqyUSjRmmoASjLTlP8xPlxNjAX43iivI0lvAZhuPwQVevXG8dz/CTf25ebZz8aT 0H/CICxipQqi4kLu8SUFYzSRK8WrF0M7RZhQgW21mU7r5ng20PpaB3We38jFHkwuvjJ4 Je8K/R1uT7m8WbGtXvk+djK5+KYRV7tS9aMcdiB+KPO8P4KY9TiRBsrJFceZw5x3SRKo 2iqiFcZ4kAm2uxlluOD8f3b6CynJ7AfVlEfvleiMBv+6KezQeOk0si8LWjT00gROMn95 WtMw== Received: by 10.66.72.71 with SMTP id b7mr38282167pav.28.1354655552533; Tue, 04 Dec 2012 13:12:32 -0800 (PST) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com. [209.131.62.116]) by mx.google.com with ESMTPS id hs2sm1563894pbc.22.2012.12.04.13.12.31 (version=SSLv3 cipher=OTHER); Tue, 04 Dec 2012 13:12:31 -0800 (PST) Subject: Re: Call for testers: vfork(2) repair for Xen From: Sean Bruno To: Konstantin Belousov In-Reply-To: <20121204210255.GS3013@kib.kiev.ua> References: <20121204210255.GS3013@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" Date: Tue, 04 Dec 2012 13:12:30 -0800 Message-ID: <1354655550.2302.9.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: xen@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org 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: Tue, 04 Dec 2012 21:12:33 -0000 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 From owner-freebsd-xen@FreeBSD.ORG Thu Dec 6 11:00:26 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 387D0E02 for ; Thu, 6 Dec 2012 11:00:26 +0000 (UTC) (envelope-from egoitz@sarenet.es) Received: from proxypop03b.sare.net (proxypop03b.sare.net [194.30.0.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6E68A8FC14 for ; Thu, 6 Dec 2012 11:00:24 +0000 (UTC) Received: from [192.168.12.224] (unknown [212.81.198.13]) by proxypop03.sare.net (Postfix) with ESMTPSA id 471839DFB6B for ; Thu, 6 Dec 2012 11:59:54 +0100 (CET) From: Egoitz Aurrekoetxea Aurre Subject: Fwd: xenbusb_nop_confighook_cb timeout and cd issue Date: Thu, 6 Dec 2012 12:00:15 +0100 References: <2697A59B-A505-4A32-8E74-A1D42572738F@sarenet.es> To: "freebsd-xen@freebsd.org" Message-Id: <4AD92DFA-7153-4E79-B906-1CBEAAC6B6A3@sarenet.es> 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: Thu, 06 Dec 2012 11:00:26 -0000 I resend the whole mail because seems the attached patch below didn't = arrive before=85.=20 Regards, Egoitz Aurrekoetxea Departamento de sistemas egoitz@sarenet.es Inicio del mensaje reenviado: > De: Egoitz Aurrekoetxea Aurre > 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 , Mark Felder >=20 > This is the mail sent to freebsd-xen mailing list. >=20 > Best regards, >=20 > Egoitz Aurrekoetxea > Departamento de sistemas > egoitz@sarenet.es >=20 >=20 > Inicio del mensaje reenviado: >=20 >> De: Egoitz Aurrekoetxea Aurre >> 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" >>=20 >> Good morning, >>=20 >> 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 : >>=20 >> ENV 1.- XCP 1.6 XEN 4.1.3 + FREEBSD 9.1-RC3 : >>=20 >> 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 >>=20 >> BUT If I do a in the XCP shell :=20 >>=20 >> xe vm-cd-remove uuid=3D08aec342-9572-8690-5e58-91d1b1f0aab2 = cd-name=3Dxs-tools.iso >>=20 >> The drive is being removed from the vm and it boots normally. This = is the workaround I'm using for the moment. >>=20 >> 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. >>=20 >> --- /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); >> } >>=20 >> 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. >>=20 >> ENV 2.- Debian Wheezy (testing) XEN 4.1.3 + FreeBSD 9.1-RC3 : >>=20 >> Here is the concrete environment and config :=20 >>=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 >>=20 >> root@pruebas-xen-egoitz:~# cat /etc/issue >> Debian GNU/Linux wheezy/sid \n \l >>=20 >> 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 >>=20 >> 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 >>=20 >> I normally create the life cycle with a xm new, later xm start=85=85. = the config file is :=20 >>=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' >>=20 >> And after booting properly and from the own vm inside the Dom0 = running Debian and Xen :=20 >>=20 >>=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 >>=20 >> root@pruebas:/root # xen-detect=20 >> Running in HVM context on Xen v4.1. >>=20 >> 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 >>=20 >> A test showing how I'm able to mount an iso image : =20 >>=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) >>=20 >> 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 >>=20 >>=20 >> So, summarizing : =20 >>=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 >>=20 >=20 >>=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 >>=20 >> Let us know something please, >> Very thankful, >> Best regards. >>=20 >> Egoitz Aurrekoetxea >> Departamento de sistemas >> egoitz@sarenet.es >>=20 >>=20 >=20 From owner-freebsd-xen@FreeBSD.ORG Thu Dec 6 11:04:28 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 15372E93 for ; Thu, 6 Dec 2012 11:04:28 +0000 (UTC) (envelope-from egoitz@sarenet.es) Received: from proxypop03b.sare.net (proxypop03b.sare.net [194.30.0.251]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0B38FC0C for ; Thu, 6 Dec 2012 11:04:26 +0000 (UTC) Received: from [192.168.12.224] (unknown [212.81.198.13]) by proxypop03.sare.net (Postfix) with ESMTPSA id D94409DF902 for ; Thu, 6 Dec 2012 12:04:01 +0100 (CET) From: Egoitz Aurrekoetxea Aurre Subject: Fwd: xenbusb_nop_confighook_cb timeout and cd issue Date: Thu, 6 Dec 2012 12:04:22 +0100 References: <4AD92DFA-7153-4E79-B906-1CBEAAC6B6A3@sarenet.es> To: "freebsd-xen@freebsd.org" Message-Id: 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: Thu, 06 Dec 2012 11:04:28 -0000 Seems freebsd.org mailman is removing my patch attachment=85. I send it = through a URL you can see=85. The patch of the URL is : = http://postfixquotareject.ramattack.net/xen-x86-interrupt-pointer-missmatc= h.diff So I correct below :=20 Sorry for this. Egoitz Aurrekoetxea Departamento de sistemas egoitz@sarenet.es Inicio del mensaje reenviado: >>=20 >> Inicio del mensaje reenviado: >>=20 >>> De: Egoitz Aurrekoetxea Aurre >>> 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" >>>=20 >>> Good morning, >>>=20 >>> 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 = : >>>=20 >>> ENV 1.- XCP 1.6 XEN 4.1.3 + FREEBSD 9.1-RC3 : >>>=20 >>> 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 >>>=20 >>> BUT If I do a in the XCP shell :=20 >>>=20 >>> xe vm-cd-remove uuid=3D08aec342-9572-8690-5e58-91d1b1f0aab2 = cd-name=3Dxs-tools.iso >>>=20 >>> The drive is being removed from the vm and it boots normally. This = is the workaround I'm using for the moment. >>>=20 >>> 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. >>>=20 >>> --- /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); >>> } >>>=20 >>> 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. >>>=20 >>> ENV 2.- Debian Wheezy (testing) XEN 4.1.3 + FreeBSD 9.1-RC3 : >>>=20 >>> Here is the concrete environment and config :=20 >>>=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 >>>=20 >>> root@pruebas-xen-egoitz:~# cat /etc/issue >>> Debian GNU/Linux wheezy/sid \n \l >>>=20 >>> 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 >>>=20 >>> 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 >>>=20 >>> I normally create the life cycle with a xm new, later xm start=85=85. = the config file is :=20 >>>=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' >>>=20 >>> And after booting properly and from the own vm inside the Dom0 = running Debian and Xen :=20 >>>=20 >>>=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 >>>=20 >>> root@pruebas:/root # xen-detect=20 >>> Running in HVM context on Xen v4.1. >>>=20 >>> 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 >>>=20 >>> A test showing how I'm able to mount an iso image : =20 >>>=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) >>>=20 >>> 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 >>>=20 >>>=20 >>> So, summarizing : =20 >>>=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 >>>=20 >>=20 = http://postfixquotareject.ramattack.net/xen-x86-interrupt-pointer-missmatc= h.diff >>>=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 >>>=20 >>> Let us know something please, >>> Very thankful, >>> Best regards. >>>=20 >>> Egoitz Aurrekoetxea >>> Departamento de sistemas >>> egoitz@sarenet.es >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org"