From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jm6xY-0002PN-Jt for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:41:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jm6xW-0002NC-LY for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:41:55 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jm6xW-0002N7-G6 for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:41:54 -0400 Received: from ns.suse.de ([195.135.220.2] helo=mx1.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jm6xW-0001qp-8F for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:41:54 -0400 Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id A6B7940887 for ; Wed, 16 Apr 2008 14:41:51 +0200 (CEST) Message-ID: <4805F2D2.4000602@suse.de> Date: Wed, 16 Apr 2008 14:36:34 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Reboot CPU on triple fault References: <47EE86E0.4070703@reactos.org> <9C7667CB-2CF0-4AC0-843B-6EF442196CAC@csgraf.de> <47F0B445.4030806@suse.de> <4804D254.5040301@siemens.com> <4805B673.3010200@suse.de> <4805EAE6.1070601@siemens.com> In-Reply-To: <4805EAE6.1070601@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Jan Kiszka schrieb: > And we need a consensus regarding fault reporting... What about > confining the dump to the logfile, leaving the console alone? Seems that the message is a big problem now, even if intentional triple-faulting didn't work in the past and caused qemu to abort. So yes, maybe the logfile must be enough. But we definitely need a new -d option then so that a developer can always run qemu with this option. The existing ones (most notably -d int where this one would belong logically) are producing way too much output to have them always enabled. Kevin