El 22/2/16 a les 16:47, Gustau Pérez ha escrit: > > > El 22/02/16 a les 13:50, Roger Pau Monné ha escrit: >> >> 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. > > Sure, my mistake. It was certaintly Dom0 domain (the one started by > the xen kernel). >>> 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. > > Sorry I was unable to get that info earlier, I'm doing this remotely > (I have another machine connected bia serial port). BTW, here is the bt [1] >> 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. > The memory position seems to point to > /usr/src/sys/dev/ata/ata-all.c:351. This is when locking the > ata_channel->state_mtx mutex. If I'm not mistaken (I have no time right > now), that would mean the reference to that mutex does not exist? Why > would that happen, because of the xen kernel freeing it?
AFAICT this is a gp that's injected by Xen when Dom0 tries to execute certain instructions that Xen cannot emulate (INS or OUTS). I've fixed this sometime ago in Xen upstream, but I seem to have missed to add the relevant patches to the port. Can you try to apply the following patches: https://people.freebsd.org/~royger/xen_ins/ To the xen-kernel port and rebuild it? There's no need to apply them to the xen-tools port, this only affects the hypervisor but not the toolstack. Roger. _______________________________________________ freebsd-xen@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
