[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] win2k3 freeze possible kqemu rtc bug

From: Wil
Subject: [Qemu-devel] win2k3 freeze possible kqemu rtc bug
Date: Mon, 20 Apr 2009 14:01:26 +0100

I've been running some tests with qemu using win2k3 as a guest. I've tried
multiple versions and configurations and thought I would report my findings
as best as possible.

Qemu 0.9.1 / kqemu 1.3.0pre11 with / without -kernel-kqemu (32 and 64 bit
qemu - different kernels and machines were used)
Qemu 0.10.2 / kqemu 1.4.0pre1 with / without -kernel-kqemu (32 and 64 bit
qemu under same kernel and machine and also a different kernel / machine)

The above combinations all seem to freeze (process consumes all available
CPU) after a few hours or days depending on how much load I place on the
machine. I'm running test scripts to place a load on the guest. The guest
has domain/iis/exchange/sql express 2005 installed.

I did try Qemu 0.10.2 with -no-kqemu and without the kqemu module loaded, it
did seem to run ok. I can't be certain though as I was forced to abort the
test as I had other things to do. In general 0.10.2 was freezing quicker
than 0.9.1 and timewise at least (as opposed amount of work done) 0.10.2
without kqemu worked significantly longer. Enabling the win2k3 ntp client
seemed to cause a freeze a lot sooner sometimes even before 1st logon

I've come to believe the key issue may be SQL 2005 Express SP3 which uses an
rtc timer with 1024Hz freq. I believe this service pack was only released
recently. I did try increasing the rtc max user freq sysctl variable to 1024
which did not seem to help. Without the rtc-hack option in 0.10.2 the clock
was loosing something like 4 secs every minute. 

An interesting point is that I migrated the guest to vbox and during my
first test it also froze up after a few hours. I believe the reason for this
however was because I forgot to unload the kqemu module, as once I unloaded
it the problem went away. Vbox however has an issue with high cpu idle due
to the above rtc freq (not sure if that's relevant of course).

Hopefully there is enough information to investigate as I'm sure it would
improve the general reliability or qemu/kqemu if it can be fixed.

Will Wiseman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]