From owner-freebsd-xen@freebsd.org Mon Feb 22 16:18:09 2016 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FF6BAB1A00 for ; Mon, 22 Feb 2016 16:18:09 +0000 (UTC) (envelope-from prvs=853c61c85=roger.pau@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CA981B0F for ; Mon, 22 Feb 2016 16:18:08 +0000 (UTC) (envelope-from prvs=853c61c85=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.22,485,1449532800"; d="scan'208";a="339973356" Subject: Re: Porting the block-iscsi hotplug script To: =?UTF-8?Q?Gustau_P=c3=a9rez?= , FreeBSD XEN 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> From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Message-ID: <56CB34BA.6060809@citrix.com> Date: Mon, 22 Feb 2016 17:18:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CB2D90.5080809@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 16:18:09 -0000 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.