From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EZvzU-0004H6-Ay for qemu-devel@nongnu.org; Wed, 09 Nov 2005 14:52:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EZvzO-0004Gp-KG for qemu-devel@nongnu.org; Wed, 09 Nov 2005 14:52:12 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EZvzM-0004Ge-9N for qemu-devel@nongnu.org; Wed, 09 Nov 2005 14:52:08 -0500 Received: from [195.168.1.142] (helo=mailhub3.nextra.sk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EZvzM-0007qC-D4 for qemu-devel@nongnu.org; Wed, 09 Nov 2005 14:52:08 -0500 Message-ID: <4372520E.9040601@atlas.sk> Date: Wed, 09 Nov 2005 20:46:22 +0100 From: ace MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] qemu and software suspend 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 Hi. Has somebody tried to hibernate Linux while qemu is running? Here is my experience: 1. I was running qemu 0.7.2 fullscreen (under X with SDL), on Linux 2.6.14 host, with Win95 quest. All was fine, together with kqemu. 2. I changed to a virtual console and initiated hibernate (software suspend2 2.2-rc9). Everything latest stuff :) 3. That's when weird things started. The kernel throwed a "BUG", with the usual instruction and stack dump. The offending process was kswapd0. 4. But it successfully hibernated anyway. This was my first kernel complaint at hibernating ever. 5. After resuming the machine later, it seemed to work fine. I switched to qemu, but it was almost dead. Actually, qemu was fine, but the guest OS was almost dead. I could move application windows a bit, click on things to select them, but all this stopped after a while (seconds) and it didn't respond again. But qemu was going along. I could toggle fullscreen and it was taking 100% CPU (which is correct here). The management console worked fine. 6. On the host side, I noticed kswapd0 (kernel swap thread) was killed, but the OS still swapped fine. 7. I couldn't wake win95 so I had to quit qemu. My questions: 1. May there be a problem with the kqemu module? Does it have proper suspend/resume routines? Or it doesn't need them (it is not a device driver)? 2. Can the problem also be inside Win95? What happens in qemu when the time in the host system suddenly changes? Mine skipped 20 hours. Does the time in the quest continue without skips, thus the guest has different time than the host? Before win95 completelly stopped responding, it showed the old time from before the suspending on the taskbar. Or does qemu synchronise the time to the host? But I doubt that, mine was drifting behind even without suspending, the machine is quite slow. I'd like to ask if suspending with qemu is officially declared "A bad thing to do", or it should work, but I have something wrong with my system. I run latest Slackware 10.2 on a Pentium MMX. Peter