From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IH9hi-0008VQ-Bq for qemu-devel@nongnu.org; Fri, 03 Aug 2007 22:49:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IH9hX-0008UI-Fl for qemu-devel@nongnu.org; Fri, 03 Aug 2007 22:49:22 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IH9hX-0008UF-9o for qemu-devel@nongnu.org; Fri, 03 Aug 2007 22:49:11 -0400 Received: from eastrmmtao105.cox.net ([68.230.240.47]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IH9hS-0001qB-Bu for qemu-devel@nongnu.org; Fri, 03 Aug 2007 22:49:09 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070804024835.UAWG9166.eastrmmtao105.cox.net@eastrmimpo01.cox.net> for ; Fri, 3 Aug 2007 22:48:35 -0400 Received: from [2002:48ce:72ec:0:20e:9bff:fe5a:426a] (unknown [IPv6:2002:48ce:72ec:0:20e:9bff:fe5a:426a]) (Authenticated sender: luke-jr) by hachi.dashjr.org (Postfix) with ESMTP id A2460960032 for ; Sat, 4 Aug 2007 02:48:34 +0000 (UTC) From: Luke -Jr Subject: Re: [Qemu-devel] Re: Network connections stalling (due to =?iso-8859-1?q?lost=09interrupts/ticks=3F?=) Date: Sat, 4 Aug 2007 02:48:31 +0000 References: <61276.4071.qm@web54105.mail.re2.yahoo.com> <46B34383.6000005@windriver.com> In-Reply-To: <46B34383.6000005@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708040248.31189.luke@dashjr.org> 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 FWIW, I suspect this problem is specific to tap+bridge+qemu combination. On Friday 03 August 2007 15:02, Jason Wessel wrote: > 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.