From owner-freebsd-xen@FreeBSD.ORG Fri Dec 5 11:56:42 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52ED0F75 for ; Fri, 5 Dec 2014 11:56:42 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88E90F59 for ; Fri, 5 Dec 2014 11:56:41 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="200671281" Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.3.181.6; Fri, 5 Dec 2014 06:56:27 -0500 Message-ID: <54819D6A.4050603@citrix.com> Date: Fri, 5 Dec 2014 12:56:26 +0100 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "David P. Discher" Subject: Re: Attempting to Get Xen FreeBSD Dom0 working References: <481F7D02-BFE9-4E35-A475-5A8A05A801CE@dpdtech.com> <547DFCC0.6030003@citrix.com> <547F1476.8080305@citrix.com> <29437DB9-7DC8-47A8-8FC4-2BFDE736B5BC@dpdtech.com> <547F59B4.1010105@citrix.com> <2DDCAA68-3B11-4E3C-AE61-EAD8CEEF1E2D@dpdtech.com> <547F6AC1.9060709@citrix.com> <7C356027-01D8-4800-B211-282566BC9871@dpdtech.com> <54801F77.5050700@citrix.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-DLP: MIA1 Cc: freebsd-xen@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 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: Fri, 05 Dec 2014 11:56:42 -0000 El 04/12/14 a les 22.28, David P. Discher ha escrit: > Update: So, I changed a few things, and stuff is working better. > > The Xen kernel line is now: > > dom0_mem=2048M dom0_max_vcpus=4 dom0pvh=1 sync_console com1=115200,8n1,0x3e8 console=vga,com1 iommu=debug I would advise against sync_console, it can easily cause delays in interrupt delivery which can cause timeouts in FreeBSD. > > Also note, I have these set in FreeBSD: > > console="comconsole vidconsole" > comconsole_speed="115200" > comconsole_port="0x3e8" > boot_multicons="yes" > vm.max_wired=2097152 > verbose_loading="YES" > boot_verbose="" # -v: Causes extra debugging information to be printed > > hint.ahci.0.msi=0 > hw.acpi.verbose=1 > debug.acpi.enable_debug_objects=1 > > So far, no AHCI timeouts. I’v gotten completely through an install of Debian … granted it failed, but for a linux reasons - couldn’t find/download a package. But is still going. > > The change to the console lines also help … console=vga,com1 & sync_console to xen allowed the IPMI SOL COM3 to fully complete the boot under freebsd. And the tty/login ran and displayed on xc0 : > > FreeBSD/amd64 (borg.dpdtech.com) (xc0) I will try to find a system similar to yours with an IPMI SOL console and see if I can figure out what's going on. As a test, could you try to disable the comconsole from FreeBSD and see if that makes a difference? console="vidconsole" And remove all the comconsole_* and boot_multicons options. This will have the side effect of removing serial output from the bootloader, but it might prevent FreeBSD from screwing the Xen serial console. > However, this console will not take any input. I still can’t get switched into the Xen console (Ctrl-A x3) on either the serial of VGA consoles. > > Another troubling item, em0 flaps when debian is starting up: > > xnb(xnb_probe:1144): Claiming device 0, xnb > xnb1.0: bpf attached > xnb(xnb_attach:1292): Attaching to backend/vif/1/0 > xnb(xnb_frontend_changed:1416): frontend_state=Initialising, xnb_state=InitWait > em0: Link is Down > xnb1.0: 2 link states coalesced > (d1) mapping kernel into physical memory > (d1) about to get started... > xnb(xnb_frontend_changed:1416): frontend_state=Connected, xnb_state=InitWait > xnb(xnb_connect_comms:796): rings connected! > em0: Link is up 1000 Mbps Full Duplex > > em0 is in bridge0, which is what the debian.cfg is using. I certainly don't see this kind of flipping on my network card, but I would focus on fixing the console first, so we can get debug info. > > Also, something really odd … hyper calls aren’t working after launching the debian guest - which also means I can’t launch any more guests. > > root@borg:~ # xl list > xc: error: Could not bounce buffer for version hypercall (35 = Resource temporarily unavailabl): Internal error > xc: error: Could not bounce buffer for version hypercall (35 = Resource temporarily unavailabl): Internal error > xc: error: Could not bounce buffer for version hypercall (35 = Resource temporarily unavailabl): Internal error > xc: error: Could not bounce buffer for version hypercall (35 = Resource temporarily unavailabl): Internal error > xc: error: Could not bounce buffer for version hypercall (35 = Resource temporarily unavailabl): Internal error > xc: error: Could not bounce buffer for version hypercall (35 = Resource temporarily unavailabl): Internal error > libxl: error: libxl.c:658:libxl_list_domain: getting domain info list: Resource temporarily unavailable > libxl_list_domain failed. It seems like you are running out of wired memory, you should increase vm.max_wired, this can be changed at runtime with sysctl without problems. > > I’m heading out for the afternoon shortly, but it seems the next thing to do is to get the consoles working correctly so I can get debugging info from the hypervisor. Will hopefully bang on this this evening. Thanks for the efforts, please keep me posted on how it goes. Roger.