From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=47540 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OEdig-0000eb-2R
	for qemu-devel@nongnu.org; Wed, 19 May 2010 03:30:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <hch@lst.de>) id 1OEdiJ-0001PW-5f
	for qemu-devel@nongnu.org; Wed, 19 May 2010 03:29:28 -0400
Received: from verein.lst.de ([213.95.11.210]:35985)
	by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <hch@lst.de>)
	id 1OEdiI-0001O7-J1
	for qemu-devel@nongnu.org; Wed, 19 May 2010 03:29:10 -0400
Date: Wed, 19 May 2010 09:29:02 +0200
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20100519072902.GA711@lst.de>
References: <4BDF3F94.1080608@dlh.net> <4BDFDC44.9030808@redhat.com>
	<4BE00750.6040804@dlh.net> <4BE01120.30608@redhat.com>
	<4BE02440.6010802@dlh.net> <4BE028BF.1000603@redhat.com>
	<4BEAB4B0.70803@dlh.net> <4BED1740.1080604@redhat.com>
	<4BF275B1.8030106@dlh.net> <4BF2949C.8010108@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BF2949C.8010108@redhat.com>
Subject: [Qemu-devel] Re: qemu-kvm hangs if multipath device is queing
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Peter Lieven <pl@dlh.net>, qemu-devel@nongnu.org, kvm@vger.kernel.org, Christoph Hellwig <hch@lst.de>

On Tue, May 18, 2010 at 03:22:36PM +0200, Kevin Wolf wrote:
> I think it's stuck here in an endless loop:
> 
>     while (laiocb->ret == -EINPROGRESS)
>         qemu_laio_completion_cb(laiocb->ctx);
> 
> Can you verify this by single-stepping one or two loop iterations? ret
> and errno after the read call could be interesting, too.

Maybe the compiler is just too smart.  Without some form of barrier
it could just optimize the loop away as laiocb->ret couldn't change
in a normal single-threaded environment.