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

["andrzej zaborowski" <balrogg@gmail.com>]

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