Re: [Qemu-devel] Re: Network connections stalling (due to lost interrupts/ticks?)

[Jason Wessel <jason.wessel@windriver.com>]

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 <jason.wessel@windriver.com>
> 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.
> >
> >
> >
> >  
>
>