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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
