From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KKBxw-0004x6-GR for qemu-devel@nongnu.org; Sat, 19 Jul 2008 08:55:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KKBxu-0004wu-3b for qemu-devel@nongnu.org; Sat, 19 Jul 2008 08:55:11 -0400 Received: from [199.232.76.173] (port=36862 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KKBxt-0004wr-Tz for qemu-devel@nongnu.org; Sat, 19 Jul 2008 08:55:09 -0400 Received: from an-out-0708.google.com ([209.85.132.245]:12327) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KKBxt-0002U7-Uu for qemu-devel@nongnu.org; Sat, 19 Jul 2008 08:55:10 -0400 Received: by an-out-0708.google.com with SMTP id d18so446973and.130 for ; Sat, 19 Jul 2008 05:55:08 -0700 (PDT) Message-ID: Date: Sat, 19 Jul 2008 14:55:08 +0200 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] Re: dyntick timer stall In-Reply-To: <4881C001.5010006@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4881C001.5010006@web.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 2008/7/19 Jan Kiszka : > 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