Re: [Qemu-devel] 8139cp problems - steps to reproduce

["Igor Kovalenko" <igor.v.kovalenko@gmail.com>]

On Mon, Sep 8, 2008 at 11:57 AM, Nikola Ciprich <extmaillist@linuxbox.cz> wrote:
> Hello Avi and everybody,
>
> (and in advance, sorry for cross-posting).
>
> As it was already reported, some people (including me :)) have problems
> with network getting stuck from time to time in KVM guests.
>
> According to http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=4563&start=0&st=0&sk=t&sd=a&sid=fcf252234991e017919ca7d0eb3799a3
> the problem is maybe not KVM speciffic.
>
> I can confirm that the problem seems to be occuring after transmitting few gigabytes of data,
> so it can be simply reproduced by starting KVM guest, mounting some NFS in it, and then
> starting shell loop dd if=/mnt/nfs/bigimage.iso of=/dev/zero
> after some runs (in my case usually tens of GB), the problem occurs:
> [ 2159.614496] NETDEV WATCHDOG: eth0: transmit timed out
> [ 2159.614537] eth0: Transmit timeout, status  d   2b   15 80ff
>
> The status "  d   2b   15 80ff" is always the same, on all testing machines
> which according to 8139cp.c means
>
> Command register=d
receiver enabled, transmitter enabled, buffer empty
> C+ command register=2b
C+ mode receiver enabled, transmitter enabled, receive checksum
offloading enabled, unsupported pci multiple r/w enabled
> Interrupt status=15
receiver overflow! tx ok,rx ok
> Interrupt mask=80ff

> So does somebody have an idea on where the problem could be? Of course I'll be glad to (try) to help
> debugging...

If it is not guest networking... please check if rx missed is not zero
(no idea how, probably with ethtool or with netstat -i)
You can also try enabling overflow debugging statements near lines where

s->IntrStatus |= RxOverflow

... there are 3 of these. There is quite low probability that rtl8139
should not set RxOK if it has overflow, or that guest driver does not
expect it in that combination (which seems to be rather valid in case
card received full set of descriptors space of data and missed last
packet before driver was able to read and vacate some buffers.)

-- 
Kind regards,
Igor V. Kovalenko