From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KluDt-0006Im-Ew for qemu-devel@nongnu.org; Fri, 03 Oct 2008 19:38:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KluDr-0006IW-B9 for qemu-devel@nongnu.org; Fri, 03 Oct 2008 19:38:12 -0400 Received: from [199.232.76.173] (port=57107 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KluDr-0006IT-6H for qemu-devel@nongnu.org; Fri, 03 Oct 2008 19:38:11 -0400 Received: from rv-out-0708.google.com ([209.85.198.251]:2465) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KluDq-0004UN-OB for qemu-devel@nongnu.org; Fri, 03 Oct 2008 19:38:11 -0400 Received: by rv-out-0708.google.com with SMTP id f25so1640896rvb.22 for ; Fri, 03 Oct 2008 16:38:09 -0700 (PDT) Message-ID: Date: Sat, 4 Oct 2008 01:38:09 +0200 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] Documentation/tools on debuging dyngen code? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081001184025.GA70684@saturn.kn-bremen.de> <20081001202009.GA21305@networkno.de> Reply-To: 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 2008/10/1 Bruce Beare (bbeare) : > I'm working on a 2.6.24 Linux port built for ARCH=powerpc and configured > for the PReP machine. I have the port booting using an unmodified 0.9.1 > version (actually, head from the SVN repo) of qemu-system-ppc but > sometimes find that QEMU "hangs". Analysis of the hang reveals: > > o C-A C-X does not respond > o QEMU is sucking up 100% cpu time of one processor > o GDB to the kernel debug port (qemu option -s -p 1234) is non > responsive > o ltrace, strace show no system or library calls in progress > o GDB on QEMU shows that it is executing apparently valid code in the > 0x4xxxxxxx > range. > > My conclusion is that QEMU is looping while executing the dynamically > generated code. I'd like to debug this further... and am looking for > some pointers on how to do so. Is there a built-in debugger? Is there a I'm seeing a similar lock-up since around the time of the conversion to TCG. It's caused by an interrupt being lost for some reason (a signal not causing an exit from cpu loop properly). I've hit it on an ARM target and Daniel Jacobowitz reproduced it on an x86 target). If what you see is the same problem, adding -clock unix manages to work around it because it means that signals will keep coming even if one is lost and eventually the cpu loop will end, but this isn't a proper fix. Cheers