From owner-freebsd-bugs Sun Dec 10 16:25:58 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA06339 for bugs-outgoing; Sun, 10 Dec 1995 16:25:58 -0800 (PST) Received: from birk04.studby.uio.no (root@birk04.studby.uio.no [129.240.214.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA06330 for ; Sun, 10 Dec 1995 16:25:54 -0800 (PST) Received: (from aagero@localhost) by birk04.studby.uio.no (8.7.3/åge1.0) id BAA00347; Mon, 11 Dec 1995 01:25:52 +0100 (MET) Date: Mon, 11 Dec 1995 01:25:52 +0100 (MET) Message-Id: <199512110025.BAA00347@birk04.studby.uio.no> From: Åge Røbekk To: freebsd-bugs@freebsd.org Subject: network driver halts on heavy network io Sender: owner-bugs@freebsd.org Precedence: bulk i have encountered a problem with the network driver in freebsd, it might be a interface card problem or a general problem in the networking code, haven't tested on any other cards than ep0, 3c509. it is hard to predict when these halts will appear, it seems like "normal" network io, with e.g. ftp works fine. but when i rcp(1) a large file, it usually halts. this is a typical scenario, i start a ping in another window to check the network and rcp a file: (delling is a machine 3 hops away, 2Mbit link.) $ ping delling PING delling.ifi.uio.no (129.240.100.4): 56 data bytes 64 bytes from 129.240.100.4: icmp_seq=0 ttl=252 time=3.459 ms [avg. ping time is ~4 ms] [Here i start an rcp of a 6MB file] 64 bytes from 129.240.100.4: icmp_seq=9 ttl=252 time=60.364 ms 64 bytes from 129.240.100.4: icmp_seq=10 ttl=252 time=73.980 ms 64 bytes from 129.240.100.4: icmp_seq=11 ttl=252 time=72.833 ms 64 bytes from 129.240.100.4: icmp_seq=12 ttl=252 time=73.689 ms 64 bytes from 129.240.100.4: icmp_seq=13 ttl=252 time=50.199 ms [10 seconds delay] ping: sendto: No buffer space available ping: wrote delling.ifi.uio.no 64 chars, ret=-1 ping: sendto: No buffer space available ping: wrote delling.ifi.uio.no 64 chars, ret=-1 ^C the average ping time when doing file transfers with ftp or sending a data stream with e.g. tcpspray is ~14 ms. i never get any halts. the reason for rcp clogging the network so bad is perhaps not so very interesting but i do not get even close with something like $ rsh < /dev/zero delling "cat >/dev/null" i looked around in the kernel sources and i found that the mbuf handling routines might be the cause, or a too small buffer somewhere. or is this a known problem with the 3c509 card? doesn't handle high speed i/o too well, they say. I'm running -CURRENT, btw :) -aage