From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NdFyG-0005wW-GK for qemu-devel@nongnu.org; Thu, 04 Feb 2010 23:39:08 -0500 Received: from [199.232.76.173] (port=44715 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NdFyF-0005wL-UC for qemu-devel@nongnu.org; Thu, 04 Feb 2010 23:39:07 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NdFyE-00047c-Fe for qemu-devel@nongnu.org; Thu, 04 Feb 2010 23:39:07 -0500 Received: from 78-86-195-86.zone2.bethere.co.uk ([78.86.195.86]:39055 helo=sentinel1.shatteredsilicon.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NdFyE-00047O-5m for qemu-devel@nongnu.org; Thu, 04 Feb 2010 23:39:06 -0500 Received: from [10.2.3.1] (ariia.shatteredsilicon.net [10.2.3.1]) by sentinel1.shatteredsilicon.net (Postfix) with ESMTP id D702BF8802 for ; Fri, 5 Feb 2010 03:59:16 +0000 (GMT) Message-ID: <4B6B9794.3040507@bobich.net> Date: Fri, 05 Feb 2010 03:59:16 +0000 From: Gordan Bobic MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] kqemu and XP guest - lock-up at mup.sys List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, It would appear that kqemu somehow breaks the XP guest under some circumstances. If I install from scratch in qemu+kqemu, it works fine in kqemu, but not on bare metal. The fact it doesn't work on bare metal COULD be related to the fact that on bare metal I'm running off a USB stick (it's a rescue system). If I install onto bare metal (again, onto a USB stick - I have a modified installer that includes the USB disk drivers at setup stage) and then start up that install in qemu, that works as long as I don't apply kqemu. But if I modprobe kqemu and start with -enable-kqemu/-kernel-kqemu (-smp 1 in all cases), the quest instanty locks up at 100% CPU usage. Everything else about the qemu configuration is exactly the same between the runs. Booting the system with -no-acpi at this point causes it to reboot instead of just locking up. I tried with qemu 0.10.5 (RHEL5 from atrpms) and 0.11.1 (built from source). kqemu I use is dkms 1.4.0pre1 from the Dag repository. With kqemu, the guest stops booting (including safe mode) at mup.sys. Googling around for similar problems didn't reveal much of use (other than the usual Windows solution to everything of "reinstall", which isn't an option here because I need the same setup to work both on bare metal and in qemu). Is there a work-around/tweak to make this work? Is there any particular reason why kqemu would break things under these circumstances when running without kqemu works fine, if slower? Is there a difference in how the emulated hardware looks/behaves with and without kqemu? Thanks. Gordan