Date: Mon, 22 Feb 2016 16:47:28 +0100 From: =?UTF-8?Q?Gustau_P=c3=a9rez?= <gustau.perez@gmail.com> To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>, FreeBSD XEN <freebsd-xen@freebsd.org> Subject: Re: Porting the block-iscsi hotplug script Message-ID: <56CB2D90.5080809@gmail.com> In-Reply-To: <56CB041E.1020009@citrix.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Greets, Gustau [1] http://pastebin.com/Xmr8ArCD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56CB2D90.5080809>