Date: Mon, 22 Feb 2016 17:18:02 +0100 From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com> To: =?UTF-8?Q?Gustau_P=c3=a9rez?= <gustau.perez@gmail.com>, FreeBSD XEN <freebsd-xen@freebsd.org> Subject: Re: Porting the block-iscsi hotplug script Message-ID: <56CB34BA.6060809@citrix.com> In-Reply-To: <56CB2D90.5080809@gmail.com> References: <553DEB97.5000300@entel.upc.edu> <5540A053.4080409@entel.upc.edu> <5540F3FC.80606@citrix.com> <5541FC8A.8080009@citrix.com> <5542365D.10403@entel.upc.edu> <55423ECD.6000404@citrix.com> <5556F21D.2050005@entel.upc.edu> <555EEFBA.5080902@citrix.com> <555EF542.3090002@citrix.com> <555F9B3F.1000600@entel.upc.edu> <55602512.1090702@citrix.com> <56C6FA2F.8040900@gmail.com> <56CAC8CB.8030107@gmail.com> <56CADEDA.4050007@citrix.com> <56CB0057.1060509@gmail.com> <56CB041E.1020009@citrix.com> <56CB2D90.5080809@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56CB34BA.6060809>