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