On Thu, Aug 01, 2013 at 07:24:13PM +0200, Jan Kiszka wrote: > On 2013-08-01 19:15, Jan Kiszka wrote: > > Hi all, > > > > I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU > > version. Under certain load, our tap backend stops reading from the char > > device, and that even if we reset the guest. The frontend device > > (pcnet32) is able to receive (can_receive would return > 0), but the > ^^^^^^^ > Yes, the pcnet lacks qemu_flush_queued_packets, like certain other NIC > models already have. We added that to pcnet_init and pcnet_start (patch > will follow), but that didn't make a difference, likely due to what I > described below.
Yes, you need to add qemu_flush_queued_packets() where the guest enables RX or marks RX descriptors free (usually by writing to a hardware register to update the RX ring index). Please also confirm that you are using -netdev tap -device pcnet32 instead of the legacy -net syntax. The reason I'm asking is because I remember the same issue with net/hub.c, which gets in the way if you use legacy syntax (see 199ee608). Hope this helps, Stefan
