From owner-freebsd-hackers Tue Feb 18 03:52:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA29224 for hackers-outgoing; Tue, 18 Feb 1997 03:52:48 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA29218 for ; Tue, 18 Feb 1997 03:52:39 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA06269; Tue, 18 Feb 1997 12:03:01 +0100 From: Luigi Rizzo Message-Id: <199702181103.MAA06269@labinfo.iet.unipi.it> Subject: 21140-AC (if_de.c) news To: hackers@freebsd.org Date: Tue, 18 Feb 1997 12:03:01 +0100 (MET) Cc: matt@3am-software.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A few more data points about the 21140A/21140-AC (if_de.c) driver I worked on 2.1.6 using both the stock driver ("old") and the latest netbsd driver ("new"), using a 100Mb/s net and diskless clients. The old driver works fine with 21140-AB board, but does not recognize the 21140-AC correctly. The new driver works better with the 21104-AC but has some bugs: BUG #1: The new driver fails to initialize the media properly on the 21140-AB (aka 21140). In the new driver, media initialization is delayed and occurs (I think) at the first transmission attempt. The fix is unknown (to me). As a consequence I could not use the new driver with the 21140-AB BUG #2: The new driver fails to deal with too many back-to-back packets. The first symptom for me was that NFS-mounting with blocksize of 8K would fail, and it only seems to work with blocksize of 1K up to about 1500. Note, in the latter case the packet is fragmented in two pieces. I tried to ping the diskless client with blocksize of up to 8100 bytes, while running tcpdump on the sender, and it seems to respond correctly. HOWEVER, as soon as I ran tcpdump on the client, pinging with more than some 4100 bytes caused failure to reply: tcpdump on the client shows the packets coming in, but no reply going out. I believe this is a symptom of lack of buffers somewhere. Kind of strange, since the relevant parameters (TULIP_RXDESCS etc.) appear to be unchanged. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________