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 . If
>> I force the detection of the iommu with  the system is able to boot
>> the domU kernel and then it panics , 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 
>> 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:
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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"