[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next d
Re: [Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
Tue, 12 Jun 2012 10:24:46 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0
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 <address@hidden>
Tested-by: Andreas Färber <address@hidden>
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...
- Re: [Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX,
Andreas Färber <=