From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KK8V9-0002I4-D6
	for qemu-devel@nongnu.org; Sat, 19 Jul 2008 05:13:15 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KK8V6-0002Gt-90
	for qemu-devel@nongnu.org; Sat, 19 Jul 2008 05:13:13 -0400
Received: from [199.232.76.173] (port=57266 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KK8V3-0002Ga-UP
	for qemu-devel@nongnu.org; Sat, 19 Jul 2008 05:13:10 -0400
Received: from an-out-0708.google.com ([209.85.132.242]:52202)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <balrogg@gmail.com>) id 1KK8V3-000737-K1
	for qemu-devel@nongnu.org; Sat, 19 Jul 2008 05:13:09 -0400
Received: by an-out-0708.google.com with SMTP id d18so434476and.130
	for <qemu-devel@nongnu.org>; Sat, 19 Jul 2008 02:13:08 -0700 (PDT)
Message-ID: <fb249edb0807190213t4ae30c60yf5c2b23377f43c11@mail.gmail.com>
Date: Sat, 19 Jul 2008 11:13:08 +0200
From: "andrzej zaborowski" <balrogg@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [Qemu-devel] dyntick timer stall
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel mailing list <qemu-devel@nongnu.org>

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