From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JKlqn-000623-ON for qemu-devel@nongnu.org; Thu, 31 Jan 2008 21:41:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JKlql-00061L-9b for qemu-devel@nongnu.org; Thu, 31 Jan 2008 21:41:56 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKlql-00061E-76 for qemu-devel@nongnu.org; Thu, 31 Jan 2008 21:41:55 -0500 Received: from wx-out-0506.google.com ([66.249.82.226]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JKlqk-00011v-UR for qemu-devel@nongnu.org; Thu, 31 Jan 2008 21:41:55 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1329412wxd.4 for ; Thu, 31 Jan 2008 18:41:53 -0800 (PST) Message-ID: Date: Fri, 1 Feb 2008 09:41:52 +0700 From: "Mulyadi Santosa" Subject: Re: [Qemu-devel] More about slow clock in guest OS In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8122F5B3F5384F6EB9822FC6673E6BA3@intranet> 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 Cc: sergb@unichrom.com hello Sergey... On 1/31/08, Sergey Bychkov wrote: > As I can see, this document anything about what to do if qemu hung :) reading always helps in some degree :) > After some investigations I can say that with the latest (2008/01/30) qemu > from cvs, compiled with gcc-3.4 on linux x86_64 host, guest OS win2k3 works > not too good. So, in other words "it works but not so well". may I interpret it as a progress? > With "-clock dynticks" clock in OS is very slow - and windows time server > can't adjust. Probably due to cost of Qemu timer rearming. And maybe Windows 2003 does certain dyntick by its own...thus enlarging the timer rearming cost. > With "-clock rtc" hung periodically - for up to 5 minutes, 300 seconds. pffff... too much timers get expired? lock contention somewhere...anybody? >This > could happen at bootstrap - when no OS, only BIOS. Then it resumes and works > for some random period of time, then hangs again, and so on. This behaviour > doesn't depend on guest OS, and was reproduced with Knoppix live CD. Note > that host should be periodically busy executing something like torrent > client. Thus..maybe it's Qemu's fault... > Details and startup scripts: > > $ cat knoppix-qemu-nographic.sh > == > QEMU=$HOME/bin/qemu-system-x86_64 > [ -x "$QEMU" ] || QEMU=/usr/bin/qemu-system-x86_64 > sudo modprobe kqemu > echo will use executable $QEMU > DIR=`dirname $0` > [ -z "$DIR" -o "$DIR" == "." ] && DIR=`pwd` > echo DIR is $DIR > PREV_RTC_FREQ=`cat /proc/sys/dev/rtc/max-user-freq` > [ "$PREV_RTC_FREQ" -ge "1024" ] || echo 'WARN: RTC FREQ too slow:' > $PREV_RTC_FREQ > sudo $QEMU -net nic,model=rtl8139,macaddr=52:54:00:80:80:01 -net > tap,script=$DIR/qemu-ifup-br0,downscript=$DIR/qemu-ifdown-br0 -localtime -cdrom > /distrib/knoppix/KNOPPIX_V5.1.0CD-2006-12-30-EN.iso -m 384 -pidfile > $DIR/virt1-knoppix.pid -smp 1 -no-kqemu -clock rtc -vnc :9 Ehm: 1. can you simply use SDL output instead of VNC? 2. what if you don't use -localtime? just courious... > == > $ cat /proc/sys/dev/rtc/max-user-freq > == > 4096 > == ehm...I think 1024 is enough for most cases.. > $ uname -a > == > Linux *** 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 > GNU/Linux > == is that kernel version of the host? can you upgrade it ? let's say to the latest 2.6.24? PS: could you try KVM too? but ehm...well, sounds like you don't have VT enabled Intel processor or SVM enabled AMD processor. So, if you indeed have one...try KVM.. regards, Mulyadi.