From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J4QVR-0001yt-Bq for qemu-devel@nongnu.org; Mon, 17 Dec 2007 19:40:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J4QVP-0001wY-EH for qemu-devel@nongnu.org; Mon, 17 Dec 2007 19:40:20 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J4QVP-0001wO-BC for qemu-devel@nongnu.org; Mon, 17 Dec 2007 19:40:19 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J4QVO-0005UT-TU for qemu-devel@nongnu.org; Mon, 17 Dec 2007 19:40:19 -0500 Received: by ug-out-1314.google.com with SMTP id m2so26864uge.4 for ; Mon, 17 Dec 2007 16:40:17 -0800 (PST) Message-ID: Date: Tue, 18 Dec 2007 01:40:17 +0100 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] qemu vl.c In-Reply-To: <3924.N1pNGSpdEBQ=.1197935190.squirrel@webmail.hotelhot.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16604_7521547.1197938417897" References: <200712161430.35113.paul@codesourcery.com> <476543A0.9090207@flac.kalibalik.dk> <200712170058.35739.paul@codesourcery.com> <4766EBDB.1020308@qumranet.com> <3924.N1pNGSpdEBQ=.1197935190.squirrel@webmail.hotelhot.dk> 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 ------=_Part_16604_7521547.1197938417897 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 18/12/2007, Anders wrote: > > >>>>> Redundant timer rearm optimisation by Anders Melchiorsen. > > > I'm merging qemu-cvs into the kvm repository now, and with this commit > > in, kvm will hang after about a minute. Attaching to it with gdb or > > strace will cause it to resume, so this is very likely a missing signal > > problem. > > That is clearly not good. > > I still cannot see anything wrong with my patch. As fewer signals are > delivered now, it is possible that this change highlights some old race. Yes, I don't see anything wrong in this change either but I see how the scenario given by Paul was already buggy before. Paul confirmed on IRC that this is also what he meant. I suspect it was buggy since "unix" and "rtc" stopped being the only available clock sources. > It is certainly also possible that my patch is all wrong, even if I am not > able to see it. > > > The next few days I will be travelling, but when I get back, I was > planning to address Pauls concern by adding > > qemu_rearm_alarm_timer(alarm_timer); That would be also my first guess at fixing this, but I have no good test-case (obviously I wouldn't have committed the change if I had such a test-case). > > to the bottom of qemu_mod_timer(). > > If you feel like it, you can try that out. I am predicting that I will > have a hard time reproducing your hang, as I have only been testing with > kvm, and obviously not seen this problem yet. > > (What I really plan to add is a rearm only if the new timer is added at > the head of the list, but the above should do for a test) Attached is a small patch to do exactly this. The rearming in main_loop_wait() can also be made conditional but I don't think there would be a real gain. Testing with KVM will be appreciated. Regards ------=_Part_16604_7521547.1197938417897 Content-Type: text/x-patch; name=qemu-timers.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fabrurbh Content-Disposition: attachment; filename=qemu-timers.patch ZGlmZiAtLWdpdCBhL3ZsLmMgYi92bC5jCmluZGV4IDcwOTUwZjguLjc1NTJmZGUgMTAwNjQ0Ci0t LSBhL3ZsLmMKKysrIGIvdmwuYwpAQCAtMTA0MSw2ICsxMDQxLDEwIEBAIHZvaWQgcWVtdV9tb2Rf dGltZXIoUUVNVVRpbWVyICp0cywgaW50NjRfdCBleHBpcmVfdGltZSkKICAgICB0cy0+ZXhwaXJl X3RpbWUgPSBleHBpcmVfdGltZTsKICAgICB0cy0+bmV4dCA9ICpwdDsKICAgICAqcHQgPSB0czsK KworICAgIC8qIHJlYXJtIGlmIHRoZSBuZWNlc3NhcnkgKi8KKyAgICBpZiAocHQgPT0gJmFjdGl2 ZV90aW1lcnNbdHMtPmNsb2NrLT50eXBlXSkKKyAgICAgICAgcWVtdV9yZWFybV9hbGFybV90aW1l cihhbGFybV90aW1lcik7CiB9CiAKIGludCBxZW11X3RpbWVyX3BlbmRpbmcoUUVNVVRpbWVyICp0 cykK ------=_Part_16604_7521547.1197938417897--