From owner-freebsd-current Sun Jul 14 12:26:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA01887 for current-outgoing; Sun, 14 Jul 1996 12:26:35 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA01859 for ; Sun, 14 Jul 1996 12:25:55 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA22570; Sun, 14 Jul 1996 21:20:57 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA25582; Sun, 14 Jul 1996 21:20:52 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id UAA12136; Sun, 14 Jul 1996 20:06:12 +0200 (MET DST) From: J Wunsch Message-Id: <199607141806.UAA12136@uriah.heep.sax.de> Subject: Re: ep driver now unstable .. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 14 Jul 1996 20:06:12 +0200 (MET DST) Cc: nate@mt.sri.com, mevans@candle.com (Mike Evans), imb@asstdc.com.au (michael butler) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607141629.CAA00572@walkabout.asstdc.com.au> from michael butler at "Jul 15, 96 02:29:34 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As michael butler wrote: > Whatever changed in the last day or so in the ep driver has now resulted in > the same symptoms as I had with the nep driver on my laptop. Intermittently, > it'll just stop working and I have to use "ifconfig ep0 down; ifconfig ep0 > up" to make it go again, Erm. Sh*t. :-(( Several people have reported in Usenet that their driver works much better with the flag set, and according to the author of the patch, it wasn't supposed to cause any additional harm. That's why i have asked David to bring this fix into 2.1.5 (i think it's been the last change before the tree was tagged). revision 1.50 date: 1996/07/13 10:49:53; author: davidg; state: Exp; lines: +2 -2 Enable transmit complete interrupt... (author's explaination): Bit 15 is the flag to request a transmit complete interrupt. The driver was apparently written to minimize interrupts, and if not for a 3-COM design quirk, everything would be just ducky. Prior to loading the outbound packet into the FIFO, the driver checks to see if there's enough space to contain the packet. If not, the driver requests a transmit-available interrupt when there is sufficient room. Unfortunately, the card is continuing to process the prior FIFO, and by the time the driver sets the threshold for a transmit available interrupt, the space is already available. When this occurs, the 3COM card ignores the interrupt request, and the driver is hung waiting for an interrupt that will never occur. There's probably a more elegant solution, but requesting the transmit complete interrupt was the easiest to implement. An alternative fix might be to check free FIFO space again, after requesting the transmit available interrupt, but I haven't bothered pursuing this. Since the patch, my 3C590 (PCI, same FIFO interface as 3C509) has been rock solid. Submitted by: mevans@candle.com (Mike Evans) OTOH, i've got exactly the same behaviour as you, Michael, with my 3C590, which was the main reason to hold the change back until i could get a better understanding. (Anyway, neither did it work *withou* the change.) Now, it seems that we've got two entirely different stories about this. For quite some people, setting this flag seems to be the ultimate solution, while it makes the driver instable for others. Sigh. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)