From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUOnl-0007Vo-GM for qemu-devel@nongnu.org; Tue, 03 Feb 2009 12:11:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUOnj-0007Ud-QG for qemu-devel@nongnu.org; Tue, 03 Feb 2009 12:11:09 -0500 Received: from [199.232.76.173] (port=41529 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUOnj-0007UZ-KB for qemu-devel@nongnu.org; Tue, 03 Feb 2009 12:11:07 -0500 Received: from wf-out-1314.google.com ([209.85.200.174]:50055) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUOnj-0002JF-8m for qemu-devel@nongnu.org; Tue, 03 Feb 2009 12:11:07 -0500 Received: by wf-out-1314.google.com with SMTP id 27so2340001wfd.4 for ; Tue, 03 Feb 2009 09:11:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1233666609.5644.12.camel@ecrins.fosdick.home.net> References: <1233666609.5644.12.camel@ecrins.fosdick.home.net> Date: Tue, 3 Feb 2009 09:11:05 -0800 Message-ID: <13f991410902030911v2472a531j64ef717f955b2bf0@mail.gmail.com> Subject: Re: [Qemu-devel] VM stops responding, 100% CPU, switching to monitor fails From: Nathan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: nejucomo@gmail.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi Steve, This may be the issue I just posted about. To test, in the host, run strace on the qemu process. If the output shows many SIGALRM signals between fewer calls to "clone" which return ERESTARTNOINTR, then it's the same issue and I can advise you. Otherwise, I'm not much help (I'm new to qemu). regards, Nathan Wilcox On Tue, Feb 3, 2009 at 5:10 AM, Steve Fosdick wrote: > I am currently experiencing an issue where the guest VM stops > responding, attempting to switch to the monitor does not do anything > either and the host CPU usage shows as 100% system. > > So far the only solution I have found is to kill the qemu process. A > normal SIGTERM signal seems to be sufficient. > > This is with kernel 2.6.28.2, kqmeu 1.3.0~pre11 and qemu 0.9.1. > > Do you have any tips on what I can do to get to the bottom of this? > > I am thinking as the CPU usage is all system time that there maybe an > infinite loop running within kqemu though I would not know if the loop > was in code that is part of kqemu itself or the guest OS. If the guest > had got stuck in an infinite loop though I would have hoped the monitor > would still work. > > Regards, > Steve. > > >