From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jm6Lq-0004EC-RU for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:02:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jm6Lq-0004Dw-9Z for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:02:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jm6Lq-0004Dt-6C for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:02:58 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jm6Lp-0001WK-Ku for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:02:57 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m3GC2tWZ004084 for ; Wed, 16 Apr 2008 14:02:55 +0200 Received: from [139.21.95.227] (mchn012c.mchh.siemens.de [139.21.95.227] (may be forged)) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id m3GC2tev011412 for ; Wed, 16 Apr 2008 14:02:55 +0200 Message-ID: <4805EAE6.1070601@siemens.com> Date: Wed, 16 Apr 2008 14:02:46 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <47EE86E0.4070703@reactos.org> <9C7667CB-2CF0-4AC0-843B-6EF442196CAC@csgraf.de> <47F0B445.4030806@suse.de> <4804D254.5040301@siemens.com> <4805B673.3010200@suse.de> In-Reply-To: <4805B673.3010200@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] Reboot CPU on triple fault 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 Kevin Wolf wrote: > Jan Kiszka schrieb: >> As the same requirement came up here, I worked out the following patch. >> I feel a bit uneasy about it because >> >> o I'm unsure if breaking out of the exception loop is OK this way. >> >> o including necessary headers fails, mostly due to stdio redefinitions >> in dyngen-exec.h. >> >> This patch behaves as it should, but only in one specific test case. >> Feedback is welcome. > > This is exactly the behaviour I'd like to have. I still needed a small > change to your patch, though: You shouldn't return 0 from > check_exception, after all it's not a divide error. I'm not sure if > EXCP_HLT is the right thing to return here, but the attached patch works > for me. Without this change it kept hanging in a loop forever writing > more dumps than I ever wanted. ;-) Your version still works for me (and makes more sense than return 0, indeed). So we just need someone to confirm that this is actually a clean way to leave the fault handling. And we need a consensus regarding fault reporting... What about confining the dump to the logfile, leaving the console alone? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux