[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qtest: setitimer() failures on Darwin and illumos
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] qtest: setitimer() failures on Darwin and illumos |
Date: |
Tue, 29 May 2012 14:21:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
Il 29/05/2012 14:01, Stefano Stabellini ha scritto:
> On Mon, 28 May 2012, Paolo Bonzini wrote:
>> Il 28/05/2012 21:40, Andreas Färber ha scritto:
>>> I'm seeing qemu-timer.c:unix_rearm_timer()'s setitimer() abort with
>>> EINVAL during `make check` on both platforms. The value of
>>> nearest_delta_ns appears to be INT64_MAX. Is this expected? Is it
>>> possible that this value is too large for it_value on some platforms?
>>> Apple's man page mentions that as possible reason for EINVAL but doesn't
>>> describe how to obtain such an upper value, nor of course where in the
>>> QEMU code base we would need to make adaptions. ;)
>>>
>>> Any suggestions?
>>
>> You shouldn't call the rearm function at all if you get INT64_MAX. This
>> applies to all timers.
>
> Yep. In fact qemu_rearm_alarm_timer returns immediately if none of the
> clocks have active timers.
> However if at least one of them does, we call qemu_next_alarm_deadline
> (that potentially can return INT64_MAX) and then rearm.
>
> So for example if the clock that has active timers is disabled (I don't
> if it is possible to get in this state), qemu_next_alarm_deadline would
> return INT64_MAX.
> I think we should make the appended change in order to make the code
> more reliable.
Yes, that makes sense, can you submit it with SoB?
Paolo