From: "Andreas Färber" <andreas.faerber@web.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Stefan Weil <sw@weilnetz.de>,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: [Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
Date: Tue, 12 Jun 2012 10:24:46 +0200 [thread overview]
Message-ID: <4FD6FCCE.8080807@web.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1205291426350.26786@kaball-desktop>
Am 29.05.2012 15:35, schrieb Stefano Stabellini:
> qemu_rearm_alarm_timer partially duplicates the code in
> qemu_next_alarm_deadline to figure out if it needs to rearm the timer.
> If it calls qemu_next_alarm_deadline, it always rearms the timer even if
> the next deadline is INT64_MAX.
>
> This patch simplifies the behavior of qemu_rearm_alarm_timer and removes
> the duplicated code, always calling qemu_next_alarm_deadline and only
> rearming the timer if the deadline is less than INT64_MAX.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Andreas Färber <andreas.faerber@web.de>
This resolves the assertion I had previously reported.
The check-qtest-i386 qemu-system-i386 process now hangs at ~98% CPU,
just as with my INT64_MAX hack before. How would I best debug this qtest
scenario, and what should I be looking for? Since my 1.1 patch this is
no longer going through any Cocoa event handling, so the only causes I
can think of are timers and signals...
Andreas
next prev parent reply other threads:[~2012-06-12 8:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.DEB.2.00.1205291426350.26786@kaball-desktop>
[not found] ` <4FC502CE.20509@weilnetz.de>
[not found] ` <4FC53AAD.3010201@redhat.com>
[not found] ` <4FC5888D.5080902@codemonkey.ws>
2012-06-11 9:55 ` [Qemu-devel] [PATCH 1.1?] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX Stefano Stabellini
2012-06-11 10:12 ` Andreas Färber
2012-06-12 8:24 ` Andreas Färber [this message]
2012-06-12 8:35 ` [Qemu-devel] " Andreas Färber
2012-06-12 12:37 ` Stefano Stabellini
2012-06-12 12:58 ` Andreas Färber
2012-06-12 13:32 ` Stefano Stabellini
2012-07-27 17:00 ` Andreas Färber
2012-08-09 15:35 ` [Qemu-devel] [Qemu-devel for-1.2] " Andreas Färber
2012-08-09 19:58 ` Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD6FCCE.8080807@web.de \
--to=andreas.faerber@web.de \
--cc=anthony@codemonkey.ws \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.