Am 12.06.2012 15:32, schrieb Stefano Stabellini: > On Tue, 12 Jun 2012, Andreas Färber wrote: >> Am 12.06.2012 14:37, schrieb Stefano Stabellini: >>> On Tue, 12 Jun 2012, Andreas Färber wrote: >>>> Am 12.06.2012 10:24, schrieb Andreas Färber: >>>>> Am 29.05.2012 15:35, schrieb Stefano Stabellini: >>>>> The check-qtest-i386 qemu-system-i386 process now hangs at ~98% CPU, >>> >>> Does this mean that increasing the timeout caused a busy loop somewhere >>> in the test? But if we set the max timeout value to INT32_MAX doesn't >>> happen? >> >> Note that this is solely about qtest, which I never saw working >> (probably didn't try before). Regular system emulation seemed to work >> just fine. >> >> Where would I try INT32_MAX for comparison? > > the following patch (to be applied on top of the other one) should do the > trick: > > diff --git a/qemu-timer.c b/qemu-timer.c > index d37a978..4fd3e1c 100644 > --- a/qemu-timer.c > +++ b/qemu-timer.c > @@ -85,7 +85,7 @@ static bool qemu_timer_expired_ns(QEMUTimer *timer_head, > int64_t current_time) > > static int64_t qemu_next_alarm_deadline(void) > { > - int64_t delta = INT64_MAX; > + int64_t delta = INT32_MAX; > int64_t rtdelta; > > if (!use_icount && vm_clock->enabled && vm_clock->active_timers) { > @@ -113,7 +113,7 @@ static int64_t qemu_next_alarm_deadline(void) > static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t) > { > int64_t nearest_delta_ns = qemu_next_alarm_deadline(); > - if (nearest_delta_ns < INT64_MAX) { > + if (nearest_delta_ns < INT32_MAX) { > t->rearm(t, nearest_delta_ns); > } > }
Seems I forgot to reply that this INT32_MAX diff didn't make a change. However, Anthony's "qtest: fix infinite loop when QEMU aborts abruptly" patch that got committed combined with the original INT64_MAX patch here makes qtest finally work on Darwin! Thanks to everyone assisting, Andreas