🚀 go-pugleaf

Archive-Name: linux/howto/ethernet/part1
Last-modified: 19 Nov 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The `Linux Ethernet HOWTO' is posted automatically by the
*** Linux HOWTO coordinator, Greg Hankins <gregh@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Paul Gortmaker <Paul.Gortmaker@anu.edu.au>.

- --- BEGIN Linux Ethernet HOWTO part 1/3 ---

  Linux Ethernet-Howto
  Paul Gortmaker, Editor.
  v2.5, 18 November 1995

  This is the Ethernet-Howto, which is a compilation of information
  about which ethernet devices can be used for Linux, and how to set
  them up. It hopefully answers all the frequently asked questions about
  using ethernet cards with Linux. Note that this Howto is focused on
  the hardware and low level driver aspect of the ethernet cards, and
  does not cover the software end of things. See the NET2-Howto for that
  stuff.

  1.  Introduction


  The Ethernet-Howto covers what cards you should and shouldn't buy; how
  to set them up, how to run more than one, and other common problems
  and questions. It contains detailed information on the current level
  of support for all of the most common ethernet cards available.  It
  does not cover the software end of things, as that is covered in the
  NET-2 Howto. Also note that general non-Linux specific questions about
  Ethernet are not (or at least they should not be) answered here. For
  those types of questions, see the excellent amount of information in
  the comp.dcom.lans.ethernet FAQ. You can FTP it from dorm.rutgers.edu
  in the directory /pub/novell/info_and_docs/

  This present revision covers distribution kernels up to and including
  v1.2.13. Information pertaining to development kernels up to version
  1.3.42 is also documented.

  The Ethernet-Howto is edited and maintained by:

       Paul Gortmaker, Paul.Gortmaker@anu.edu.au


  The primary source of the information for the initial Ethernet-Howto
  was from:

       Donald J. Becker, becker@cesdis.gsfc.nasa.gov


  who we have to thank for writing the vast majority of ethernet card
  drivers that are presently available for Linux. He also is the
  original author of the NFS server too. Thanks Donald! We owe ya one!
  :-)

  Net-surfers may wish to check out the following URL:

  Donald Becker
  <http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html>


  1.1.  New Versions of this Document


  New versions of this document can be retrieved via anonymous FTP from:

  Sunsite HOWTO Archive <ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/>

  and various Linux ftp mirror sites. Updates will be made as new
  information and/or drivers becomes available. If this copy that you
  are reading is more than 4 months old, it is either out of date, or it
  means that I have been lazy and haven't updated it.  This document was
  produced by using the SGML system that was specifically set up for the
  Linux Howto project, and there are various output formats available,
  including, postscript, dvi, ascii, html, and soon TeXinfo.
  I would recommend viewing it in the html (via a WWW browser) or the
  Postscript/dvi format. Both of these contain cross-references that are
  lost in the ascii translation.

  If you want to get the official copy off sunsite, here is URL.

  Ethernet-HOWTO <http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html>

  If minor additions and changes have been made, you can view the latest
  working copy from this URL.

  Working Copy <http://rsphy1.anu.edu.au/~gpg109/Ethernet-HOWTO.html>


  1.2.  Using the Ethernet-Howto


  As this guide is getting bigger and bigger, you probably don't want to
  spend the rest of your afternoon reading the whole thing. And you
  don't have to read it all. If you haven't got an ethernet card, then
  you will want to start with ``What card should I buy...''  to see what
  you should buy, and what you should avoid. If you have already got an
  ethernet card, but are not sure if you can use it with Linux, then you
  will want to read ``Vendor Specific...''  which contains specific
  information on each manufacturer, and their cards. If you are having
  trouble with your card, then you will want to read the specific
  information about your card mentioned above, and the troubleshooting
  information in ``the FAQ section''.  If you are interested in some of
  the technical aspects of the device drivers, then you can find that
  information in ``Technical Information''


  1.3.  Disclaimer and Copyright


  This document is not gospel. However, it is probably the most up to
  date info that you will be able to find. Nobody is responsible for
  what happens to your hardware but yourself. If your ethercard or any
  other hardware goes up in smoke (...nearly impossible!)  we take no
  responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE FOR ANY DAMAGES
  INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION INCLUDED IN
  THIS DOCUMENT.

  This document is Copyright (c) 1993, 1994, 1995 by Donald Becker and
  Paul Gortmaker. Permission is granted to make and distribute verbatim
  copies of this manual provided the copyright notice and this
  permission notice are preserved on all copies.

  Permission is granted to copy and distribute modified versions of this
  document under the conditions for verbatim copying, provided that this
  copyright notice is included exactly as in the original, and that the
  entire resulting derived work is distributed under the terms of a
  permission notice identical to this one.

  Permission is granted to copy and distribute translations of this
  document into another language, under the above conditions for
  modified versions.

  If you are intending to incorporate this document into a published
  work, please contact me, and I will make an effort to ensure that you
  have the most up to date information available. In the past, out of
  date versions of the Linux howto documents have been published, which
  caused the developers undue grief from being plagued with questions
  that were already answered in the up to date versions.


  2.  What card should I buy for Linux?


  The answer to this question depends heavily on exactly what you intend
  on doing with your net connection, and how much traffic it will see.

  If you only expect a single user to be doing the occasional ftp
  session or WWW connection, then an old 8 bit wd8003 card will keep you
  happy.

  If you intend to set up a server, and you require the CPU overhead of
  Rx'ing and Tx'ing ether packets to be kept at a minimum, you probably
  want to look at one of the newer PCI cards with the DEC 21040 chip, or
  the AMD PCnet-PCI chip.

  If you fall somewhere in the middle of the above, then any one of the
  16 bit ISA cards with stable drivers will do the job for you.


  2.1.  So What Drivers are Stable?


  Of the 16 bit ISA cards, the following drivers are very mature, and
  you shouldn't have any problems if you buy a card that uses these
  drivers.

  SMC-Ultra/EtherEZ, WD80x3, 3c509, 3c503/16, Lance, NE2000.

  This is not to say that all the other drivers are unstable.  It just
  happens that the above are the oldest and most used of all the linux
  drivers, making them the safest choice.

  Note that some el-cheapo motherboards can have trouble with the bus-
  mastering that the lance cards do, and some el-cheapo NE2000 clones
  can have trouble getting detected at boot.

  As for PCI cards, the PCnet-PCI cards that use the lance driver are a
  safe choice (except for the Boca cards as they have hardware flaws).
  The Allied Telsyn AT2450 is a PCnet-PCI implementation that is known
  to work well.

  The DEC 21040 `tulip' driver and the 3c59x `vortex' driver are
  relatively new drivers, but have proven themselves to be quite stable
  already. (The newer 21041 based cards may be slightly problematic at
  the moment, but this will no doubt be resolved quickly.)


  2.2.  Eight bit vs 16 bit Cards


  You probably can't buy a new 8 bit ISA ethercard anymore, but you will
  find lots of them turning up at computer swap meets and the like for
  the next few years, at very low prices.  This will make them popular
  for ``home-ethernet'' systems.

  Some 8 bit cards that will provide adequate performance for light to
  average use are the wd8003, the 3c503 and the ne1000.  The 3c501
  provides poor performance, and these poor 10 year old relics of the XT
  days should be avoided.

  The 8 bit data path doesn't hurt performance that much, as you can
  still expect to get about 500 to 800kB/s ftp download speed to an 8
  bit wd8003 card (on a fast ISA bus) from a fast host.  And if most of
  your net-traffic is going to remote sites, then the bottleneck in the
  path will be elsewhere, and the only speed difference you will notice
  is during net activity on your local subnet.
  2.3.  32 Bit / VLB / PCI Ethernet Cards


  There aren't many 32 bit ethercard device drivers because there aren't
  that many 32 bit ethercards.  There aren't many 32 bit ethercards out
  there because a 10Mbs network doesn't justify spending the 5x price
  increment for the 32 bit interface. (For a 100Mbs network, it is a
  different story though.)

  See ``Programmed I/O vs. ...'' as to why having an ethercard on an
  8MHz ISA bus is really not a bottleneck. Even though having the
  ethercard on a fast bus won't necessarily mean faster transfers, it
  will usually mean reduced CPU overhead, which is good for multi-user
  systems.

  AMD has the 32 bit PCnet-VLB and PCnet-PCI chips.  See ``AMD
  PCnet-32'' for info on the 32 bit versions of the LANCE / PCnet-ISA
  chip.

  The DEC 21040 PCI chip is another option (see ``DEC 21040'') for
  power-users.  Many manufacturers produce cards that use this chip.

  3Com's `Vortex' PCI cards are also another option, and the price is
  quite cheap if you can get one under their evaluation deal while it
  lasts.  (see ``3c590/3c595'')


  2.4.  Available 100Mbs Cards and Drivers


  The present list of supported 100Mbs hardware is as follows: cards
  with the DEC 21140 chip; the 3c595 Vortex card; and the HP 100VG ANY-
  LAN. The drivers for the first two are quite stable, but feedback on
  the HP driver has been low so far as it has only been around since
  early 1.3.x kernels.

  The EtherExpressPro10/100 is not presently supported.  Getting
  documentation out of intel is difficult to impossible, which is the
  main reason.

  The 21140 100Base-? chip is supported with the same driver as its
  10Mbs counterpart, the 21040. SMC's 100Mbs EtherPower PCI card uses
  this chip. As with the 21040, you have a choice of two drivers to pick
  from.

  Also have a look at the information on Donald's WWW site, at the
  following URL:

  100Mbs Ethernet <http://cesdis.gsfc.nasa.gov/linux/misc/100mbs.html>

  Donald has been doing most of his work with the SMC EtherPower-10/100
  cards, and reports getting about 4.6MB/s application to application
  with TCP on P5-100 Triton machines.

  (See ``3c595'' and ``DEC 21140'' for more details.)

  For 100VG information, see Donald's 100VG Page
  <http://cesdis.gsfc.nasa.gov/linux/drivers/100vg.html>

  You may also be interested in looking at:

  Dan Kegel's Fast Ethernet Page <http://alumni.caltech.edu/~dank/fe/>




  2.5.  Programmed I/O vs. Shared Memory vs. DMA


  Ethernet is 10Mbs. (Don't be pedantic, 3Mbs and 100Mbs don't count.)
  If you can already send and receive back-to-back packets, you just
  can't put more bits over the wire. Every modern ethercard can receive
  back-to-back packets. The Linux DP8390 drivers come pretty close to
  sending back-to-back packets (depending on the current interrupt
  latency) and the 3c509 and AT1500 hardware has no problem at all
  automatically sending back-to-back packets.

  The ISA bus can do 5.3MB/sec (42Mb/sec), which sounds like more than
  enough. You can use that bandwidth in several ways:


  2.5.1.  Programmed I/O (e.g. NE2000, HP)


  Pro: Doesn't use any constrained system resources, just a few I/O
  registers, and has no 16M limit.

  Con: Usually the slowest transfer rate, the CPU is waiting the whole
  time, and interleaved packet access is usually difficult to
  impossible.


  2.5.2.  Shared memory (e.g. WD80x3, SMC-Ultra, 3c503)


  Pro: Simple, faster than programmed I/O, and allows random access to
  packets. The linux drivers compute the checksum of incoming IP packets
  as they are copied off the card, resulting in a further reduction of
  CPU usage vs. an equivalent PIO card.

  Con: Uses up memory space (a big one for DOS users, only a minor issue
  under Linux), and it still ties up the CPU.


  2.5.3.  Slave (normal) Direct Memory Access (e.g. none for Linux!)


  Pro: Frees up the CPU during the actual data transfer.

  Con: Checking boundary conditions, allocating contiguous buffers, and
  programming the DMA registers makes it the slowest of all techniques.
  It also uses up a scarce DMA channel, and requires aligned low memory
  buffers.


  2.5.4.  Bus Master Direct Memory Access (e.g. LANCE, DEC 21040)


  Pro: Frees up the CPU during the data transfer, can string together
  buffers, can require little or no CPU time lost on the ISA bus.

  Con: Requires low-memory buffers and a DMA channel. Any bus-master
  will have problems with other bus-masters that are bus-hogs, such as
  some primitive SCSI adaptors. A few badly-designed motherboard
  chipsets have problems with bus-masters. And a reason for not using
  any type of DMA device is using a 486 processor designed for plug-in
  replacement of a 386: these processors must flush their cache with
  each DMA cycle. (This includes the Cx486DLC, Ti486DLC, Cx486SLC,
  Ti486SLC, etc.)



  2.6.  Type of cable that your card should support


  If you are setting up a small ``personal'' network, you will probably
  want to use thinnet or thin ethernet cable. This is the style with the
  standard BNC connectors. See ``Cables, Coax...''  for other concerns
  with different types of ethernet cable.

  Most ethercards also come in a `Combo' version for only $10-$20 more.
  These have both twisted pair and thinnet transceiver built-in,
  allowing you to change your mind later.

  The twisted pair cables, with the RJ-45 (giant phone jack) connectors
  is technically called 10BaseT. You may also hear it called UTP
  (Unsheilded Twisted Pair).

  The thinnet, or thin ethernet cabling, (RG-58 coaxial cable) with the
  BNC (metal push and turn-to-lock) connectors is technically called
  10Base2.

  The older thick ethernet (10mm coaxial cable) which is only found in
  older installations is called 10Base5.

  Large corporate installations will most likely use 10BaseT instead of
  10Base2. 10Base2 does not offer an easy upgrade path to the new
  upcoming 100Base-whatever.


  3.  Frequently Asked Questions


  Here are some of the more frequently asked questions about using Linux
  with an Ethernet connection. Some of the more specific questions are
  sorted on a `per manufacturer basis'.  However, since this document is
  basically `old' by the time you get it, any `new' problems will not
  appear here instantly. For these, I suggest that you make efficient
  use of your newsreader. For example, nn users would type


       nn -xX -s'3c'


  to get all the news articles in your subscribed list that have `3c' in
  the subject. (ie. 3com, 3c509, 3c503, etc.)  The moral: Read the man
  page for your newsreader.


  3.1.  Alpha Drivers -- Getting and Using them


  I heard that there is an updated or alpha driver available for my
  card. Where can I get it?

  The newest of the `new' drivers can be found on Donald's new ftp site:
  cesdis.gsfc.nasa.gov in the /pub/linux/ area. Things change here quite
  frequently, so just look around for it.  There is still all the stuff
  on the old ftp site ftp.super.org in /pub/linux, but this is not being
  actively maintained, and hence will be of limited value to most
  people.

  Note that most of the `useable' alpha drivers have been included in
  the standard kernel source tree. When running make config you will be
  asked if you want to be offered ALPHA test drivers.

  Now, if it really is an alpha, or pre-alpha driver, then please treat
  it as such. In other words, don't complain because you can't figure
  out what to do with it. If you can't figure out how to install it,
  then you probably shouldn't be testing it.  Also, if it brings your
  machine down, don't complain. Instead, send us a well documented bug
  report, or even better, a patch!

  People reading this while net-surfing may want to check out:

  Don's Linux Home Page
  <http://cesdis.gsfc.nasa.gov/pub/linux/linux.html>

  for the latest dirt on what is new and upcoming.


  3.2.  Using More than one Ethernet Card per Machine


  What needs to be done so that Linux can run two ethernet cards?

  The hooks for multiple ethercards are all there.  However, note that
  only one ethercard is auto-probed for by default.  This avoids a lot
  of possible boot time hangs caused by probing sensitive cards.

  There are two ways that you can enable auto-probing for the second
  (and third, and...) card. The easiest method is to pass boot-time
  arguments to the kernel, which is usually done by LILO. Probing for
  the second card can be achieved by using a boot-time argument as
  simple as ether=0,0,eth1. In this case eth0 and eth1 will be assigned
  in the order that the cards are found at boot.  Say if you want the
  card at 0x300 to be eth0 and the card at 0x280 to be eth1 then you
  could use


       LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1


  The ether= command accepts more than the IRQ + i/o + name shown above.
  Please have a look at ``Passing Ethernet Arguments...''  for the full
  syntax, card specific parameters, and LILO tips.

  These boot time arguments can be made permanent so that you don't have
  to re-enter them every time. See the LILO configuration option
  `append' in the LILO manual.

  The second way (not recommended) is to edit the file Space.c and
  replace the 0xffe0 entry for the i/o address with a zero. The 0xffe0
  entry tells it not to probe for that device -- replacing it with a
  zero will enable autoprobing for that device.  If you really need more
  than four ethernet cards in one machine, then you can add an eth4
  entry and an eth5 entry and so on.

  Note that if you are intending to use Linux as a gateway between two
  networks, you will have to re-compile a kernel with IP forwarding
  enabled. Usually using an old AT/286 with something like the `kbridge'
  software is a better solution.

  If you are viewing this while net-surfing, you may wish to look at a
  mini-howto Donald has on his WWW site. Check out Multiple Ethercards
  <http://cesdis.gsfc.nasa.gov/linux/misc/multicard.html>.

  For module users with 8390 based cards, you can have a single module
  control multiple cards as well. Please see ``8390 Based Cards as
  Modules'' for module specific information about using multiple cards.




  3.3.  Poor NE2000 Clones


  Here is a list of some of the NE-2000 clones that are known to have
  various problems. Most of them aren't fatal. In the case of the ones
  listed as `bad clones' -- this usually indicates that the cards don't
  have the two NE2000 identifier bytes. NEx000-clones have a Station
  Address PROM (SAPROM) in the packet buffer memory space.  NE2000
  clones have 0x57,0x57 in bytes 0x0e,0x0f of the SAPROM, while other
  supposed NE2000 clones must be detected by their SA prefix.

  This is not a comprehensive list of all the NE2000 clones that don't
  have the 0x57,0x57 in bytes 0x0e,0x0f of the SAPROM. There are
  probably hundreds of them. If you get a card that causes the driver to
  report an `invalid signature' then you will have to add your cards
  signature to the driver. The process for doing this is described
  below.

  Accton NE2000 -- might not get detected at boot, see below.

  Aritsoft LANtastic AE-2 -- OK, but has flawed error-reporting
  registers.

  AT-LAN-TEC NE2000 -- clone uses Winbond chip that traps SCSI drivers

  ShineNet LCS-8634 -- clone uses Winbond chip that traps SCSI drivers

  Cabletron E10**, E20**, E10**-x, E20**-x -- bad clones, but the driver
  checks for them. See ``E10**''.

  D-Link Ethernet II -- bad clones, but the driver checks for them. See
  ``DE-100 / DE-200''.

  DFI DFINET-300, DFINET-400 -- bad clones, but the driver checks for
  them. See ``DFI-300 / DFI-400''

  EtherNext UTP8, EtherNext UTP16 -- bad clones, but the driver checks
  for them.


  3.4.  Problems with NE1000 / NE2000 cards (and clones)


  Problem: NE*000 card hangs machine, sometimes with a `DMA conflict'
  message, sometimes completely silently.

  Reason: There were some bugs in the driver and the upper networking
  layers that caused this. They have been fixed in kernels v1.2.9 and
  above. Upgrade your kernel.

  Problem: NE*000 card hangs machine during NE probe, or can not read
  station address properly.

  Reason: Kernels previous to v1.3.7 did not fully reset the card after
  finding it at boot. Some cheap cards are not left in a reasonable
  state after power-up and need to be fully reset before any attempt is
  made to use them. Also, a previous probe may have upset the NE card
  prior to the NE probe taking place. In that case, look in to using the
  ``reserve='' boot keyword to protect the card from other probes.

  Problem: NE*000 driver reports `not found (no reset ack)' during boot
  probe.

  Reason: This is related to the above change. After the initial
  verification that an 8390 is at the probed i/o address, the reset is
  performed. When the card has completed the reset, it is supposed to
  acknowedge that the reset has completed.  Your card doesn't, and so
  the driver assumes that no NE card is present.

  Solution:

  Change the two lines as shown below in drivers/net/ne.c

  ______________________________________________________________________
  -                       printk(" not found (no reset ack).\n");
  -                       return ENODEV;
  +                       printk(" (warning: no reset ack)");
  +                       break;
  ______________________________________________________________________



  This will allow the card detection to continue, even if your card
  doesn't ACK the reset.

  Problem: NE*000 card hangs machine at first network access.

  Reason: This problem has been reported for kernels as old as 1.1.57 to
  the present. It appears confined to the software configurable clone
  cards. It appears that they expect to be initialized in some special
  way.

  Solution: Several people have reported that running the supplied DOS
  software config program and/or the supplied DOS driver prior to warm
  booting (i.e. loadlin or the `three-finger-salute') into linux allowed
  the card to work. This would indicate that these cards need to be
  initialized in a particular fashion, slightly different than what the
  present Linux driver does.

  Problem: NE*000 ethercard at 0x360 doesn't get detected anymore.

  Reason: Recent kernels ( > 1.1.7X) have more sanity checks with
  respect to overlapping i/o regions. Your NE2000 card is 0x20 wide in
  i/o space, which makes it hit the parallel port at 0x378.  Other
  devices that could be there are the second floppy controller (if
  equipped) at 0x370 and the secondary IDE controller at 0x376--0x377.
  If the port(s) are already registered by another driver, the kernel
  will not let the probe happen.

  Solution: Either move your card to an address like 0x280, 0x340, 0x320
  or compile without parallel printer support.

  Problem: Network `goes away' every time I print something (NE2000)

  Reason: Same problem as above, but you have an older kernel that
  doesn't check for overlapping i/o regions. Use the same fix as above,
  and get a new kernel while you are at it.

  Problem: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found.
  (invalid signature yy zz)

  Reason: First off, do you have a NE1000 or NE2000 card at the addr.
  0xNNN?  And if so, does the hardware address reported look like a
  valid one? If so, then you have a poor NE*000 clone. All NE*000 clones
  are supposed to have the value 0x57 in bytes 14 and 15 of the SA PROM
  on the card. Yours doesn't -- it has `yy zz' instead.

  Solution: The driver (/usr/src/linux/drivers/net/ne.c) has a "Hall of
  Shame" list at about line 42. This list is used to detect poor clones.
  For example, the DFI cards use `DFI' in the first 3 bytes of the prom,
  instead of using 0x57 in bytes 14 and 15, like they are supposed to.

  You can determine what the first 3 bytes of your card PROM are by
  adding a line like:


      printk("PROM prefix: %2.2x %2.2x %2.2x\n",SA_prom[0],SA_prom[1],SA_prom[2]);



  into the driver, right after the error message you got above, and just
  before the "return ENXIO" at line 227.

  Reboot with this change in place, and after the detection fails, you
  will get the three bytes from the PROM like the DFI example above.
  Then you can add your card to the bad_clone_list[] at about line 43.
  Say the above line printed out:


       PROM prefix: 0x3F 0x2D 0x1C


  after you rebooted. And say that the 8 bit version of your card was
  called the "FOO-1k" and the 16 bit version the "FOO-2k". Then you
  would add the following line to the bad_clone_list[]:


       {"FOO-1k", "FOO-2k", {0x3F, 0x2D, 0x1C,}},


  Note that the 2 name strings you add can be anything -- they are just
  printed at boot, and not matched against anything on the card.  You
  can also take out the "printk()" that you added above, if you want.
  It shouldn't hit that line anymore anyway. Then recompile once more,
  and your card should be detected.

  Problem: Errors like DMA address mismatch

  Is the chip a real NatSemi 8390? (DP8390, DP83901, DP83902 or
  DP83905)?  If not, some clone chips don't correctly implement the
  transfer verification register. MS-DOS drivers never do error
  checking, so it doesn't matter to them. (Note: The DMA address check
  is not done by default as of v1.2.4 for performance reasons. Enable it
  with the `NE_SANITY' define in ne.c if you want the check done.)

  Are most of the messages off by a factor of 2?  If so:  Are you using
  the NE2000 in a 16 bit slot?  Is it jumpered to use only 8 bit
  transfers?

  The Linux driver expects a NE2000 to be in a 16 bit slot. A NE1000 can
  be in either size slot. This problem can also occur with some clones,
  notably D-Link 16 bit cards, that don't have the correct ID bytes in
  the station address PROM.

  Are you running the bus faster than 8Mhz?  If you can change the speed
  (faster or slower), see if that makes a difference. Most NE2000 clones
  will run at 16MHz, but some may not. Changing speed can also mask a
  noisy bus.

  What other devices are on the bus?  If moving the devices around
  changes the reliability, then you have a bus noise problem -- just
  what that error message was designed to detect. Congratulations,
  you've probably found the source of other problems as well.

  Problem: The machine hangs during boot right after the `8390...'  or
  `WD....' message. Removing the NE2000 fixes the problem.


  Solution: Change your NE2000 base address to 0x340. Alternatively, you
  can use the device registrar implemented in 0.99pl13 and later
  kernels.

  Reason: Your NE2000 clone isn't a good enough clone. An active NE2000
  is a bottomless pit that will trap any driver autoprobing in its
  space. The other ethercard drivers take great pain to reset the NE2000
  so that it's safe, but some clones cannot be reset. Clone chips to
  watch out for: Winbond 83C901. Changing the NE2000 to a less-popular
  address will move it out of the way of other autoprobes, allowing your
  machine to boot.


  Problem: The machine hangs during the SCSI probe at boot.

  Reason: It's the same problem as above, change the ethercard's
  address, or use the device registrar.

  Problem: The machine hangs during the soundcard probe at boot.

  Reason: No, that's really during the silent SCSI probe, and it's the
  same problem as above.

  Problem: NE2000 not detected at boot - no boot messages at all

  Donald writes: `A few people have reported a problem with detecting
  the Accton NE2000.  This problem occurs only at boot-time, and the
  card is later detected at run-time by the identical code my (alpha-
  test) ne2k diagnostic program. Accton has been very responsive, but I
  still haven't tracked down what is going on. I've been unable to
  reproduce this problem with the Accton cards we purchased. If you are
  having this problem, please send me an immediate bug report. For that
  matter, if you have an Accton card send me a success report, including
  the type of the motherboard. I'm especially interested in finding out
  if this problem moves with the particular ethercard, or stays with the
  motherboard.'

  Here are some things to try, as they have fixed it for some people:


  o  Change the bus speed, or just move the card to a different slot.

  o  Change the `I/O recovery time' parameter in the BIOS chipset
     configuration.


  3.5.  Problems with WD80*3 cards


  Problem: A WD80*3 is falsely detected. Removing the sound or MIDI card
  eliminates the `detected' message.

  Reason: Some MIDI ports happen to produce the same checksum as a WD
  ethercard.

  Solution: Update your ethercard driver: new versions include an
  additional sanity check. If it is the midi chip at 0x388 that is
  getting detected as a WD living at 0x380, then you could also use:

          LILO: linux reserve=0x380,8



  Problem: You get messages such as the following with your 80*3:


          eth0: bogus packet size, status = NNNN
          kmalloc called with impossibly large argument (65400)
          eth0: Couldn't allocate sk_buff of size 65400
          eth0: receiver overrun



  Reason: There is a shared memory problem.

  Solution: If the problem is sporadic, you have hardware problems.
  Typical problems that are easy to fix are board conflicts, having
  cache or `shadow ROM' enabled for that region, or running your bus
  faster than 8Mhz. There are also a surprising number of memory
  failures on ethernet cards, so run a diagnostic program if you have
  one for your ethercard.

  If the problem is continual, and you have have to reboot to fix the
  problem, record the boot-time probe message and mail it to
  becker@cesdis.gsfc.nasa.gov - Take particular note of the shared
  memory location.

  Problem: WD80*3 will not get detected at boot.

  Reason: Earlier versions of the Mitsumi CD-ROM (mcd) driver probe at
  0x300 will succeed if just about anything is that I/O location.  This
  is bad news and needs to be a bit more robust.  Once another driver
  registers that it `owns' an I/O location, other drivers (incl. the
  wd80x3) are `locked out' and can not probe that addr for a card.

  Solution: Recompile a new kernel without any excess drivers that you
  aren't using, including the above mcd driver.  Or try moving your
  ethercard to a new I/O addr. Valid I/O addr. for all the cards are
  listed in ``Probed Addresses'' You can also point the mcd driver off
  in another direction by a boot-time parameter (via LILO) such as:

       mcd=0x200,12


  Problem: Old wd8003 and/or jumper-settable wd8013 always get the IRQ
  wrong.

  Reason: The old wd8003 cards and jumper-settable wd8013 clones don't
  have the EEPROM that the driver can read the IRQ setting from.  If the
  driver can't read the IRQ, then it tries to auto-IRQ to find out what
  it is. And if auto-IRQ returns zero, then the driver just assigns IRQ
  5 for an 8 bit card or IRQ 10 for a 16 bit card.

  Solution: Avoid the auto-IRQ code, and tell the kernel what the IRQ
  that you have jumpered the card to is via a boot time argument.  For
  example, if you are using IRQ 9, using the following should work.


       LILO: linux ether=9,0,eth0



  3.6.  Problems with 3Com cards

  Problem: The 3c503 picks IRQ N, but this is needed for some other
  device which needs IRQ N. (eg. CD ROM driver, modem, etc.)  Can this
  be fixed without compiling this into the kernel?

  Solution: The 3c503 driver probes for a free IRQ line in the order {5,
  9/2, 3, 4}, and it should pick a line which isn't being used. Very old
  drivers used to pick the IRQ line at boot-time, and the current driver
  (0.99pl12 and newer) chooses when the card is open()/ifconfig'ed.
  Alternately, you can fix the IRQ at boot by passing parameters via
  LILO. The following selects IRQ9, base location 0x300, <ignored
  value>, and if_port #1 (the external transceiver).


       LILO: linux ether=9,0x300,0,1,eth0


  The following selects IRQ3, probes for the base location, <ignored
  value>, and the default if_port #0 (the internal transceiver)


       LILO: linux ether=3,0,0,0,eth0


  Problem: 3c503: configured interrupt X invalid, will use autoIRQ.

  Reason: The 3c503 card can only use one of IRQ{5, 2/9, 3, 4} (These
  are the only lines that are connected to the card.)  If you pass in an
  IRQ value that is not in the above set, you will get the above
  message.  Usually, specifying an interrupt value for the 3c503 is not
  necessary. The 3c503 will autoIRQ when it gets ifconfig'ed, and pick
  one of IRQ{5, 2/9, 3, 4}.

  Solution: Use one of the valid IRQs listed above, or enable autoIRQ by
  not specifying the IRQ line at all.

  Problem: The supplied 3c503 drivers don't use the AUI (thicknet) port.
  How does one choose it over the default thinnet port?

  Solution: The 3c503 AUI port can be selected at boot-time with
  0.99pl12 and later. The selection is overloaded onto the low bit of
  the currently-unused dev->rmem_start variable, so a boot-time
  parameter of:


       LILO: linux ether=0,0,0,1,eth0


  should work. A boot line to force IRQ 5, port base 0x300, and use an
  external transceiver is:


       LILO: linux ether=5,0x300,0,1,eth0


  With kernels 1.3.42 and newer, you can specify the AUI port when
  loading as a module as well. Just append xcvr=1 to the insmod command
  line along with your i/o and irq values.

  Also note that kernel revisions 1.00 to 1.03 had an interesting
  `feature'. They would switch to the AUI port when the internal
  transceiver failed. This is a problem, as it will never switch back if
  for example you momentarily disconnect the cable. Kernel versions 1.04
  and newer only switch if the very first Tx attempt fails.


  3.7.  Problems with Hewlett Packard Cards


  Problem: HP Vectra using built in AMD LANCE chip gets IRQ and DMA
  wrong.

  Solution: The HP Vectra uses a different implementation to the
  standard HP-J2405A. The `lance.c' driver used to always use the value
  in the setup register of an HP Lance implementation.  In the Vectra
  case it's reading an invalid 0xff value. Kernel versions newer than
  about 1.1.50 now handle the Vectra in an appropriate fashion.

  Problem: HP Card is not detected at boot, even though kernel was
  compiled with `HP PCLAN support'.

  Solution: You probably have a HP PCLAN+  -- note the `plus'. Support
  for the PCLAN+ was added to mid/late versions of 1.1.  Recompile a
  (possibly newer) kernel with support for the HP PCLAN+ and you should
  be in business.



  3.8.  FAQs Not Specific to Any Card.



  3.8.1.  Ethercard is Not Detected at Boot.


  The usual reason for this is that people are using a kernel that does
  not have support for their particular card built in. If you are using
  a pre-compiled kernel that is part of a distribution set, then check
  the documentation to see which kernel you installed, and if it was
  built with support for your particular card. If it wasn't, then your
  options are to try and get one that has support for your card, or
  build your own.

  It is usually wise to build your own kernel with only the drivers you
  need, as this cuts down on the kernel size (saving your precious RAM
  for applications!) and reduces the number of device probes that can
  upset sensitive hardware. Building a kernel is not as complicated as
  it sounds. You just have to answer yes or no to a bunch of questions
  about what drivers you want, and it does the rest.

  The next main cause is having another device using part of the i/o
  space that your card needs. Most cards are 16 or 32 bytes wide in i/o
  space. If your card is set at 0x300 and 32 bytes wide, then the driver
  will ask for 0x300-0x31f. If any other device driver has registered
  even one port anywhere in that range, the probe will not take place at
  that address and  the driver will silently continue to the next of the
  probed addresses. So, after booting, do a cat /proc/ioports and verify
  that the full iospace that the card will require is vacant.

  Another problem is having your card jumpered to an i/o address that
  isn't probed by default. There is a list ``probed addresses'' for each
  card in this document. Even if the i/o setting of your card is not in
  the list of porbed addresses, you can supply it at boot with the
  ether= command as described in ``Passing Ethernet Arguments...''



  3.8.2.  ifconfig reports the wrong i/o address for the card.


  No it doesn't. You are just interpreting it incorrectly.  This is not
  a bug, and the numbers reported are correct. It just happens that some
  8390 based cards (wd80x3, smc-ultra, etc) have the actual 8390 chip
  living at an offset from the first assigned i/o port.  Try cd
  /usr/src/linux/drivers/net;grep NIC_OFFSET *.c|more to see what is
  going on. This is the value stored in dev->base_addr, and is what
  ifconfig reports. If you want to see the full range of ports that your
  card uses, then try cat /proc/ioports which will give the numbers you
  expect.


  3.8.3.  Shared Memory ISA cards in PCI Machine


  This will usually show up as reads of lots of 0xffff values.  No
  shared memory cards of any type will work in a PCI machine unless you
  have the PCI ROM BIOS/CMOS SETUP configuration set properly. You have
  to set it to allow shared memory access from the ISA bus for the
  memory region that your card is trying to use. If you can't figure out
  which settings are applicable then ask your supplier or local computer
  guru.


  3.8.4.  Asynchronous Transfer Mode (ATM) Support


  Werner Almesberger has been playing around with ATM support for linux.
  He has been working with the Efficient Networks ENI155p board
  (Efficient Networks <http://www.efficient.com/>) and the Zeitnet
  ZN1221 board (Zeitnet <http://www.zeitnet.com/>).

  Werner says that the driver for the ENI155p is rather stable, while
  the driver for the ZN1221 is presently unfinished.

  Check the latest/updated status at the following URL:

  Linux ATM Support <http://lrcwww.epfl.ch/linux-atm/>


  3.8.5.  FDDI Support

  Is there FDDI support for Linux?

  Donald writes: `No, there is no Linux driver for any FDDI boards.  I
  come from a place with supercomputers, so an external observer might
  think FDDI would be high on my list. But FDDI never delivered end-to-
  end throughput that would justify its cost, and it seems to be a
  nearly abandoned technology now that 100base{X,Anynet} seems imminent.
  (And yes, I know you can now get FDDI boards for <$1K. That seems to
  be a last-ditch effort to get some return on the development
  investment. Where is the next generation of FDDI going to come from?)'


  3.8.6.  Ethernet Cards for Linux on Alpha/AXP PCI Boards


  At present only the depca, de4x5 and all the 8390 drivers (wd, smc-
  ultra, ne, 3c503, e2100, ac3200, hp, hp-plus) have been made
  `architecture independent' so as to work on the DEC Alpha CPU based
  systems.

  Note that the changes that are required aren't that complicated.  You
  only need to do the following:

  -multiply all jiffies related values by HZ/100 to account for the
  different HZ value that the Alpha uses.  (i.e timeout=2; becomes
  timeout=2*HZ/100;)

  -replace any i/o memory (640k to 1MB) pointer dereferences with the
  appropriate readb() writeb() readl() writel() calls, as shown in this
  example.






  ______________________________________________________________________
  -       int *mem_base = (int *)dev->mem_start;
  -       mem_base[0] = 0xba5eba5e;
  +       unsigned long mem_base = dev->mem_start;
  +       writel(0xba5eba5e, mem_base);
  ______________________________________________________________________



  -replace all memcpy() calls that have i/o memory as source or target
  destinations with the appropriate one of memcpy_fromio() or
  memcpy_toio().


  3.8.7.  Linking 10BaseT without a Hub


  Can I link 10BaseT (RJ45) based systems together without a hub?

  You can link 2 machines easily, but no more than that, without extra
  devices/gizmos. See ``Twisted Pair'' -- it explains how to do it. And
  no, you can't hack together a hub just by crossing a few wires and
  stuff. It's pretty much impossible to do the collision signal right
  without duplicating a hub.


  3.8.8.  SIOCSIFxxx: No such device


  I get a bunch of `SIOCSIFxxx: No such device' messages at boot,
  followed by a `SIOCADDRT: Network is unreachable' What is wrong?

  Your ethernet device was not detected at boot, and when ifconfig and
  route are run, they have no device to work with. Use dmesg | more to
  review the boot messages and see if there are any messages about
  detecting an ethernet card.


  3.8.9.  SIOCSFFLAGS: Try again


  I get `SIOCSFFLAGS: Try again' when I run `ifconfig' -- Huh?

  Some other device has taken the IRQ that your ethercard is trying to
  use, and so the ethercard can't use the IRQ.  You don't necessairly
  need to reboot to resolve this, as some devices only grab the IRQs
  when they need them and then release them when they are done. Examples
  are some sound cards, serial ports, floppy disk driver, etc. You can
  type cat /proc/interrupts to see which interrupts are presently in
  use. Most of the Linux ethercard drivers only grab the IRQ when they
  are opened for use via `ifconfig'. If you can get the other device to
  `let go' of the required IRQ line, then you should be able to `Try
  again' with ifconfig.


  3.8.10.  Link UNSPEC and HW-addr of 00:00:00:00:00:00


  When I run ifconfig with no arguments, it reports that LINK is UNSPEC
  (instead of 10Mbs Ethernet) and it also says that my hardware address
  is all zeros.

  This is because people are running a newer version of the `ifconfig'
  program than their kernel version. This new version of ifconfig is not
  able to report these properties when used in conjunction with an older
  kernel. You can either upgrade your kernel, `downgrade' ifconfig, or
  simply ignore it. The kernel knows your hardware address, so it really
  doesn't matter if ifconfig can't read it.


  3.8.11.  Huge Number of RX and TX Errors


  When I run ifconfig with no arguments, it reports that I have a huge
  error count in both rec'd and transmitted packets. It all seems to
  work ok -- What is wrong?

  Look again. It says RX packets big number PAUSE errors 0 PAUSE dropped
  0 PAUSE overrun 0.  And the same for the TX column.  Hence the big
  numbers you are seeing are the total number of packets that your
  machine has rec'd and transmitted.  If you still find it confusing,
  try typing cat /proc/net/dev instead.


  3.8.12.  Entries in /dev/ for Ethercards


  I have /dev/eth0 as a link to /dev/xxx. Is this right?

  Contrary to what you have heard, the files in /dev/* are not used.
  You can delete any /dev/wd0, /dev/ne0 and similar entries.


  3.8.13.  Linux and ``trailers''


  Should I disable trailers when I `ifconfig' my ethercard?

  You can't disable trailers, and you shouldn't want to. `Trailers' are
  a hack to avoid data copying in the networking layers. The idea was to
  use a trivial fixed-size header of size `H', put the variable-size
  header info at the end of the packet, and allocate all packets `H'
  bytes before the start of a page. While it was a good idea, it turned
  out to not work well in practice.  If someone suggests the use of
  `-trailers', note that it is the equivalent of sacrificial goats
  blood. It won't do anything to solve the problem, but if problem fixes
  itself then someone can claim deep magical knowledge.



  3.8.14.  Access to the raw Ethernet Device


  How do I get access to the raw ethernet device in linux, without going
  through TCP/IP and friends?


  ______________________________________________________________________
          int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
  ______________________________________________________________________



  This gives you a socket receiving every protocol type.  Do recvfrom()
  calls to it and it will fill the sockaddr with device type in
  sa_family and the device name in the sa_data array. I don't know who
  originally invented SOCK_PACKET for Linux (its been in for ages) but
  its superb stuff.  You can use it to send stuff raw too via sendto()
  calls.  You have to have root access to do either of course.



  4.  Performance Tips


  Here are some tips that you can use if you are suffering from low
  ethernet throughput, or to gain a bit more speed on those ftp
  transfers.

  The ttcp.c program is a good test for measuring raw throughput speed.
  Another common trick is to do a ftp> get large_file /dev/null where
  large_file is > 1MB and residing in the buffer cache on the Tx'ing
  machine. (Do the `get' at least twice, as the first time will be
  priming the buffer cache on the Tx'ing machine.) You want the file in
  the buffer cache because you are not interested in combining the file
  access speed from the disk into your measurement. Which is also why
  you send the incoming data to /dev/null instead of onto the disk.


  4.1.  General Concepts


  Even an 8 bit card is able to receive back-to-back packets without any
  problems. The difficulty arises when the computer doesn't get the Rx'd
  packets off the card quick enough to make room for more incoming
  packets. If the computer does not quickly clear the card's memory of
  the packets already received, the card will have no place to put the
  new packet.

  In this case the card either drops the new packet, or writes over top
  of a previously received packet. Either one seriously interrupts the
  smooth flow of traffic by causing/requesting re-transmissions and can
  seriously degrade performance by up to a factor of 5!

  Cards with more onboard memory are able to ``buffer'' more packets,
  and thus can handle larger bursts of back-to-back packets without
  dropping packets.  This in turn means that the card does not require
  as low a latency from the the host computer with respect to pulling
  the packets out of the buffer to avoid dropping packets.

  Most 8 bit cards have an 8kB buffer, and most 16 bit cards have a 16kB
  buffer. Most Linux drivers will reserve 3kB of that buffer (for two Tx
  ping-pong buffers), leaving only 5kB of receive space for an 8 bit
  card. This is room enough for only three full sized (1500 bytes)
  ethernet packets.


  4.2.  ISA Bus Speed

  As mentioned above, if the packets are removed from the card fast
  enough, then a drop/overrun condition won't occur even when the amount
  of Rx packet buffer memory is small. The factor that sets the rate at
  which packets are removed from the card to the computer's memory is
  the speed of the data path that joins the two -- that being the ISA
  bus speed. (If the CPU is a dog-slow 386sx-16, then this will also
  play a role.)

  The recommended ISA bus clock is about 8MHz, but many motherboards and
  peripheral devices can run at higher frequencies. The clock frequency
  for the ISA bus can usually be set in the CMOS setup, by selecting a
  divisor of the mainboard/CPU clock frequency.

  For example, here are some receive speeds as measured by the TTCP
  program on a 40MHz 486, with an old 8 bit WD8003EP card, for different
  ISA bus speeds.



  ______________________________________________________________________
          ISA Bus Speed (MHz)     Rx TTCP (kB/s)
          -------------------     --------------
          6.7                     740
          13.4                    970
          20.0                    1030
          26.7                    1075
  ______________________________________________________________________



  You would be hard pressed to do better than 1075kB/s with any 10Mb/s
  ethernet card, using TCP/IP. However, don't expect every system to
  work at fast ISA bus speeds. Most systems will not function properly
  at speeds above 13MHz. (Also, most PCI systems have the ISA bus speed
  fixed at 8MHz, so that the end user does not have the option of
  increasing it.)

  In addition to faster transfer speeds, one will usually also benefit
  from a reduction in CPU usage due to the shorter duration memory and
  i/o cycles. (Note that hard disks and video cards located on the ISA
  bus will also usually experience a performance increase from an
  increased ISA bus speed.)


  4.3.  Setting the TCP Rx Window


  Once again, cards with small amounts of onboard RAM and relatively
  slow data paths between the card and the computer's memory run into
  trouble. The default TCP Rx window setting is 32kB, which means that a
  fast computer on the same subnet as you can dump 32k of data on you
  without stopping to see if you received any of it okay.

  Recent versions of the route command have the ability to set the size
  of this window on the fly. Usually it is only for the local net that
  this window must be reduced, as computers that are behind a couple of
  routers or gateways are `buffered' enough to not pose a problem. An
  example usage would be:


  ______________________________________________________________________
          route add <whatever> ... window <win_size>
  ______________________________________________________________________



  where win_size is the size of the window you wish to use (in bytes).
  An 8 bit 3c503 card on an ISA bus operating at a speed of 10MHz or
  less would work well with a window size of about 4kB. Too large a
  window will cause overruns and dropped packets, and a drastic
  reduction in ethernet throughput. You can check the operating status
  by doing a cat /proc/net/dev which will display any dropped or overrun
  conditions that occurred.



  4.4.  Increasing NFS performance

  Some people have found that using 8 bit cards in NFS clients causes
  poorer than expected performance, when using 8kB (native Sun) NFS
  packet size.

  The possible reason for this could be due to the difference in on
  board buffer size between the 8 bit and the 16 bit cards.  The maximum
  ethernet packet size is about 1500 bytes. Now that 8kB NFS packet will
  arrive as about 6 back to back maximum size ethernet packets. Both the
  8 and 16 bit cards have no problem Rx'ing back to back packets. The
  problem arises when the machine doesn't remove the packets from the
  cards buffer in time, and the buffer overflows. The fact that 8 bit
  cards take an extra ISA bus cycle per transfer doesn't help either.
  What you can do if you have an 8 bit card is either set the NFS
  transfer size to 4kB, or try increasing the ISA bus speed in order to
  get the card's buffer cleared out faster.


  5.  Vendor/Manufacturer/Model Specific Information



  5.1.  3Com


  If you are not sure what your card is, but you think it is a 3Com
  card, you can probably figure it out from the assembly number. 3Com
  has a document `Identifying 3Com Adapters By Assembly Number' (ref
  24500002) that would most likely clear things up. See ``Technical
  Information from 3Com'' for info on how to get documents from 3Com.

  Also note that 3Com has a FTP site with various goodies: ftp.3Com.com
  that you may want to check out.

  For those of you browsing this document by a WWW browser, you can try
  3Com's WWW site


  5.1.1.  3c501


  Status -- Semi-Supported

  Too brain-damaged to use. Available surplus from many places. Avoid it
  like the plague. Again, do not purchase this card, even as a joke.
  It's performance is horrible, and it breaks in many ways.

  Cameron L. Spitzer of 3Com said: ``I'm speaking only for myself here,
  of course, but I believe 3Com advises against installing a 3C501 in a
  new system, mostly for the same reasons Donald has discussed. You
  probably won't be happy with the 3C501 in your Linux box. The data
  sheet is marked `(obsolete)' on 3Com's Developers' Order Form, and the
  board is not part of 3Com's program for sending free Technical
  Reference Manuals to people who need them. The decade-old things are
  nearly indestructible, but that's about all they've got going for them
  any more.''

  For those not yet convinced, the 3c501 can only do one thing at a time
  -- while you are removing one packet from the single-packet buffer it
  cannot receive another packet, nor can it receive a packet while
  loading a transmit packet. This was fine for a network between two
  8088-based computers where processing each packet and replying took
  10's of msecs, but modern networks send back-to-back packets for
  almost every transaction.

  AutoIRQ works, DMA isn't used, the autoprobe only looks at 0x280 and
  0x300, and the debug level is set with the third boot-time argument.

  Once again, the use of a 3c501 is strongly discouraged!  Even more so
  with a IP multicast kernel, as you will grind to a halt while
  listening to all multicast packets. See the comments at the top of the
  source code for more details.


  5.1.2.  3c503, 3c503/16


  Status -- Supported

  If you have a 3c503/16 you may be interested to know that as of 1.3.37
  the driver has the facility to use the full 16kB RAM on your card.
  Previous versions treated the 16bit cards as 8bit cards, and only used
  half of the available RAM. This update also detects the newer 3Com
  prefix found on newly manufactured cards mentioned below.

  Recently made 3c503/16 cards have a new base hardware address because
  3Com ran out of numbers (they made too many cards!) The cards used to
  start with 02 60 8C and the newer ones use 00 20 AF. Up to 1.3.37, the
  driver will only check for the old address, and skip over the newer
  cards.  You can upgrade to a kernel newer than 1.3.37, or change the
  numbers in 3c503.c for older kernels.

  These shared-memory ethercards also have a programmed I/O mode that
  doesn't use the 8390 facilities (their engineers found too many bugs!)
  It should be about the same speed as the same bus width WD80x3, but it
  is actually a bit slower.  The 3c503 does not have ``EEPROM setup'',
  so a diagnostic/setup program isn't needed before running the card
  with Linux. The shared memory address of the 3c503 is set using
  jumpers that are shared with the boot PROM address. This is confusing
  to people familiar with other ISA cards, where you always leave the
  jumper set to ``disable'' unless you have a boot PROM.

  The Linux 3c503 driver can also work with the 3c503 in programmed-I/O
  mode, but this is slower and less reliable than shared memory mode.
  Also, programmed-I/O mode is not as well tested when updating the
  drivers.  You still shouldn't use the programmed-I/O mode though,
  unless you need it for MS-DOS compatibility.

  The 3c503's IRQ line is set in software, with no hints from an EEPROM.
  Unlike the MS-DOS drivers, the Linux driver has capability to autoIRQ:
  it uses the first available IRQ line in {5,2/9,3,4}, selected each
  time the card is ifconfig'ed. (Older driver versions selected the IRQ
  at boot time.) The ioctl() call in `ifconfig' will return EAGAIN if no
  IRQ line is available at that time.

  Some common problems that people have with the 503 are discussed in
  ``Problems with...''.

  If you intend on using this driver as a loadable module you should
  probably see ``Using the Ethernet Drivers as Modules'' and also ``8390
  Based Cards as Modules'' for module specific information.




  5.1.3.  3c505


  Status -- Semi-Supported

  This is a driver that was written by Craig Southeren
  geoffw@extro.ucc.su.oz.au. These cards also use the i82586 chip.
  There are not that many of these cards about.  It is included in the
  standard kernel, but it is classed as an alpha driver. See ``Alpha
  Drivers'' for important information on using alpha-test ethernet
  drivers with Linux.

  There is also the file /usr/src/linux/drivers/net/README.3c505 that
  you should read if you are going to use one of these cards.  It
  contains various options that you can enable/disable.  Technical
  information is available in ``Programming the Intel chips''.


  5.1.4.  3c507

  Status -- Semi-Supported

  This card uses one of the Intel chips, and the development of the
  driver is closely related to the development of the Intel Ether
  Express driver.  The driver is included in the standard kernel
  release, but as an alpha driver.

  See ``Alpha Drivers'' for important information on using alpha-test
  ethernet drivers with Linux. Technical information is available in
  ``Programming the Intel chips''.


  5.1.5.  3c509 / 3c509B


  Status -- Supported

  Note: Donald has an updated driver for these cards that is not
  presently in the default kernel. It fixes harmless irq N for unknown
  device messages at boot, has better handling for the 3c509B Plug and
  Pray cards, and recovers from certain adapter failure status values.

  It's fairly inexpensive and has excellent performance for a non-bus-
  master design.  The drawbacks are that the original 3c509 requires
  very low interrupt latency. The 3c509B shouldn't suffer from the same
  problem, due to having a larger buffer. (See below.)

  Note that the ISA card detection uses a different method than most
  cards. Basically, you ask the cards to respond by sending data to an
  ID_PORT (port 0x100). Note that if you have some other strange ISA
  card using an I/O range that includes the ID_PORT of the 3c509, it
  will probably not get detected. Note that you can change the ID_PORT
  to 0x110 or 0x120 or... in 3c509.c if you have a conflicting ISA card,
  and the 3c509 will still be happy.  Also note that this detection
  method means that a particular card will always get detected first in
  a multiple ISA 3c509 configuration.  The card with the lowest hardware
  ethernet address will always end up being eth0. This shouldn't matter
  to anyone, except for those people who want to assign a 6 byte
  hardware address to a particular interface.  If you have multiple
  3c509 cards, it is best to append ether=0,0,ethN commands without the
  i/o port specified (i.e. use i/o=zero) and allow the probe to sort out
  which card is first, otherwise it may not detect all your cards.

  The original 3c509 has a smaller packet buffer (4kB total, 2kB Rx, 2kB
  Tx), causing the driver to occasionally drop a packet if interrupts
  are masked for too long. To minimize this problem, you can try
  unmasking interrupts during IDE disk transfers (see hdparm(8)) and/or
  increasing your ISA bus speed so IDE transfers finish sooner.

  (Note that the driver could be completely rewritten to use predictive
  interrupts, but performance re-writes of working drivers are low
  priority unless there is some particular incentive or need.)

  Cameron Spitzer writes: ``Beware that if you put a '509 in EISA
  addressing mode by mistake and save that in the EEPROM, you'll have to
  use an EISA machine or the infamous Test Via to get it back to normal,
  and it will conflict at IO location 0 which may hang your ISA machine.
  I believe this problem is corrected in the 3C509B version of the
  board.''


  The newer model 3c509B has 8kB on board, and the buffer can be split
  4/4, 5/3 or 6/2 for Rx/Tx. This setting can also be stored on the
  EEPROM. This should alleviate the above problem with the original
  3c509. At this point in time, the Linux driver is not aware of this,
  and treats the 3c509B as an older 3c509.

  3c509B users should use the supplied DOS utility to disable the plug
  and play support, and to set the output media to what they require.
  Cameron adds: ``The 3C509B has 3Com's relocatable I/O port scheme, and
  Microsofttm Plug-and-play ("PnP").  You can't use them both at the
  same time.  Some (broken, IMHO) BIOSes begin a PnP sequence by writing
  to the PnP address (0x279 ?), which causes PnP adapters like 3C509B to
  enter the PnP state, but then they (these funny BIOSes) never come
  back to finish the job.  The 3C509Bs hang there in the middle of the
  PnP ID Sequence, where they have no idea you didn't mean it and you're
  going to use the 3Com ID sequence after all.  3C5X9CFG /PNPRST clears
  this hang.  Disable PnP if your drivers (eg., Linux) don't use it.

  It was a marketing decision to turn PnP on as a factory default
  setting.  If it caused you a hassle, or not, please take the time to
  say so when you mail in your warranty card.  The more info they have,
  the better decisions they can make.  Also, check with your motherboard
  supplier to see if you need a BIOS upgrade.''

  With regards to the media detection features, Cameron said:
  ``Autoselect is a feature of the commercial *drivers* for 3C509(B).
  AFAIK nobody ever claimed the Linux driver attempts it.  When
  drivers/net/3c509.c recognizes my 3C509B at boot time, it says: eth0:
  3c509 at 0x300 tag 1, 10baseT port, ...  revealing that the card is
  configured for 10BASE-T.  It finds that out by reading the little
  EEPROM, which IMHO is the Right Way To Do It.''



  5.1.6.  3c523


  Status -- Not Supported

  This MCA bus card uses the i82586, and now that people are actually
  running Linux on MCA machines, someone may wish to try and recycle
  parts of the 3c507 driver into a driver for this card.


  5.1.7.  3c527


  Status -- Not Supported

- --- END Linux Ethernet HOWTO part 1/3 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gregh@cc.gatech.edu for public key

iQCVAwUBML4sm3tNTo2suu5NAQHvNQP/Z9MA0TZPnv3zP86NRU+hvURMCQWUJdI/
Qyt2diOWLKFNHC9RXbcE87C0kAaojESUtJCIiFLvn1d0kfBtiJifhPypxwRciiVB
rI1b390z7gTDCMcJdmqQOPZH1WpWNsKfrDUD2TAf/5JM+D8mrOoiuFgIfFdNn84H
chBAzam8mAQ=
=0s0e
-----END PGP SIGNATURE-----