El 07/04/15 a les 13.11, Gustau Pérez ha escrit:
> Hi Roger,
>>>> If you don't have a serial console you
>>>> should use console=vga in your xen_cmdline. Additionally if you have a
>>>> usb debug port you could use that as console with console=dbgp .
>>> Thank you. I did not have a console at $home (the laptop has no
>>> physical serial port) but at $work my laptop dockstation provides me
>>> with a physical serial port. I'll try to use it.
> Well, my current laptop (Dell latitude E6430) and the previous one
> (Fujitsu Lifebook) have that. I'd say that even an old D630 laptop had
> that option. It is quite useful.
>> I didn't know there were dock stations that provided serial ports even
>> when the laptop didn't have them, that's something worth a try. If not
>> just setting console=vga ought to provide some output. If that also
>> fails please write back and I will provide a patch for the bootloader in
>> order to try to figure out what's going on.
> I added a new test machine. I'll show my results with this one (I'll
> report my laptop results later).
> The new machine is
> Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
> EPT and IOMMU are there:
> [root@hast16 ~/xen]# dmesg|grep EPT
> VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID
> [root@hast16 ~/xen]# acpidump -t | grep DMAR
> DMAR: Length=432, Revision=1, Checksum=213,
> First I tried xen and xen-tools from ports (version 4.5, hoping those
> were enought). The boot failed, he error says iommu is not enabled. The
> complete log is here:
Yup, there's an errata with that specific chipset :(.
> so I switched to git version instead. The error was the same. I
> suspect this is the reason:
> (XEN) [VT-D]Disabling IOMMU due to Intel 5500/5520/X58 Chipset
> errata #47, #53
> According to the article  it is possible to prevent interruption
> remapping. I added iommu=no-intremap (it is listed in ), it appears
> the xen kernel is happy with that, but then the domain0 FreeBSD kernel
Could you add iommu=no-intremap,debug? That will make the IOMMU code a
little bit more verbose. Also the full boot log and a backtrace of
FreeBSD might be helpful.
I think I have an idea of what might cause this GP, can you apply the
following patch to the Xen source tree and recompile the Xen kernel,
(there's no need to recompile the tools):
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e1c55ce..fc3c45b 100644
@@ -3102,8 +3102,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
if ( exit_qualification & 0x10 )
/* INS, OUTS */
- if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
- !handle_mmio() )
+ if ( !handle_mmio() )
>  http://support.citrix.com/article/CTX136517
> PS: I'd like to talk about the behavior of the xen_cmdline reboot
> option. Setting it "no" causes the machine to stop (which is fine) but
> the machine remains there. Perhaps it'd be good to allow to reboot the
> machine by pressing a key when in panic. Otherwise you have physically
> reboot the machine.
Yes, this is possible from the serial console. Press Ctrl-A tree times
(to switch to the Xen console), and then 'R' (note the caps).
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"