From owner-freebsd-hackers Mon Mar 3 10:24:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA18380 for hackers-outgoing; Mon, 3 Mar 1997 10:24:05 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA18368 for ; Mon, 3 Mar 1997 10:24:02 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08263; Mon, 3 Mar 1997 11:18:42 -0700 From: Terry Lambert Message-Id: <199703031818.LAA08263@phaeton.artisoft.com> Subject: Re: [driver testing] Odd network behaviour? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 3 Mar 1997 11:18:42 -0700 (MST) Cc: hackers@FreeBSD.ORG, jrb@cs.pdx.edu In-Reply-To: <199703021423.AAA20864@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 3, 97 00:53:40 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Julian, Garrett, as intimates of the 82586 club, I'd really appreciate > any ideas you might have here... > > I've been pounding on Jim B's Wavelan driver for a while and driving > myself slowly nuts trying to work out some odd behaviour. I've come > to the point where I think some external input would be helpful. > > A shred of background; the Wavelan cards use intel i82586's, and > generally look like ethernet cards from the programmer's point of view > (modulo some extra bits). > > The behaviour I'm seeing is basically that when a 'fast' (slow > Pentium) host sends to a 'slow' (486/66) host, the send randomly > pauses. I've just been using ftp for this testing; with hashmark > printing on it's easy to see the output pause, often for a second > or longer. > > This problem is seperate from the one where the card occasionally > loses transmit interrupts, but may (?) be related. I seriously doubt you are having this problem, but... During early testing of Garrett's 82586 driver in AT&T 6386/33E WGS systems (using Intel Plato motherboards, I believe), the copy of data from the card to host memory could fail, and the packet would be lost in the higher protocol layers (ie: it was bad data, so it was right to lose it). On the 6386/25's, the driver was reliable enough that we never pursue the problem with vigor. Kurt Mahon, who wrote the driver for the 82586 for USL, claimed that the USL driver copied the data twice; apparently, the interrupt was issued when data was available, rather than when it had made it into card memory? The second copy worked because the first copy provided sufficient delay, scaled to the size of the transfer. I never had a chance to verify Kurt's claims, since I was happily running 368BSD on the 6386/25's and didn't want to screw with success. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.