From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Max1l-0007I1-UP
	for qemu-devel@nongnu.org; Tue, 11 Aug 2009 15:28:58 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Max1h-0007G9-5u
	for qemu-devel@nongnu.org; Tue, 11 Aug 2009 15:28:57 -0400
Received: from [199.232.76.173] (port=36636 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Max1g-0007Fy-W1
	for qemu-devel@nongnu.org; Tue, 11 Aug 2009 15:28:53 -0400
Received: from mx2.redhat.com ([66.187.237.31]:43485)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1Max1g-0000wr-85
	for qemu-devel@nongnu.org; Tue, 11 Aug 2009 15:28:52 -0400
Message-ID: <4A81C669.8070300@redhat.com>
Date: Tue, 11 Aug 2009 21:28:41 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] virtio-blk/qdev failure in the current git tree
References: <20090810235646.GA12872@lst.de> <4A80BB6B.3020001@codemonkey.ws>
	<20090811161302.GA2053@lst.de> <20090811163638.GA4891@lst.de>
In-Reply-To: <20090811163638.GA4891@lst.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.gnu.org/pipermail/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: Christoph Hellwig <hch@lst.de>
Cc: qemu-devel@nongnu.org

On 08/11/09 18:36, Christoph Hellwig wrote:
> On Tue, Aug 11, 2009 at 06:13:02PM +0200, Christoph Hellwig wrote:
>> With the fix pulled it the guest kernel now hangs after
>>
>> 	input: ImExPS/2 Generic Explorer Mouse as /class/input/input2
>> 	Clocksource tsc unstable (delta = -782142631 ms)
>>
>> when reducing the config to just one virtio-blk device it books, but
>> with a longish break at the point where the original config hangs.
>
> The culprit is commit d176c495b6664b72dc1e595f6e89dc5648aa248b
>
> 	qdev-ify virtio-blk.
>
> reverting it (needs some manual work due to the macrofication of the
> qdev attributes) fixes the boot again.

Hmm.  I suspect this is not related to qdev and virtio-blk at all.  I've 
noticed now and then that some pci devices don't work if you have many 
of them.  Didn't try (yet) to root-cause that one.

The commit changes the initialization order of the virtio-blk devices, 
which probably makes them being placed in other PCI slots, which in turn 
might uncover the bug mentioned above in your setup.

How are the pci devices assigned to slots with and without the patch?

Does removing the balloon device (-balloon none) change the behavior?
Does removing the nic (-net none) too change the behavior?

cheers,
   Gerd