From owner-freebsd-xen@FreeBSD.ORG Wed Dec 3 18:43:30 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D4B2505 for ; Wed, 3 Dec 2014 18:43:30 +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 3F0ECADB for ; Wed, 3 Dec 2014 18:43:28 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="199540165" Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.3.181.6; Wed, 3 Dec 2014 13:43:01 -0500 Message-ID: <547F59B4.1010105@citrix.com> Date: Wed, 3 Dec 2014 19:43:00 +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.2.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> In-Reply-To: <29437DB9-7DC8-47A8-8FC4-2BFDE736B5BC@dpdtech.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-DLP: MIA2 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: Wed, 03 Dec 2014 18:43:30 -0000 Hello, El 03/12/14 a les 18.18, David P. Discher ha escrit: > > > On Dec 3, 2014, at 5:47 AM, Roger Pau Monné wrote: > >> The good news is that I think I have a patch that solves this, but I'm >> afraid we will also have to debug the ACPI error shown above in order to >> get your system to a working state. >> >> Could you please try the following patch on top of my pvh_dom0_v8 branch? >> >> https://people.freebsd.org/~royger/xen_pci.patch >> >> Roger. > > > Hey Roger - > > Thanks for the com change, that seems to have gotten the Xen’s serial output going, which is included below. I think as you expected, got yet another panic, however at a different place. Panic summary here. Full console messages below … and for reference, also included the full boot messages from the same kernel booting the bare metal. > > Let know what you are thinking as the problem … I can certainly do some more poking and trail and error stuff on my own as well, but just need a bit more information and guidance. I rarely hang out on IRC, but certainly can jump over there for collaboration. > > Thanks again ! > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x60 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff80e53fa3 > stack pointer = 0x28:0xffffffff82318b70 > frame pointer = 0x28:0xffffffff82318ba0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [ thread pid 0 tid 100000 ] > Stopped at acpi_install_wakeup_handler+0x113: movq %r14,0x60(%r15) > db> bt > Tracing pid 0 tid 100000 td 0xffffffff8180bcf0 > acpi_install_wakeup_handler() at acpi_install_wakeup_handler+0x113/frame 0xffffffff82318ba0 > nexus_xen_attach() at nexus_xen_attach+0xe0/frame 0xffffffff82318bc0 > device_attach() at device_attach+0x38f/frame 0xffffffff82318c20 > bus_generic_new_pass() at bus_generic_new_pass+0x116/frame 0xffffffff82318c50 > bus_set_pass() at bus_set_pass+0x8c/frame 0xffffffff82318c80 > configure() at configure+0xa/frame 0xffffffff82318c90 > mi_startup() at mi_startup+0x108/frame 0xffffffff82318cb0 > xen_start() at xen_start+0x1f > db> Thanks for being able to test this so quickly, AFAICT this is a fallout from failing to initialize ACPI. I don't have a system with this specific ACPI configuration to trigger this, but I have the following patch, which _might_ solve your problem: https://people.freebsd.org/~royger/xen_acpi.patch Again, it should be applied on top of your already patched pvh_dom0_v8 branch (don't remove the previous patch). If this doesn't solve your problem I will try to find a similar box so I can reproduce the issue. Roger.