[Qemu-devel] dyntick timer stall

[Qemu-devel] dyntick timer stall

[andrzej zaborowski]

With dyntick enabled I see qemu-system-arm lock up after a while (stay
in code_gen_buffer) due to no more signals reaching qemu. This happens
after a couple of seconds of constantly rearming the host timer with
250usec period (MIN_TIMER_REARM_US).

The offender is audio which, if the QEMU_AUDIO_TIMER_PERIOD env
variable is unset, requests audio_timer() be called every 1 vm_clock
tick, resulting in a negative period in qemu_next_deadline_dyntick
which is then trimmed to MIN_TIMER_REARM_US. It seems to be a problem
in host's timer_settime() though.

timer_settime is constantly called with 250usec as parameter without
the timeout having passed, and then after it's called for the last
time, no signal arrives in the main thread for at least a couple of
minutes. The host is x86_64 Linux 2.6, what may be causing this and
what may be a fix?

Regards

[Qemu-devel] Re: dyntick timer stall

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

andrzej zaborowski wrote:
> With dyntick enabled I see qemu-system-arm lock up after a while (stay
> in code_gen_buffer) due to no more signals reaching qemu. This happens
> after a couple of seconds of constantly rearming the host timer with
> 250usec period (MIN_TIMER_REARM_US).
> 
> The offender is audio which, if the QEMU_AUDIO_TIMER_PERIOD env
> variable is unset, requests audio_timer() be called every 1 vm_clock
> tick, resulting in a negative period in qemu_next_deadline_dyntick
> which is then trimmed to MIN_TIMER_REARM_US. It seems to be a problem
> in host's timer_settime() though.
> 
> timer_settime is constantly called with 250usec as parameter without
> the timeout having passed, and then after it's called for the last
> time, no signal arrives in the main thread for at least a couple of
> minutes. The host is x86_64 Linux 2.6, what may be causing this and
> what may be a fix?

Cannot confirm: I'm running the Musicpal with SVN head on OpenSuse 11.0
(2.6.25.9, SMP) without problems. And when I attach strace to that
process, I see continuous dumps of

timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---

Can you capture the strace of qemu, or does the issue flee in that case?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: dyntick timer stall

[andrzej zaborowski]

2008/7/19 Jan Kiszka <jan.kiszka@web.de>:
> andrzej zaborowski wrote:
>> With dyntick enabled I see qemu-system-arm lock up after a while (stay
>> in code_gen_buffer) due to no more signals reaching qemu. This happens
>> after a couple of seconds of constantly rearming the host timer with
>> 250usec period (MIN_TIMER_REARM_US).
>>
>> The offender is audio which, if the QEMU_AUDIO_TIMER_PERIOD env
>> variable is unset, requests audio_timer() be called every 1 vm_clock
>> tick, resulting in a negative period in qemu_next_deadline_dyntick
>> which is then trimmed to MIN_TIMER_REARM_US. It seems to be a problem
>> in host's timer_settime() though.
>>
>> timer_settime is constantly called with 250usec as parameter without
>> the timeout having passed, and then after it's called for the last
>> time, no signal arrives in the main thread for at least a couple of
>> minutes. The host is x86_64 Linux 2.6, what may be causing this and
>> what may be a fix?
>
> Cannot confirm: I'm running the Musicpal with SVN head on OpenSuse 11.0
> (2.6.25.9, SMP) without problems. And when I attach strace to that
> process, I see continuous dumps of

Uh, you're right, the signal is there and I wasn't looking at the
right function.  The signal handler doesn't manage to cause an exit
from the cpu loop, looks very similar to an issue that got fixed
before TCG introduction.

>
> timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0
> --- SIGALRM (Alarm clock) @ 0 (0) ---
>
> Can you capture the strace of qemu, or does the issue flee in that case?

Yes, I'm now seeing --- SIGALRM (Alarm clock) @ 0 (0) --- as the last
line from strace and later only some serial port writes before stall.

Regards