Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!umd5!magorian
From: magorian@umd5.umd.edu (Dan Magorian)
Newsgroups: comp.unix.aux
Subject: Re: problems with ethernet interface
Message-ID: <4115@umd5.umd.edu>
Date: 8 Oct 88 00:29:28 GMT
References: <1959@spdcc.COM> <12275@steinmetz.ge.com> <7247@bloom-beacon.MIT.EDU> <586@draken.nada.kth.se>
Reply-To: magorian@umd5.umd.edu (Dan Magorian)
Organization: University of Maryland, College Park
Lines: 36

In article <586@draken.nada.kth.se> ragge@nada.kth.se (Ragnar Sundblad) writes:
>In article <7247@bloom-beacon.MIT.EDU> dyer@arktouros.MIT.EDU (Steve Dyer) writes:
>>In my experience, "ifconfig ae0 up" was a no-op.  Programs complained
>>"network down" anyway.  Someone else placed the line
>>ifconfig ae0 down; ifconfig ae0 up
>....
>>Steve Dyer
>
>That's probably one of the bugs in the National DP8390 (described in
>DP8390 Tech Update, problem #3).
>
>"
>	Problem 3
>	Suspended Operation After Transmission: If Collision (COL) is
>	asserted during the transmission of the last byte, the NIC will
>	suspend all operations. This problem is manifested when the
>	Command Register continually reads 26H.
>	The NIC must be hardware reset to resume operation.
>
>	NOTE: In a properly operating IEEE 802.3 network, a collision will
>	never occur during the last byte of transmission.
>"
>Note: I don't THINK that the EtherTalk card exchange some months ago
>solved this problem.

Does anyone have some details on what the swapped Rev I or J cards patched?  We
had the earlier Rev E cards, and were experiencing the problems people are
describing (there was even one Rev C card with the earlier version of the NIC).
Swapping them out reduced lockups considerably.  Basically, it's the same card 
reworked with 4 additional jumpers (there were already 2).  On the MacOS side,
the reworks were shipped with the same 1.1 driver, but a 2.0 version later
appeared.  Comments?

Dan Magorian
Computer Science Center
University of Maryland