From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GxQiz-0006oE-UB for qemu-devel@nongnu.org; Thu, 21 Dec 2006 11:24:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GxQiy-0006nJ-05 for qemu-devel@nongnu.org; Thu, 21 Dec 2006 11:24:53 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GxQix-0006nF-OM for qemu-devel@nongnu.org; Thu, 21 Dec 2006 11:24:51 -0500 Received: from [194.25.134.83] (helo=mailout07.sul.t-online.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GxQix-0000N9-Cn for qemu-devel@nongnu.org; Thu, 21 Dec 2006 11:24:51 -0500 Message-ID: <458AB534.2050306@t-online.de> Date: Thu, 21 Dec 2006 17:24:20 +0100 From: Werner Dittmann MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Question/problems with Qemu and 64Bit Opensuse 10.2 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 All, currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu. Using a plain 0.82 didn't work out, after the Install screen Qemu goes in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc). I could not even stop Qemu but had to use kill -9 . Because of some mail in the list that reported similar errors I downloaded the latest CVS version and built it using a gcc 3.3. That didn't solve the problem: It seems to be in a loop but I can close the qemu window and the window also grabs the mouse cursor (that was not the case with the 0.8.2 version). After loading the kernel I get the following message on the console (only in VESA mode): " Decompressing Linux ... done. Booting the kernel. " and at the bottom of the console screen the message (without the qutes): "kernel direct mapping tables up to 100000000 @ 8000-d000" I tried to switch on some -d but I don't know which one is relevant here. I tried "-d int" but this produced about 90MB log data in just some seconds. Which info do you need to get down to the problem? What can I try to tackle the problem? Regards, Werner PS: Because I'm somewhat experienced with security software I would ask if there is any interest to have a TPM module (Software based TPM) for Qemu that looks like a real HW TPM according the the TPM specs? If yes I would start to look how to do it for Qemu. There is a software based TPM avaliable with a GPL licence. The "only thing" to do would be to wrap it with the HW interface functions (it's a memory mapped interface) so that standard drivers would see it as standard TPM module. Werner