Try adding the noapic option to your guest kernel. I re-ran that test on kvm-62
and my VM was able to run under load for more than 3-1/2 days (the network never
locked up; I stopped the test to try other variations).
One side effect of the noapic option is that irq balancing is disabled -- all
david ahern wrote:
Try adding the noapic option to your guest kernel. I re-ran that test on
kvm-62
and my VM was able to run under load for more than 3-1/2 days (the network
never
locked up; I stopped the test to try other variations).
One side effect of the noapic option is that irq
I did not have any better luck with the e1000 or pcnet nics when running kvm-61.
I'll try again with kvm-63 and get back to you.
david
Avi Kivity wrote:
david ahern wrote:
Try adding the noapic option to your guest kernel. I re-ran that test
on kvm-62
and my VM was able to run under load
david ahern daahern at cisco.com writes:
I know this issue has been discussed on this list before, but I am still
experiencing network freezes in a guest that requires a restart to clear. When
the network freezes in the guest I no longer see the network interrupts
counter
incrementing
david ahern wrote:
Almost 7 hours and the uniprocessor case is still chugging along.
How long does it usually take to hang?
How do I go about reproducing this? apachebench (host) against httpd
(guest) doesn't seem to trigger it.
--
error compiling committee.c: too many arguments to
Usually within a few hours, sometimes within 30 minutes.
Load averages as computed by sysstat in the nightly sar files:
rxpck/s txpck/s rxbyt/s txbyt/s
eth0975.18 1188.34 82044.06 171655.38
Interrupts come in at 1830/sec for eth0, 250/sec for the timer and 20/sec or
ide0.
Avi Kivity wrote:
david ahern wrote:
Almost 7 hours and the uniprocessor case is still chugging along.
How long does it usually take to hang?
How do I go about reproducing this? apachebench (host) against httpd
(guest) doesn't seem to trigger it.
ab (on host) against httpd (on
I noted in my original post that if I increase the weight parameter in the
driver to have it pull more packets on each poll before taking it break then it
takes longer to freeze.
I have looked at a newer version of the 8139cp driver. Very few changes to the
poll function; most of them seem to be
david ahern wrote:
Usually within a few hours, sometimes within 30 minutes.
Load averages as computed by sysstat in the nightly sar files:
rxpck/s txpck/s rxbyt/s txbyt/s
eth0975.18 1188.34 82044.06 171655.38
Interrupts come in at 1830/sec for eth0, 250/sec for the
david ahern wrote:
I've run a lot more tests:
- if I remove the if (!change) return optimization from pci_set_irq the
rtl8139 nic worked fine for 16+ hours. I'm not recommending this as a fix,
just
confirming that the problem goes away.
Interesting. What can cause this to happen?
-
Avi Kivity wrote:
david ahern wrote:
I've run a lot more tests:
- if I remove the if (!change) return optimization from pci_set_irq the
rtl8139 nic worked fine for 16+ hours. I'm not recommending this as a
fix, just
confirming that the problem goes away.
Interesting. What can
david ahern wrote:
Avi Kivity wrote:
- the in-kernel ioapic is buggy and needs the extra kicking the
optimization prevents. Can be checked by re-adding the optimization to
kvm_ioapic_set_irq() (keeping it removed in qemu). If it works, the
problem is in userspace. If it fails, the problem
david ahern wrote:
david ahern wrote:
Avi Kivity wrote:
- the in-kernel ioapic is buggy and needs the extra kicking the
optimization prevents. Can be checked by re-adding the optimization to
kvm_ioapic_set_irq() (keeping it removed in qemu). If it works, the
problem is in
Almost 7 hours and the uniprocessor case is still chugging along.
david
Avi Kivity wrote:
david ahern wrote:
david ahern wrote:
Avi Kivity wrote:
- the in-kernel ioapic is buggy and needs the extra kicking the
optimization prevents. Can be checked by re-adding the optimization
david ahern wrote:
I know this issue has been discussed on this list before, but I am still
experiencing network freezes in a guest that requires a restart to clear. When
the network freezes in the guest I no longer see the network interrupts
counter
incrementing (i.e., the eth0 counter in
I've run a lot more tests:
- with the -no-kvm-irqchip option the vm eventully stops responding to network
or console,
- with the -no-kvm option the performance is so bad I cannot get our ap up and
running so the results are inconclusive,
- I've tried the e1000 and pcnet nic models and both
I know this issue has been discussed on this list before, but I am still
experiencing network freezes in a guest that requires a restart to clear. When
the network freezes in the guest I no longer see the network interrupts counter
incrementing (i.e., the eth0 counter in /proc/interrupts in the
17 matches
Mail list logo
