Re: [kvm-devel] still seeing network freezes with rtl8139 nic

[david a. <da...@ci...>]

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 showed the network lockup;
with the ne2k_pci nic I did not see dropped packets and the network never locked
up in 12+ hours, but system CPU time was 10% higher than when the rtl8139 nic
was working

- 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.

- I tried adding a thread mutex to the rtl8139 device model around accesses to
the RTL8139State data, but the network still locked up.

david


Avi Kivity wrote:
> 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 /proc/interrupts in the guest). Using
>> the crash utility, I verified that the interrupt is still enabled on the guest
>> side and that no interrupts are pending. This suggests that the interrupts are
>> not getting delivered to the VM.
>>
>>   
> 
> [...]
> 
>> I am continuing to look into the irq processing on the kvm/qemu side. I'd like
>> to know if anyone has suggestions on what to look at. This is my first foray
>> into the kvm and qemu code, and it's a lot to take in all at once.
>>
>>   
> 
> Standard procedure is to run with -no-kvm and -no-kvm-irqchip, to see if 
> the problem is in qemu proper, the in-kernel irq handling, or the rest 
> of kvm.
>