From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?U8OpYmFzdGllbiBSSUNDSU8=?= Subject: Re: hanging tapdisk2 processes and improper udev rules Date: Fri, 22 Jul 2011 12:01:25 +0200 Message-ID: <4E294A75.9040106@swisscenter.com> References: <4E294068.2030700@leuphana.de> <1311327074.2360.14.camel@ramone> <4E294430.7090805@swisscenter.com> <1311328223.2360.23.camel@ramone> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1311328223.2360.23.camel@ramone> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel Stodden Cc: Andreas Olsowski , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org > The processes, really? Where do they hang? (check out the wait state -- > ps -eopid,wchan:25,cmd or so). > > Or do you mean they're stuck waiting for I/Os? > > Daniel > > They seems to work and to do their job, but they are in a strange state.=20 For example a ps -aux on dom0 hangs when processing the line about the tapdisk process, also it cannot be detached from the=20 vm, and issuing a reboot of the host hangs too (can't kill the process=20 so it doesn't reboot). I fighted quite a lot with this on a debian6 + xen 4.1.x box and found=20 out that disabling the multipath-tools and multipath-tools-boot=20 corrected the problem (but I need them). I thought that maybe it was=20 beacause multipathd try to "multipath" the block device handled by blktap2 and somehow locks it. But it's speculations :) I do not have the the hands on the box at the moment to give you more=20 informations and do not want to hijack this thread. It's just that it=20 looked like the problem I encountered, but I will send you more=20 informations when I am on the box. Thanks, S=C3=A9bastien