[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: Network connections stalling (due to lost interrupt
Re: [Qemu-devel] Re: Network connections stalling (due to lost interrupts/ticks?)
Fri, 03 Aug 2007 10:02:27 -0500
Thunderbird 18.104.22.168 (Windows/20070509)
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.
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
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.
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
>> 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.