From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IGyg7-0001hh-4H for qemu-devel@nongnu.org; Fri, 03 Aug 2007 11:02:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IGyfx-0001bL-Qp for qemu-devel@nongnu.org; Fri, 03 Aug 2007 11:02:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGyfx-0001bD-IV for qemu-devel@nongnu.org; Fri, 03 Aug 2007 11:02:49 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IGyfu-00018O-Mg for qemu-devel@nongnu.org; Fri, 03 Aug 2007 11:02:48 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l73F2Si2003412 for ; Fri, 3 Aug 2007 08:02:28 -0700 (PDT) Message-ID: <46B34383.6000005@windriver.com> Date: Fri, 03 Aug 2007 10:02:27 -0500 From: Jason Wessel MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Network connections stalling (due to lost interrupts/ticks?) References: <61276.4071.qm@web54105.mail.re2.yahoo.com> In-Reply-To: <61276.4071.qm@web54105.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 The RTC message has nothing to do with the interrupt controller load. The patch I mentioned was aimed at stability/bug fix. Nothing to do with performance what so ever. The simple test that you can usually break the qemu interrupt controller with is to do a "ping -f" to the target when using TAP. Then just run some other processes on the target or try to use the network with telnet or write to the disk with echo file > blah ; sync... It usually doesn't last too long. It is the "ping -f" that will keep the interrupt load at the max. Jason. n schembr wrote: > I'm seeing the same rtc error but my systems are not hanging. I can > still get to them and they seem to handle a good load from time to > time, 4 running proc. > > Is this a stability or performance issue? > > If it is a stability issue how do I test it? > > ----- Original Message ---- > From: Jason Wessel > To: charles@dyfis.net; qemu-devel@nongnu.org > Sent: Friday, August 3, 2007 8:18:50 AM > Subject: Re: [Qemu-devel] Re: Network connections stalling (due to > lost interrupts/ticks?) > > Charles, > > Are you willing to try an experimental patch? > > Perhaps you could try the attached patch and post back if it happens to > solve your problem. There is most definitely a problem where qemu can > get hung up indefinitely after an "interrupt storm". I had not ever > submitted it because there is no clean way to do this via the opaque > information that is passed around. It seems wrong to have to make the > ioapic a global. If this does fix the problem perhaps someone will > decide to fix this up in a cleaner fashion via the opaque structures. > > Jason. > > Charles Duffy wrote: > > Charles Duffy wrote: > > > >> There's a warning on startup that the system can't set a 1024Hz timer, > >> which persists even after I set /proc/sys/dev/rtc/max-user-freq to > 1024, > >> and I occasionally get warnings at runtime ("Your time source seems to > >> be instable or some driver is hogging interrupts"). > >> > > > > This was happening because my host kernel was compiled with > > CONFIG_HPET_RTC_IRQ=y. I've disabled this option, recompiled and > > rebooted, and it resolved the RTC warning (and apparently, the unstable > > time source messages) -- but my network connections are still stalling. > > > > > > > > > >