From owner-freebsd-xen@freebsd.org Tue Mar 1 13:02:05 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 3F182ABDA27 for ; Tue, 1 Mar 2016 13:02:05 +0000 (UTC) (envelope-from prvs=8619cf47e=roger.pau@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (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 DEB101D0C for ; Tue, 1 Mar 2016 13:02:04 +0000 (UTC) (envelope-from prvs=8619cf47e=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.22,523,1449532800"; d="scan'208";a="335566690" 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> <56CB34BA.6060809@citrix.com> <56CC24BD.6050609@gmail.com> <56CC32E5.5010101@citrix.com> <56CC7637.3080408@gmail.com> <56CF5668.6090605@citrix.com> <56D0091F.80408@gmail.com> <56D02863.7040100@citrix.com> <56D03D95.9090509@gmail.com> <56D04E5F.8070901@citrix.com> <56D42A28.8050701@gmail.com> <56D434FC.8030905@citrix.com> <56D57110.2060406@gmail.com> <56D587D8.6030702@citrix.com> <56D590EA.609@gmail.com> <56D591BA.4020303@gmail.com> From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Message-ID: <56D5929F.7040001@citrix.com> Date: Tue, 1 Mar 2016 14:01:19 +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: <56D591BA.4020303@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA2 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: Tue, 01 Mar 2016 13:02:05 -0000 El 1/3/16 a les 13:57, Gustau Pérez ha escrit: > > > El 1/03/16 a les 13:54, Gustau Pérez ha escrit: >> >> El 1/03/16 a les 13:15, Roger Pau Monné ha escrit: >>>> I tried deleting the xen-tools package and then deleting >>>> /var/db/xen*. After that I rebooted (there was two xenstore processes, >>>> I'd say one is the kernel side process and the other the user space >>>> process, whose binary is installed by the xen-tools port). Finally I >>>> installed the xen-tools. But the error remains. The error can be found >>>> at [1]. >>> Hm, this is weird. First things first, you should only have one >>> xenstored process running in Dom0, so when doing a ps aux you should see: >>> >>> root 675 0.0 0.1 23100 2548 - I 12:21 0:00.69 >>> /usr/local/sbin/xenstored --pid-file... >> This is the output of `ps axuw|grep xenstored|grep -v grep`: >> >> root 4549 0,0 0,1 12772 3124 - I 10:53 0:00,20 >> /usr/local/sbin/xenstored --pid-file /var/run/xenstored.pid >> >>> But only one of those lines, if you have more than one, something is >>> clearly wrong. Can you check if you maybe have duplicated init scripts >>> in /etc/rc.d and /usr/local/etc/rc.d? >>> >>> Then, can you paste the output of `xenstore-ls -fp` before creating the >>> domain that's giving you the error? If you can paste the config file of >>> the domain that might also help tracking this down. >> Sure, [1] is the output of the xenstore-ls -fp and [2] is the config >> of the domain. Also, the block script [3] is so simple that it does nothing. > Hi Roger, > > strike my last, don't know why but now it does not complain. I can't > explain why. > > Thank you and sorry for the noise, OK, no problem. I wouldn't be surprised if there are certain sequences of events that can leave blkback in a deadlocked state. I've tried fixing them, but the disconnection and error paths should be simplified, now it's too messy to understand. Also, make sure your hotplug script writes the "physical-device" node, or else blkback is not going to attach the disk. Roger.