Re: [Qemu-devel] qemu and software suspend

[ace]

Oliver Gerlich wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> ace schrieb:
> 
>>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)?
> 
> 
> Have you already tried to hibernate without haveing kqemu loaded? That
> could narrow down the problem.
Yes, I have now find the problem. Coincidentally, I just upgraded the
kernel before trying suspending with qemu and the kswapd0 bustage was a
bug in it. It is now officially fixed per 2.6.14.2. I am using a
nondefault io sheduler, that's why nobody else has seen this.
Who would have thought there can be bugs in the Linux kernel :)

But still after fixing this problem, all other symptoms with qemu stay
valid.

>>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 notice that when I stop emulation (while eg. Win2k is running in qemu)
> and resume qemu some hours later, the guest clock has paused and is then
> wrong by some hours. You could try that as well with Win95 and see what
> happens (you can stop emulation by executing "stop" in the qemu monitor,
> and resume operation by running "c" in the monitor).
I have tried this, stopping qemu for several minutes and I couldn't see
any problems. Yes, the quests time is then wrong, but the quest OS
worked fine.

>>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.
> There's been a posting on that topic some weeks ago, with a link to
> http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html#suspend
> You could try hibernating with that patch applied.

Thanks, I missed this posting on the mailinglist somehow (and it was
only 1 month old...). There was also another patch for this problem, and
that seems to work (see next email from me).

Peter