On Thu, 2009-10-29 at 20:00 +0800, Scott Tsai wrote: > Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009: > > Assuming this is something like the virtio-net in 2.6.26, there was no > > receivable buffers support so (as Scott points out) it must be that > > we've read a packet from the tap device which is >1514 bytes (or >1524 > > bytes with IFF_VNET_HDR) but the guest has not supplied buffers which > > are large enough to take it > > > One thing to check is that the tap device is being initialized by > > qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO > > should not be enabled, because the guest cannot handle large GSO packets > > > Another possibility is that the MTU on the bridge in the host is too > > large and that's what's causing the large packets to be sent > > Using Dustin's image, I see: > virtio_net_set_features(features: 0x00000930) > tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1) > being called and get an mtu of 1500 on virbr0 using his birdge.sh script. > > virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 10 'virtio_net_hdr') > and the guest only had 1524 bytes of space in its input descriptors. > > BTW, I can also reproduce this running Dustin's image inside Fedora 11's qemu-0.10.6-9.fc11.x86_64. > > The patch I posted earlier actually only applies to the 0.10 branch, here's a patch that compiles for 0.11: Hi Scott, Thanks for this. Testing this, kvm doesn't crash. And the guest has working network connectivity, until I saturate the network connection with nc. At that point, the guest loses network connectivity all together. So the fix is not quite ideal, yet. :-Dustin
Attachment:
signature.asc
Description: This is a digitally signed message part
