I noticed on the weekend our offsite rsync virtually stopped. Upon investigation I found that I had started a vbox guest on the machine and this caused the rsync ssh flow to virtually stall. Stopping and restart the rsync process fixed the issue. Its easy to re-create. start a large tcp stream operation eg. pipe an ssh stream to another machine fire up a FreeBSD guest in vbox where the guest bridges the nic. The ssh stream will virtually stall. Another way to fix the issue is to shutdown the vbox guest. The traffic speeds will resume to normal. 1 37 0xffffffff80200000 1141750 kernel 2 1 0xffffffff81342000 4a10 coretemp.ko 3 1 0xffffffff81411000 169e64 zfs.ko 4 1 0xffffffff8157b000 397f opensolaris.ko 5 1 0xffffffff8157f000 3582 ums.ko 6 1 0xffffffff81583000 2b5c uhid.ko 7 1 0xffffffff81586000 176f accf_http.ko 8 1 0xffffffff81588000 cbf accf_data.ko 9 1 0xffffffff81589000 2e57 aesni.ko 10 1 0xffffffff8158c000 1f56c crypto.ko 11 3 0xffffffff815ac000 32710 vboxdrv.ko 12 1 0xffffffff815df000 3ec0 vboxnetadp.ko 13 1 0xffffffff815e3000 28c0 vboxnetflt.ko 14 2 0xffffffff815e6000 b998 netgraph.ko 15 1 0xffffffff815f2000 40b2 ng_ether.ko Another way to do it is to start the ssh stream, pause and then unpause the guest. When the guest restarts, the ssh stream will drop to almost zero. The bug seems to have something to do with tso. If I disable tso on the NIC, this behaviour does not happen. Intel MB. dmesg, dmidecode etc attached # VBoxManage --version 4.3.12_OSEr93733
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
(In reply to mike from comment #0) Are you seeing issues here with recent FreeBSD versions?