From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2 2/6] reuse env stop and stopped states Date: Tue, 28 Jul 2009 09:17:05 +0300 Message-ID: <4A6E97E1.9050902@redhat.com> References: <1248214392-12533-1-git-send-email-glommer@redhat.com> <1248214392-12533-2-git-send-email-glommer@redhat.com> <1248214392-12533-3-git-send-email-glommer@redhat.com> <4A6DCB33.5020008@redhat.com> <20090728004822.GQ4776@poweredge.glommer> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Marcelo Tosatti To: Glauber Costa Return-path: Received: from mx2.redhat.com ([66.187.237.31]:56420 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752990AbZG1GRH (ORCPT ); Tue, 28 Jul 2009 02:17:07 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n6S6H879013603 for ; Tue, 28 Jul 2009 02:17:08 -0400 In-Reply-To: <20090728004822.GQ4776@poweredge.glommer> Sender: kvm-owner@vger.kernel.org List-ID: On 07/28/2009 03:48 AM, Glauber Costa wrote: > On Mon, Jul 27, 2009 at 06:43:47PM +0300, Avi Kivity wrote: > >> On 07/22/2009 01:13 AM, Glauber Costa wrote: >> >>> qemu CPUState already provides "stop" and "stopped" states. And they >>> mean exactly that. There is no need for us to provide our own. >>> >>> >>> >> This patch (known as dd0e1c1a589 in qemu-kvm.git) breaks reboot. My >> test case is FC6 i386 -smp 2, running the reboot command in rc.local. >> In about 15 minutes qemu hangs hard. Please check what's gone wrong. >> > I found out that doing kill -38 makes it run again, so we're likely > hanging somewhere while holding qemu_mutex. The state of the process is "D", > so we're holding qemu_mutex, and then calling something that can block. > Sounds like we call a vcpu ioctl from the iothread (or from a different vcpu thread). > It's hard for me to believe that this patch introduced it. At best, it might have > made it more likely. Also, I also verified that it sometimes takes a while until > it happen for the first time. Are you sure this is the first patch that makes it happen? > I haven't been able to reproduce it before this patch. Maybe this patch doesn't introduce it, only exposes it. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.