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

[Luke -Jr]

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 <address@hidden>
> > To: address@hidden; address@hidden
> > 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.