Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Dec 2014 19:43:00 +0100
From:      =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
To:        "David P. Discher" <dpd@dpdtech.com>
Cc:        freebsd-xen@freebsd.org
Subject:   Re: Attempting to Get Xen FreeBSD Dom0 working
Message-ID:  <547F59B4.1010105@citrix.com>
In-Reply-To: <29437DB9-7DC8-47A8-8FC4-2BFDE736B5BC@dpdtech.com>
References:  <481F7D02-BFE9-4E35-A475-5A8A05A801CE@dpdtech.com> <547DFCC0.6030003@citrix.com> <DCB954B5-0E45-4DE6-AAC4-C5ACF7FD90A7@dpdtech.com> <547F1476.8080305@citrix.com> <29437DB9-7DC8-47A8-8FC4-2BFDE736B5BC@dpdtech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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é <roger.pau@citrix.com> 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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?547F59B4.1010105>