From owner-freebsd-bugs Sat Jun 8 04:50:08 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA04622 for bugs-outgoing; Sat, 8 Jun 1996 04:50:08 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA04602; Sat, 8 Jun 1996 04:50:03 -0700 (PDT) Resent-Date: Sat, 8 Jun 1996 04:50:03 -0700 (PDT) Resent-Message-Id: <199606081150.EAA04602@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, tk@pars.sics.se Received: from pars.sics.se (pars.sics.se [192.16.123.61]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA03120 for ; Sat, 8 Jun 1996 04:45:52 -0700 (PDT) Received: (from tk@localhost) by pars.sics.se (8.6.12/8.6.12) id NAA04039; Sat, 8 Jun 1996 13:46:16 +0200 Message-Id: <199606081146.NAA04039@pars.sics.se> Date: Sat, 8 Jun 1996 13:46:16 +0200 From: Torsten Koehler Reply-To: tk@pars.sics.se To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/1302: 3COM 3c590 can't receive packets Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1302 >Category: kern >Synopsis: 3COM 3c590 can't receive packets >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jun 8 04:50:02 PDT 1996 >Last-Modified: >Originator: Torsten Koehler >Organization: SICS >Release: FreeBSD 2.2-960501-SNAP i386 >Environment: 3Com 3c590 EtherLink III PCI rev 0, Pentium PC. >Description: With increasing packet sizes the rate of received packet goes to zero. Packet sizes around 100 bytes are ok, at 250 bytes only every 5th packet gets received, at 500 bytes every 20th and so on. >How-To-Repeat: ping -s 100 host # ok ping -s 1000 host # no response >Fix: It looks like that the calculation of RX_EARLY_THRESH in pci/if_vx.c goes wrong. One hack is to disable all SET_RX_EARLY_THRESH commands. After disabling SET_RX_EARLY_THRESH the card is able to receive packets of all sizes, but with a high input error rate. Which isn't really nice either, but 15% packet loss is still better than receiving every 15th packet ... Also, not using RX_EARLY interrupts might increase the change of locking the device driver in IFF_OACTIVE state due to lost RX_COMPLETE interrupts (the LINUX driver mentions that problem). Does somebody has a hardware spec for the 3COM 3c590 ? *** if_vx.c Fri Jun 7 23:57:42 1996 --- ../if_vx.c.test Sat Jun 8 13:07:36 1996 *************** *** 29,34 **** --- 29,36 ---- * */ + #define VX_NO_RX_EARLY + /* * Created from if_ep.c driver by Fred Gray (fgray@rice.edu) to support * the 3c590 family. *************** *** 440,446 **** --- 442,450 ---- m_freem(sc->top); sc->top = sc->mcur = 0; } + #ifndef VX_NO_RX_EARLY outw(BASE + VX_COMMAND, SET_RX_EARLY_THRESH | sc->rx_early_thresh); + #endif /* * These clever computations look very interesting *************** *** 847,854 **** --- 851,860 ---- if (delta < MIN_RX_EARLY_THRESHL) delta = MIN_RX_EARLY_THRESHL; + #ifndef VX_NO_RX_EARLY outw(BASE + VX_COMMAND, SET_RX_EARLY_THRESH | (sc->rx_early_thresh = delta)); + #endif return; } all_pkt: *************** *** 897,904 **** --- 903,912 ---- #ifdef VX_LOCAL_STATS sc->rx_bpf_disc++; #endif + #ifndef VX_NO_RX_EARLY while (inw(BASE + VX_STATUS) & S_COMMAND_IN_PROGRESS); outw(BASE + VX_COMMAND, SET_RX_EARLY_THRESH | delta); + #endif return; } } *************** *** 910,917 **** --- 918,927 ---- if (!sc->mb[sc->next_mb]) vxmbuffill((caddr_t) sc, 0); sc->top = 0; + #ifndef VX_NO_RX_EARLY while (inw(BASE + VX_STATUS) & S_COMMAND_IN_PROGRESS); outw(BASE + VX_COMMAND, SET_RX_EARLY_THRESH | delta); + #endif return; out: *************** *** 928,936 **** --- 938,948 ---- delta = MIN_RX_EARLY_THRESHF; vx_fset(F_RX_FIRST); vx_frst(F_RX_TRAILER); + #ifndef VX_NO_RX_EARLY while (inw(BASE + VX_STATUS) & S_COMMAND_IN_PROGRESS); outw(BASE + VX_COMMAND, SET_RX_EARLY_THRESH | (sc->rx_early_thresh = delta)); + #endif } /* >Audit-Trail: >Unformatted: Torsten Koehler