From owner-FreeBSD-users-jp@jp.freebsd.org  Tue Jul 16 15:21:44 1996
Received: by mail.jp.freebsd.org (8.7.3+2.6Wbeta5/8.7.3) id OAA01024
	Tue, 16 Jul 1996 14:46:15 +0900 (JST)
Received: by mail.jp.freebsd.org (8.7.3+2.6Wbeta5/8.7.3) with ESMTP id OAA01019
	for <FreeBSD-users-jp@jp.freebsd.org>; Tue, 16 Jul 1996 14:46:06 +0900 (JST)
Received: by uno.sat.t.u-tokyo.ac.jp (8.7.3+2.6Wbeta5/8.7.3) with ESMTP
	id OAA12708; Tue, 16 Jul 1996 14:46:06 +0900 (JST)
To: FreeBSD-users-jp@jp.freebsd.org
X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Date: Tue, 16 Jul 1996 14:46:05 +0900
Message-ID: <12706.837495965@sat.t.u-tokyo.ac.jp>
From: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
Reply-To: FreeBSD-users-jp@jp.freebsd.org
X-Distribute: distribute [version 2.1 (Alpha) patchlevel=19]
X-Sequence: FreeBSD-users-jp 3054
Subject: [FreeBSD-users-jp 3054] Re: FreeBSD 2.1.5-RELEASE re-rolling ?!
Errors-To: owner-FreeBSD-users-jp@jp.freebsd.org
Sender: owner-FreeBSD-users-jp@jp.freebsd.org

$B2<@n!wElBg$G$9!%(B

tnomura> $BLnB<!w7DBg$G$9!#(B
tnomura> 
tnomura>   $B<!$N$h$&$J%a!<%k$,Mh$^$7$?!#?7$7$$%+!<%M%k$G(B ep0(on EtherLink III)$B$r;HMQ(B
tnomura> $B$7$F$$$k$H!"FMA3%M%C%H%o!<%/$,;H$($J$/$J$k$H$$$&%H%i%V%k$r7P83$7$F$*$j!"4X(B
tnomura> $BO"$"$k$N$+$b$7$l$^$;$s!#$5$C$-!"(Bftp.freebsd.org $B$r8+$?$i!"(B

$B;d$bF|MK$"$?$j$N(Bstable$B$G7P83$7$^$7$?!%(B

# ifconfig ep0 up

$B$H$d$k$HI|3h$9$k$N$G$9$,(B ^_^;

/sys/i386/isa/if_ep.c $B$N0J2<$NJQ99$,0-$$$i$7$/$F!$(B
revision 1.49$B$r;H$C$?$H$3$mLdBj$,$J$/$J$j$^$7$?!%(B

/\ Hidetoshi Shimokawa
\/  simokawa@sat.t.u-tokyo.ac.jp
PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp


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)
