El 22/2/16 a les 13:34, Gustau Pérez ha escrit:
>> It might be that the IOMMU has an errata and Xen refuses to enable it.
>> Can you provide the serial output when you try to boot Xen + FreeBSD?
>> You might have to add console="com1,vga" to your xen_cmdline (although
>> AFAIK that's the default).
>    Hi Roger,
>    I was able to get a dump of the output via the serial console [1]. If
> I force the detection of the iommu with [2] the system is able to boot
> the domU kernel and then it panics [3], it would appear it panics when

I guess you mean Dom0 here instead of DomU, because the log you provided
shows that Dom0 is not even able to finish the boot process.

> detecting atapci0. Here I'm lost.

Right, the interesting bit is:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0xffffffff804169a1
stack pointer           = 0x28:0xfffffe0120435a30
frame pointer           = 0x28:0xfffffe0120435a90
code segment        = base 0x0, limit 0xfffff, type 0x1b
            = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, IOPL = 0
current process     = 12 (irq23: atapci0)
trap number     = 9
panic: general protection fault
cpuid = 0
Uptime: 1s

Is there any chance you can use a kernel with debug options enabled
(ddb)? This way we should be able to get a back trace of the call chain.

Also, can you provide the output of running:

# addr2line -e /path/to/kernel/debug/sym 0xffffffff804169a1

The kernel symbols are usually stored at
/usr/lib/debug/boot/kernel/kernel.debug in modern FreeBSD versions.

freebsd-xen@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Reply via email to