Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

tlug: NE2000 cards



On Wed, 31 Mar 1999, Stephen J. Turnbull wrote:

>     ash> You can get get rid of the '(aka "Satan spawn")' bit.
> 
> Yes.  That's code for "Chris was here."  Doesn't mean anything to the
> kernel.

*snort* That one wasn't me -- must be someone else who shares my (dim)
view of Novell Eagle workalike cards.

I've said many times that ne2k cards are absolute crap, but I've never
really explained why.  For those who are curious:

The Novell Eagle 1000/2000 card is built around the DP8390 and DP8391
ethernet chips, a bit of RAM for buffering (typically between 16 to 64Kb),
and some glue parts.  It is an absolute bare-bones implementation --
essentially Novell took the example configuration from the 8390
datasheet and threw it together.

The 8390 is designed for DMA operation -- the RAM is used as the buffer.
For transmission, the CPU writes the packet to the RAM and then tells the
8390 to transmit.  Packet reception works in a similar manner.

The engineers at Novell apparently decided that DMA was unnecessary, as
they did not couple the buffer RAM to the system bus.  So, in order to
store or retrieve data to or from the RAM, the 8390 has to be used in
something called remote DMA mode -- essentially programmed i/o[1], sending
each byte (or word) one-at-a-time through the data port. Thereby doing
nasty things to performance[2].

If that wasn't bad enough, many runs of the 8390 (and clones derived from
its silicon) had a buffer bug that _required_ a dummy read from the buffer
RAM for every write to the buffer RAM.

The _single_ good thing about the Novell board was that it was cheap.
Cheap enough to clone.  They didn't perform very well (which ensured
the survival of 3com), but who really cares about dropped packets with a
US$150 card?  Once machines became fast enough to slam the data port
without generating timeouts, the Novell boards saturated the market.

-- Chris

[1] Some clone cards rectified this design flaw.  Unfortunately, there is
    _no_ way to determine where in the upper 384Kb this RAM sits without
    opening up the box and looking at the jumper settings[3], so it is not
    used in the linux driver.

[2] Interestingly enough, although the PCI ne2k clones can advertise their
    buffer RAM location via the PCI spec (neatly avoiding the need to
    probe), they often lie.  PIO to a PCI card ... *shudder*

[3] ... unless one writes a card-specific driver.  Ugh.

-------------------------------------------------------------------
Next Technical Meeting: April 10 (Sat), 12:30   place: Temple Univ.
*** featuring: LabView and UDB/DB2 for Linux
Next Nomikai: May 21 (Fri), 19:30    Tengu TokyoEkiMae 03-3275-3691
-------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links