From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NmKK3-000850-S0
	for qemu-devel@nongnu.org; Tue, 02 Mar 2010 00:07:07 -0500
Received: from [199.232.76.173] (port=57321 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NmKK2-00084m-Oe
	for qemu-devel@nongnu.org; Tue, 02 Mar 2010 00:07:06 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <xin.li@rochester.edu>) id 1NmKK1-0002av-Vg
	for qemu-devel@nongnu.org; Tue, 02 Mar 2010 00:07:06 -0500
Received: from cowpens.ceas.rochester.edu ([128.151.162.25]:57703)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <xin.li@rochester.edu>) id 1NmKK1-0002aZ-OO
	for qemu-devel@nongnu.org; Tue, 02 Mar 2010 00:07:05 -0500
Received: from [128.151.137.62]
	(urwireless-dhcp-128-151-137-62.wireless.rochester.edu
	[128.151.137.62])
	by cowpens.ceas.rochester.edu (8.13.6/8.13.6) with ESMTP id
	o22574AF017916
	for <qemu-devel@nongnu.org>; Tue, 2 Mar 2010 00:07:04 -0500 (EST)
Message-ID: <4B8C9CF3.8000700@rochester.edu>
Date: Tue, 02 Mar 2010 00:06:59 -0500
From: Xin Li <xin.li@rochester.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Bug: hpet timer hangs QEMU using icount
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Hpet hangs QEMU when icount is present. I don't know if this is a 
universal problem. The cause is that for periodical timers, hpet_timer 
function tries to insert the timer back to the active timers queue, 
using an updated expire time. However, before the update, if the expire 
time is equal to the current time, this updating will be skipped. As a 
result, this timer will be inserted as is and goes off again and again, 
basically traps itself in a infinite loop, preventing any new 
instructions from being executed.

The patch tries to update the timer even when the current time equals 
the old expire time.

Thanks.

-Xin

--- hw/hpet.c   2010-03-01 23:58:08.815931235 -0500
+++ hw/new_hpet.c       2010-03-01 23:55:07.316704119 -0500
@@ -220,10 +220,10 @@

      if (timer_is_periodic(t) && period != 0) {
          if (t->config & HPET_TN_32BIT) {
-            while (hpet_time_after(cur_tick, t->cmp))
+            while (!hpet_time_after(t->cmp, cur_tick))
                  t->cmp = (uint32_t)(t->cmp + t->period);
          } else
-            while (hpet_time_after64(cur_tick, t->cmp))
+            while (!hpet_time_after64(t->cmp, cur_tick))
                  t->cmp += period;

          diff = hpet_calculate_diff(t, cur_tick);