🚀 go-pugleaf

Archive-Name: linux/howto/ethernet/part3
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 3/3 ---

  As these are basically the same as their 16 bit counterparts (WD8013 /
  SMC Elite16), you should see the next section for more information.



  5.32.2.  WD8013, SMC Elite16


  Status -- Supported

  Over the years the design has added more registers and an EEPROM.
  Clones usually go by the `8013' name, and usually use a non-EEPROM
  (jumpered) design.  Late model SMC cards will have two main PLCC chips
  on board; the SMC 83c690 and the SMC 83c694.  The shared memory design
  makes the cards 10-20 % faster, than PIO cards, especially with larger
  packets.  More importantly, from the driver's point of view, it avoids
  a few bugs in the programmed-I/O mode of the 8390, allows safe multi-
  threaded access to the packet buffer, and it doesn't have a
  programmed-I/O data register that hangs your machine during warm-boot
  probes.

  Non-EEPROM cards that can't just read the selected IRQ will attempt
  auto-irq, and if that fails, they will silently assign IRQ 10. (8 bit
  versions will assign IRQ 5)

  Cards with a non standard amount of memory on board can have the
  memory size specified at boot (or at `insmod' time if using modules).
  The standard memory size is 8kB for an 8bit card and 16kB for a 16bit
  card.  For example, the older WD8003EBT cards could be jumpered for
  32kB memory. To make full use of that RAM, you would use something
  like (for i/o=0x280 and IRQ 9):



  ______________________________________________________________________
          LILO: linux ether=9,0x280,0xd0000,0xd8000,eth0
  ______________________________________________________________________



  Also see ``8013 problems'' for some of the more common problems that
  people have.

  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.32.3.  SMC Elite Ultra


  Status -- Supported

  This ethercard is based on a new chip from SMC, with a few new
  features. While it has a mode that is similar to the older SMC
  ethercards, it's not entirely compatible with the old WD80*3 drivers.
  However, in this mode it shares most of its code with the other 8390
  drivers, while operating slightly faster than a WD8013 clone.

  Since part of the Ultra looks like an 8013, the Ultra probe is
  supposed to find an Ultra before the wd8013 probe has a chance to
  mistakenly identify it.

  Donald mentioned that it is possible to write a separate driver for
  the Ultra's `Altego' mode which allows chaining transmits at the cost
  of inefficient use of receive buffers, but that will probably not
  happen.

  Bus-Master SCSI host adaptor users take note: In the manual that ships
  with Interactive UNIX, it mentions that a bug in the SMC Ultra will
  cause data corruption with SCSI disks being run from an aha-154X host
  adaptor.  This will probably bite aha-154X compatible cards, such as
  the BusLogic boards, and the AMI-FastDisk SCSI host adaptors as well.

  SMC has acknowledged the problem occurs with Interactive, and older
  Windows NT drivers. It is a hardware conflict with early revisions of
  the card that can be worked around in the driver design. The current
  Ultra driver protects against this by only enabling the shared memory
  during data transfers with the card. Make sure your kernel version is
  at least 1.1.84, or that the driver version reported at boot is at
  least smc-ultra.c:v1.12 otherwise you are vulnerable.

  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.32.4.  SMC 8416 (EtherEZ)


  Status -- Supported

  This card uses SMC's 83c795 chip and supports the Plug 'n Play
  specification. It also has an SMC Ultra compatible mode, which allows
  it to be used with the Linux Ultra driver.  In this compatibility
  mode, it uses shared memory instead of programmed i/o. Be sure to set
  your card for this compatibility mode. See the above information for
  notes on the Ultra driver.

  Note that the EtherEZ specific checks were added to the SMC Ultra
  driver in 1.1.84, and hence earlier kernel versions will not detect or
  handle these cards correctly.



  5.32.5.  SMC 8432 PCI (EtherPower)


  Status -- Supported

  These cards are a basic DEC 21040 implementation, i.e. one big chip
  and a couple of transceivers. Donald has used one of these cards for
  his development of the generic 21040 driver (aka tulip.c). Thanks to
  Duke Kamstra, once again, for supplying a card to do development on.

  Some of the newer revisons of this card use the newer DEC 21041 chip,
  which may cause problems with older versions of the tulip driver. Make
  sure you are using the latest driver release.

  See ``DEC 21040'' for more details on using one of these cards, and
  the current status of the driver.


  5.32.6.  SMC 3008


  Status -- Not Supported

  These 8 bit cards are based on the Fujitsu MB86950, which is an
  ancient version of the MB86965 used in the Linux at1700 driver. Russ
  says that you could probably hack up a driver by looking at the
  at1700.c code and his DOS packet driver for the Tiara card (tiara.asm)


  5.32.7.  SMC 3016


  Status -- Not Supported

  These are 16bit i/o mapped 8390 cards, much similar to a generic
  NE2000 card. If you can get the specifications from SMC, then porting
  the NE2000 driver would probably be quite easy.


  5.32.8.  SMC 9000


  Status -- Not Supported

  These cards are VLB cards based on the 91c92 chip. They are fairly
  expensive, and hence the demand for a driver is pretty low at the
  moment.


  5.33.  Xircom


  Another group that won't release documentation. No cards supported.
  Don't look for any support in the future unless they release their
  programming information. And this is highly unlikely, as they forbid
  you from even reverse- engineering their drivers. If you are already
  stuck with one, see if you can trade it off on some DOS (l)user.

  And if you just want to verify that this is the case, you can reach
  Xircom at 1-800-874-7875, 1-800-438-4526 or +1-818-878-7600.  They
  used to advertise that their products "work with all network operating
  systems", but have since stopped. Wonder why...


  5.33.1.  PE1, PE2, PE3-10B*


  Status -- Not Supported

  Not to get your hopes up, but if you have one of these parallel port
  adaptors, you may be able to use it in the DOS emulator with the
  Xircom-supplied DOS drivers. You will have to allow DOSEMU access to
  your parallel port, and will probably have to play with SIG (DOSEMU's
  Silly Interrupt Generator).


  5.34.  Zenith



  5.34.1.  Z-Note


  Status -- Supported

  The built-in Z-Note network adaptor is based on the Intel i82593 using
  two DMA channels. There is an (alpha?) driver available in the present
  kernel version. As with all notebook and pocket adaptors, it is under
  the `Pocket and portable adaptors' section when running make config.
  See ``Programming the Intel chips'' for more technical information.
  Also note that the IBM ThinkPad 300 is compatible with the Z-Note.


  5.35.  Znyx



  5.35.1.  Znyx ZX342 (DEC 21040 based)


  Status -- Supported

  You have a choice of two drivers for cards based on this chip. There
  is the DE425 driver written by David, and the generic 21040 driver
  that Donald has written.

  Note that as of 1.1.91, David has added a compile time option that may
  allow non-DEC cards (such as the Znyx cards) to work with this driver.
  Have a look at README.de4x5 for details.

  See ``DEC 21040'' for more information on these cards, and the present
  driver situation.


  5.36.  Drivers for Non-Ethernet Devices


  There are a few other drivers that are in the linux source, that
  present an ethernet-like device to network programs, while not really
  being ethernet. These are briefly listed here for completeness.

  dummy.c - The purpose of this driver is to provide a device to point a
  route through, but not to actually transmit packets.

  eql.c - Load Equalizer, enslaves multiple devices (usually modems) and
  balances the Tx load across them while presenting a single device to
  the network programs.

  ibmtr.c - IBM Token Ring, which is not really ethernet.  Broken-Ring
  requires source routing and other uglies.

  loopback.c - Loopback device, for which all packets from you machine
  and destined for your own machine go.  It essentially just moves the
  packet off the Tx queue and onto the Rx queue.

  pi2.c - Ottawa Amateur Radio Club PI and PI2 interface.

  plip.c - Parallel Line Internet Protocol, allows two computers to send
  packets to each other over two joined parallel ports in a point-to-
  point fashion.

  ppp.c - Point-to-Point Protocol (RFC1331), for the Transmission of
  Multi-protocol Datagrams over a Point-to-Point Link (again usually
  modems).

  slip.c - Serial Line Internet Protocol, allows two computers to send
  packets to each other over two joined serial ports (usually via
  modems) in a point-to-point fashion.

  tunnel.c - Provides an IP tunnel through which you can tunnel network
  traffic transparently across subnets

  wavelan.c - An Ethernet-like radio transceiver controlled by the Intel
  82586 coprocessor which is used on other ethercards such as the Intel
  EtherExpress.


  6.  Cables, Coax, Twisted Pair

  If you are starting a network from scratch, it's considerably less
  expensive to use thin ethernet, RG58 co-ax cable with BNC connectors,
  than old-fashioned thick ethernet, RG-5 cable with N connectors, or
  10baseT, twisted pair telco-style cables with RJ-45 eight wire `phone'
  connectors. See ``Type of cable...'' for an introductory look at
  cables.

  Also note that the FAQ from comp.dcom.lans.ethernet has a lot of
  useful information on cables and such. Look in dorm.rutgers.edu for
  the file /pub/novell/info_and_docs/Ethernet.FAQ


  6.1.  Thin Ethernet (thinnet)


  Thin ethernet is the `ether of choice'. The cable is inexpensive. If
  you are making your own cables solid-core RG58A is $0.27/m. and
  stranded RG58AU is $0.45/m. Twist-on BNC connectors are < $2 ea., and
  other misc. pieces are similarly inexpensive. It is essential that you
  properly terminate each end of the cable with 50 ohm terminators, so
  budget $2 ea. for a pair. It's also vital that your cable have no
  `stubs' -- the `T' connectors must be attached directly to the
  ethercards. The only drawback is that if you have a big loop of
  machines connected together, and some bonehead breaks the loop by
  taking one cable off the side of his tee, the whole network goes down
  because it sees an infinite impedance (open circuit) instead of the
  required 50 ohm termination. Note that you can remove the tee piece
  from the card itself without killing the whole subnet, as long as you
  don't remove the cables from the tee itself. Of course this will
  disturb the machine that you pull the actual tee off of. 8-) And if
  you are doing a small network of two machines, you still need the tees
  and the 50 ohm terminators -- you can't just cable them together!

  6.2.  Twisted Pair


  Twisted pair networks require active hubs, which start around $200,
  and the raw cable cost can actually be higher than thinnet. They are
  usually sold using the claim that you can use your existing telephone
  wiring, but it's a rare installation where that turns out to be the
  case. The claim that you can upgrade to higher speeds is also suspect,
  as most proposed schemes use higher-grade (read $$) cable and more
  sophisticated termination ($$$) than you would likely install on
  speculation. New gizmos are floating around which allow you to daisy-
  chain machines together, and the like. For example, Farallon sells
  EtherWave adaptors and transceivers. This device allows multiple
  10baseT devices to be daisy-chained. They also sell a 3c509 clone that
  includes the EtherWave transceiver.  The drawback is that it's more
  expensive and less reliable than a cheap ($100-$150) mini-hub and
  another ethercard.  You probably should either go for the hub approach
  or switch over to 10base2 thinnet.

  On the other hand, hubs are rapidly dropping in price, all 100Mb/sec
  ethernet proposals use twisted pair, and most new business
  installations use twisted pair. (This is probably to avoid the problem
  with idiots messing with the BNC's as described above.)

  Also, Russ Nelson adds that `New installations should use Category 5
  wiring. Anything else is a waste of your installer's time, as 100Base-
  whatever is going to require Cat 5.'

  If you are only connecting two machines, it is possible to avoid using
  a hub, by swapping the Rx and Tx pairs (1-2 and 3-6).

  If you hold the RJ-45 connector facing you (as if you were going to
  plug it into your mouth) with the lock tab on the top, then the pins
  are numbered 1 to 8 from left to right. The pin usage is as follows:


          Pin Number              Assignment
          ----------              ----------
          1                       Output Data (+)
          2                       Output Data (-)
          3                       Input Data (+)
          4                       Reserved for Telephone use
          5                       Reserved for Telephone use
          6                       Input Data (-)
          7                       Reserved for Telephone use
          8                       Reserved for Telephone use



  Some cards, like the wd8013 can sense reversed polarity, and will
  adjust accordingly. Also note that 3 and 6 must be a twisted pair. If
  you make 3-4 a twisted pair, and 5-6 the other twisted pair, your
  cable may work for lengths less than a metre, but will fail miserably
  for longer lengths.

  Note that before 10BaseT was ratified as a standard, there existed
  other network formats using RJ-45 connectors, and the same wiring
  scheme as above. Examples are SynOptics's LattisNet, and AT&T's
  StarLAN.  In some cases, (as with early 3C503 cards) you could set
  jumpers to get the card to talk to hubs of different types, but in
  most cases cards designed for these older types of networks will not
  work with standard 10BaseT networks/hubs. (Note that if the cards also
  have an AUI port, then there is no reason as to why you can't use
  that, combined with an AUI to 10BaseT transceiver.)


  6.3.  Thick Ethernet

  Thick ethernet is mostly obsolete, and is usually used only to remain
  compatible with an existing implementation. You can stretch the rules
  and connect short spans of thick and thin ethernet together with a
  passive $3 N-to-BNC connector, and that's often the best solution to
  expanding an existing thicknet. A correct (but expensive) solution is
  to use a repeater in this case.

  7.  Software Configuration and Card Diagnostics


  In most cases, if the configuration is done by software, and stored in
  an EEPROM, you will usually have to boot DOS, and use the supplied DOS
  program to set the cards IRQ, I/O, mem_addr and whatnot. Besides,
  hopefully it is something you will only be setting once. For those
  that don't have the DOS utility available, note that a fair number of
  NIC setup/driver disks (e.g. 3Com, SMC/WD and Allied Telesis NIC's)
  are available from dorm.rutgers.edu in the directory
  /pub/novell/nic_drvs/ However, there are some cards for which Linux
  versions of the config utils exist, and they are listed here.

  Also, Donald has written a few small card diagnostic programs that run
  under Linux. Most of these are a result of debugging tools that he has
  created while writing the various drivers. Don't expect fancy menu-
  driven interfaces. You will have to read the source code to use most
  of these. Even if your particular card doesn't have a corresponding
  diagnostic, you can still get lots of information just by typing cat
  /proc/net/dev -- assuming that your card was at least detected at
  boot.

  In either case, you will have to run most of these programs as root
  (to allow I/O to the ports) and you probably want to shut down the
  ethercard before doing so by typing ifconfig eth0 down (Note: replace
  eth0 with atp0 or whatever when appropriate.)


  7.1.  Configuration Programs for Ethernet Cards


  For people with wd80x3 cards, there is the program wdsetup which can
  be found in wdsetup-0.6a.tar.gz on Linux ftp sites.  I am not sure if
  it is being actively maintained or not, as it has not been updated for
  quite a while. If it works fine for you then great, if not, use the
  DOS version that you should have got with your card. If you don't have
  the DOS version, you will be glad to know that the SMC setup/driver
  disks are available at the dorm.rutgers.edu site mentioned above.  Of
  course, you have to have an EEPROM card to use this utility.  Old, old
  wd8003 cards, and some wd8013 clones use jumpers to set up the card
  instead.

  The Digital EtherWorks 3 card can be configured in a similar fashion
  to the DOS program NICSETUP.EXE. David C. Davies wrote this and other
  tools for the EtherWorks 3 in conjunction with the driver. Look on
  sunsite.unc.edu in the directory /pub/linux/system/Network/management
  for the file that is named ewrk3tools-X.XX.tar.gz.

  Some Nat Semi DP83905 implementations (such as the AT/LANTIC and the
  NE2000+) are software configurable. (Note that this card can also
  emulate a wd8013!) You can get the file /pub/linux/setup/atlantic.c
  from Donald's ftp server, cesdis.gsfc.nasa.gov to configure this card.
  Be careful when configuring NE2000+ cards, as you can give them bad
  setting values which will require you to open the case and switch a
  jumper to force it back to sane settings.


  The 3Com Etherlink III family of cards (i.e. 3c5x9) can be configured
  by using another config utility from Donald.  You can get the file
  /pub/linux/setup/3c5x9setup.c from Donald's ftp server,
  cesdis.gsfc.nasa.gov to configure these cards. (Note that the DOS
  3c5x9B config utility may have more options pertaining to the new
  ``B'' series of the Etherlink III family.)




  7.2.  Diagnostic Programs for Ethernet Cards


  Any of the diagnostic programs that Donald has written can be obtained
  from this URL.

  Ethercard Diagnostics
  <http://cesdis.gsfc.nasa.gov/pub/linux/diag/diagnostic.html>

  Allied Telesis AT1700 -- look for the file /pub/linux/diag/at1700.c on
  cesdis.gsfc.nasa.gov.

  Cabletron E21XX -- look for the file /pub/linux/diag/e21.c on
  cesdis.gsfc.nasa.gov.

  HP PCLAN+ -- look for the file /pub/linux/diag/hp+.c on
  cesdis.gsfc.nasa.gov.

  Intel EtherExpress -- look for the file /pub/linux/diag/eexpress.c on
  cesdis.gsfc.nasa.gov.

  NE2000 cards -- look for the file /pub/linux/diag/ne2k.c on
  cesdis.gsfc.nasa.gov.

  RealTek (ATP) Pocket adaptor -- look for the file /pub/linux/diag/atp-
  diag.c on cesdis.gsfc.nasa.gov.

  All Other Cards -- try typing cat /proc/net/dev and see what useful
  info the kernel has on the card in question.


  8.  Technical Information


  For those who want to play with the present drivers, or try to make up
  their own driver for a card that is presently unsupported, this
  information should be useful. If you do not fall into this category,
  then perhaps you will want to skip this section.


  8.1.  Probed Addresses


  While trying to determine what ethernet card is there, the following
  addresses are autoprobed, assuming the type and specs of the card have
  not been set in the kernel. The file names below are in
  /usr/src/linux/drivers/net/









  ______________________________________________________________________
          3c501.c         0x280, 0x300
          3c503.c:        0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2a0, 0x2e0
          3c505.c:        0x300, 0x280, 0x310
          3c507.c:        0x300, 0x320, 0x340, 0x280
          3c509.c:        Special ID Port probe
          apricot.c       0x300
          at1700.c:       0x300, 0x280, 0x380, 0x320, 0x340, 0x260, 0x2a0, 0x240
          atp.c:          0x378, 0x278, 0x3bc
          depca.c         0x300, 0x200
          de600.c:        0x378
          de620.c:        0x378
          eexpress.c:     0x300, 0x270, 0x320, 0x340
          hp.c:           0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240
          hp-plus.c       0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340
          lance.c:        0x300, 0x320, 0x340, 0x360
          ne.c:           0x300, 0x280, 0x320, 0x340, 0x360
          ni52.c          0x300, 0x280, 0x360, 0x320, 0x340
          ni65.c          0x300, 0x320, 0x340, 0x360
          smc-ultra.c:    0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380
          wd.c:           0x300, 0x280, 0x380, 0x240
  ______________________________________________________________________



  There are some NE2000 clone ethercards out there that are waiting
  black holes for autoprobe drivers. While many NE2000 clones are safe
  until they are enabled, some can't be reset to a safe mode.  These
  dangerous ethercards will hang any I/O access to their `dataports'.
  The typical dangerous locations are:

  ______________________________________________________________________
          Ethercard jumpered base     Dangerous locations (base + 0x10 - 0x1f)
                  0x300 *                         0x310-0x317
                  0x320                           0x330-0x337
                  0x340                           0x350-0x357
                  0x360                           0x370-0x377
  ______________________________________________________________________



  * The 0x300 location is the traditional place to put an ethercard, but
  it's also a popular place to put other devices (often SCSI
  controllers). The 0x320 location is often the next one chosen, but
  that's bad for for the AHA1542 driver probe. The 0x360 location is
  bad, because it conflicts with the parallel port at 0x378.  If you
  have two IDE controllers, or two floppy controlers, then 0x360 is also
  a bad choice, as a NE2000 card will clobber them as well.

  Note that kernels > 1.1.7X keep a log of who uses which i/o ports, and
  will not let a driver use i/o ports registered by an earlier driver.
  This may result in probes silently failing.  You can view who is using
  what i/o ports by typing cat /proc/ioports if you have the proc
  filesystem enabled.

  To avoid these lurking ethercards, here are the things you can do:


  o  Probe for the device's BIOS in memory space. This is easy and
     always safe, but it only works for cards that always have BIOSes,
     like primary SCSI controllers.

  o  Avoid probing any of the above locations until you think you've
     located your device. The NE2000 clones have a reset range from
     <base>+0x18 to <base>+0x1f that will read as 0xff, so probe there
     first if possible. It's also safe to probe in the 8390 space at
     <base>+0x00 - <base>+0x0f, but that area will return quasi-random
     values

  o  If you must probe in the dangerous range, for instance if your
     target device has only a few port locations, first check that there
     isn't an NE2000 there. You can see how to do this by looking at the
     probe code in /usr/src/linux/net/inet/ne.c

  o  Use the `reserve' boot time argument to protect volatile areas from
     being probed. See the information on using boot time arguments with
     LILO in ``The reserve command''


  8.2.  Writing a Driver



  The only thing that one needs to use an ethernet card with Linux is
  the appropriate driver. For this, it is essential that the
  manufacturer will release the technical programming information to the
  general public without you (or anyone) having to sign your life away.
  A good guide for the likelihood of getting documentation (or, if you
  aren't writing code, the likelihood that someone else will write that
  driver you really, really need) is the availability of the Crynwr (nee
  Clarkson) packet driver. Russ Nelson runs this operation, and has been
  very helpful in supporting the development of drivers for Linux. Net-
  surfers can try this URL to look up Russ' software.

  Russ Nelson's Packet Drivers <http://www.crynwr.com/crynwr/home.html>

  Given the documentation, you can write a driver for your card and use
  it for Linux (at least in theory).  Keep in mind that some old
  hardware that was designed for XT type machines will not function very
  well in a multitasking environment such as Linux. Use of these will
  lead to major problems if your network sees a reasonable amount of
  traffic.

  Most cards come with drivers for MS-DOS interfaces such as NDIS and
  ODI, but these are useless for Linux. Many people have suggested
  directly linking them in or automatic translation, but this is nearly
  impossible. The MS-DOS drivers expect to be in 16 bit mode and hook
  into `software interrupts', both incompatible with the Linux kernel.
  This incompatibility is actually a feature, as some Linux drivers are
  considerably better than their MS-DOS counterparts. The `8390' series
  drivers, for instance, use ping-pong transmit buffers, which are only
  now being introduced in the MS-DOS world.

  (Ping-pong Tx buffers means using at least 2 max-size packet buffers
  for Tx packets. One is loaded while the card is transmitting the
  other. The second is then sent as soon as the first finished, and so
  on. In this way, most cards are able to continuously send back-to-back
  packets onto the wire.)

  OK. So you have decided that you want to write a driver for the Foobar
  Ethernet card, as you have the programming information, and it hasn't
  been done yet. (...these are the two main requirements ;-) You should
  start with the skeleton network driver that is provided with the Linux
  kernel source tree. It can be found in the file
  /usr/src/linux/drivers/net/skeleton.c in all recent kernels.



  8.3.  Driver interface to the kernel



  Here are some notes on the functions that you would have to write if
  creating a new driver. Reading this in conjunction with the above
  skeleton driver may help clear things up.



  8.3.1.  Probe


  Called at boot to check for existence of card. Best if it can check
  un-obtrsively by reading from memory, etc. Can also read from i/o
  ports. Initial writing to i/o ports in a probe is not good as it may
  kill another device.  Some device initialization is usually done here
  (allocating i/o space, IRQs,filling in the dev->??? fields etc.)  You
  need to know what io ports/mem the card can be configured to, how to
  enable shared memory (if used) and how to select/enable interrupt
  generation, etc.


  8.3.2.  Interrupt handler


  Called by the kernel when the card posts an interrupt.  This has the
  job of determining why the card posted an interrupt, and acting
  accordingly. Usual interrupt conditions are data to be rec'd, transmit
  completed, error conditions being reported. You need to know any
  relevant interrupt status bits so that you can act accordingly.


  8.3.3.  Transmit function


  Linked to dev->hard_start_xmit() and is called by the kernel when
  there is some data that the kernel wants to put out over the device.
  This puts the data onto the card and triggers the transmit. You need
  to know how to bundle the data and how to get it onto the card (shared
  memory copy, PIO transfer, DMA?) and in the right place on the card.
  Then you need to know how to tell the card to send the data down the
  wire, and (possibly) post an interrupt when done.  When the hardware
  can't accept additional packets it should set the dev->tbusy flag.
  When additional room is available, usually during a transmit-complete
  interrupt, dev->tbusy should be cleared and the higher levels informed
  with mark_bh(INET_BH).


  8.3.4.  Receive function


  Called by the kernel interrupt handler when the card reports that
  there is data on the card. It pulls the data off the card, packages it
  into a sk_buff and lets the kernel know the data is there for it by
  doing a netif_rx(sk_buff). You need to know how to enable interrupt
  generation upon Rx of data, how to check any relevant Rx status bits,
  and how to get that data off the card (again sh mem, PIO, DMA, etc.)


  8.3.5.  Open function


  linked to dev->open and called by the networking layers when somebody
  does ifconfig eth0 up - this puts the device on line and enables it
  for Rx/Tx of data. Any special initialization incantations that were
  not done in the probe sequence (enabling IRQ generation, etc.)  would
  go in here.


  8.3.6.  Close function (optional)


  This puts the card in a sane state when someone does ifconfig eth0
  down.  It should free the IRQs and DMA channels if the hardware
  permits, and turn off anything that will save power (like the
  transceiver).


  8.3.7.  Miscellaneous functions


  Things like a reset function, so that if things go south, the driver
  can try resetting the card as a last ditch effort.  Usually done when
  a Tx times out or similar. Also a function to read the statistics
  registers of the card if so equipped.


  8.4.  Interrupts and Linux


  There are two kinds of interrupt handlers in Linux: fast ones and slow
  ones. You decide what kind you are installing by the flags you pass to
  irqaction(). The fast ones, such as the serial interrupt handler, run
  with _all_ interrupts disabled. The normal interrupt handlers, such as
  the one for ethercard drivers, runs with other interrupts enabled.

  There is a two-level interrupt structure. The `fast' part handles the
  device register, removes the packets, and perhaps sets a flag.  After
  it is done, and interrupts are re-enabled, the slow part is run if the
  flag is set.

  The flag between the two parts is set by:


       mark_bh(INET_BH);


  Usually this flag is set within dev_rint() during a received-packet
  interrupt, and set directly by the device driver during a transmit-
  complete interrupt.

  You might wonder why all interrupt handlers cannot run in `normal
  mode' with other interrupts enabled. Ross Biro uses this scenario to
  illustrate the problem:


  o  You get a serial interrupt, and start processing it.  The serial
     interrupt is now masked.

  o  You get a network interrupt, and you start transferring a maximum-
     sized 1500 byte packet from the card.

  o  Another character comes in, but this time the interrupts are
     masked!

  The `fast' interrupt structure solves this problem by allowing
  bounded-time interrupt handlers to run without the risk of leaving
  their interrupt lines masked by another interrupt request.

  There is an additional distinction between fast and slow interrupt
  handlers -- the arguments passed to the handler. A `slow' handler is
  defined as



  ______________________________________________________________________

                  static void
                  handle_interrupt(int reg_ptr)
                  {
                      int irq = -(((struct pt_regs *)reg_ptr)->orig_eax+2);
                      struct device *dev = irq2dev_map[irq];
                  ...
  ______________________________________________________________________



  While a fast handler gets the interrupt number directly


  ______________________________________________________________________

                  static void
                  handle_fast_interrupt(int irq)
                  {
                  ...
  ______________________________________________________________________



  A final aspect of network performance is latency. The only board that
  really addresses this is the 3c509, which allows a predictive
  interrupt to be posted. It provides an interrupt response timer so
  that the driver can fine-tune how early an interrupt is generated.


  8.5.  Programming the Intel chips (i82586 and i82593)


  These chips are used on a number of cards, namely the 3c507 ('86), the
  Intel EtherExpress 16 ('86), Microdyne's exos205t ('86), the Z-Note
  ('93), and the Racal-Interlan ni5210 ('86).

  Russ Nelson writes: `Most boards based on the 82586 can reuse quite a
  bit of their code.  More, in fact, than the 8390-based adapters. There
  are only three differences between them:


  o  The code to get the Ethernet address,

  o  The code to trigger CA on the 82586, and

  o  The code to reset the 82586.

  The Intel EtherExpress 16 is an exception, as it I/O maps the 82586.
  Yes, I/O maps it. Fairly clunky, but it works.

  Garrett Wollman did an AT&T driver for BSD that uses the BSD
  copyright. The latest version I have (Sep '92) only uses a single
  transmit buffer. You can and should do better than this if you've got
  the memory. The AT&T and 3c507 adapters do; the ni5210 doesn't.

  The people at Intel gave me a very big clue on how you queue up
  multiple transmit packets. You set up a list of NOP-> XMIT-> NOP->
  XMIT-> NOP-> XMIT-> beginning) blocks, then you set the `next' pointer
  of all the NOP blocks to themselves. Now you start the command unit on
  this chain. It continually processes the first NOP block. To transmit
  a packet, you stuff it into the next transmit block, then point the
  NOP to it. To transmit the next packet, you stuff the next transmit
  block and point the previous NOP to it. In this way, you don't have to
  wait for the previous transmit to finish, you can queue up multiple
  packets without any ambiguity as to whether it got accepted, and you
  can avoid the command unit start-up delay.'


  8.6.  Technical information from 3Com


  If you are interested in working on drivers for 3Com cards, you can
  get technical documentation from 3Com. Cameron has been kind enough to
  tell us how to go about it below:

  3Com's Ethernet Adapters are documented for driver writers in our
  `Technical References' (TRs). These manuals describe the programmer
  interfaces to the boards but they don't talk about the diagnostics,
  installation programs, etc that end users can see.

  The Network Adapter Division marketing department has the TRs to give
  away. To keep this program efficient, we centralized it in a thing
  called `CardFacts.' CardFacts is an automated phone system. You call
  it with a touch-tone phone and it faxes you stuff. To get a TR, call
  CardFacts at 408-727-7021. Ask it for Developer's Order Form, document
  number 9070. Have your fax number ready when you call. Fill out the
  order form and fax it to 408-764-5004.  Manuals are shipped by Federal
  Express 2nd Day Service.

  After you get a manual, if you still can't figure out how to program
  the board, try our `CardBoard' BBS at 1-800-876-3266, and if you can't
  do that, write Andy_Chan@3Mail.3com.com and ask him for alternatives.
  If you have a real stumper that nobody has figured out yet, the fellow
  who needs to know about it is Steve_Lebus@3Mail.3com.com.

  There are people here who think we are too free with the manuals, and
  they are looking for evidence that the system is too expensive, or
  takes too much time and effort. That's why it's important to try to
  use CardFacts before you start calling and mailing the people I named
  here.

  There are even people who think we should be like Diamond and Xircom,
  requiring tight `partnership' with driver writers to prevent poorly
  performing drivers from getting written. So far, 3Com customers have
  been really good about this, and there's no problem with the level of
  requests we've been getting. We need your continued cooperation and
  restraint to keep it that way.


          Cameron Spitzer, 408-764-6339
          3Com NAD
          Santa Clara
          work: camerons@nad.3com.com
          home: cls@truffula.sj.ca.us





  8.7.  Notes on AMD PCnet / LANCE Based cards


  The AMD LANCE (Local Area Network Controller for Ethernet) was the
  original offering, and has since been replaced by the `PCnet-ISA'
  chip, otherwise known as the 79C960.  A relatively new chip from AMD,
  the 79C960, is the heart of many new cards being released at present.
  Note that the name `LANCE' has stuck, and some people will refer to
  the new chip by the old name. Dave Roberts of the Network Products
  Division of AMD was kind enough to contribute the following
  information regarding this chip:
  `As for the architecture itself, AMD developed it originally and
  reduced it to a single chip -- the PCnet(tm)-ISA -- over a year ago.
  It's been selling like hotcakes ever since.

  Functionally, it is equivalent to a NE1500. The register set is
  identical to the old LANCE with the 1500/2100 architecture additions.
  Older 1500/2100 drivers will work on the PCnet-ISA.  The NE1500 and
  NE2100 architecture is basically the same.  Initially Novell called it
  the 2100, but then tried to distinguish between coax and 10BASE-T
  cards. Anything that was 10BASE-T only was to be numbered in the 1500
  range. That's the only difference.

  Many companies offer PCnet-ISA based products, including HP, Racal-
  Datacom, Allied Telesis, Boca Research, Kingston Technology, etc.  The
  cards are basically the same except that some manufacturers have added
  `jumperless' features that allow the card to be configured in
  software. Most have not. AMD offers a standard design package for a
  card that uses the PCnet-ISA and many manufacturers use our design
  without change.  What this means is that anybody who wants to write
  drivers for most PCnet-ISA based cards can just get the data-sheet
  from AMD. Call our literature distribution center at (800)222-9323 and
  ask for the Am79C960, PCnet-ISA data sheet. It's free.

  A quick way to understand whether the card is a `stock' card is to
  just look at it. If it's stock, it should just have one large chip on
  it, a crystal, a small IEEE address PROM, possibly a socket for a boot
  ROM, and a connector (1, 2, or 3, depending on the media options
  offered). Note that if it's a coax card, it will have some transceiver
  stuff built onto it as well, but that should be near the connector and
  away from the PCnet-ISA.'

  There is also some info regarding the LANCE chip in the file lance.c
  which is included in the standard kernel.

  A note to would-be card hackers is that different LANCE
  implementations do `restart' in different ways. Some pick up where
  they left off in the ring, and others start right from the beginning
  of the ring, as if just initialised. This is a concern when setting
  the multicast list.


  8.8.  Multicast and Promiscuous Mode


  Another one of the things Donald has worked on is implementing
  multicast and promiscuous mode hooks.  All of the released (i.e. not
  ALPHA) ISA drivers now support promiscuous mode.

  Donald writes: `At first I was planning to do it while implementing
  either the /dev/* or DDI interface, but that's not really the correct
  way to do it. We should only enable multicast or promiscuous modes
  when something wants to look at the packets, and shut it down when
  that application is finished, neither of which is strongly related to
  when the hardware is opened or released.

  I'll start by discussing promiscuous mode, which is conceptually easy
  to implement. For most hardware you only have to set a register bit,
  and from then on you get every packet on the wire. Well, it's almost
  that easy; for some hardware you have to shut the board (potentially
  dropping a few packet), reconfigure it, and then re-enable the
  ethercard. This is grungy and risky, but the alternative seems to be
  to have every application register before you open the ethercard at
  boot-time.

  OK, so that's easy, so I'll move on something that's not quite so
  obvious: Multicast. It can be done two ways:
  1. Use promiscuous mode, and a packet filter like the Berkeley packet
     filter (BPF). The BPF is a pattern matching stack language, where
     you write a program that picks out the addresses you are interested
     in. Its advantage is that it's very general and programmable. Its
     disadvantage is that there is no general way for the kernel to
     avoid turning on promiscuous mode and running every packet on the
     wire through every registered packet filter. See ``The Berkeley
     Packet Filter'' for more info.


  2. Using the built-in multicast filter that most etherchips have.

  I guess I should list what a few ethercards/chips provide:



          Chip/card  Promiscuous  Multicast filter
          ----------------------------------------
          Seeq8001/3c501  Yes     Binary filter (1)
          3Com/3c509      Yes     Binary filter (1)
          8390            Yes     Autodin II six bit hash (2) (3)
          LANCE           Yes     Autodin II six bit hash (2) (3)
          i82586          Yes     Hidden Autodin II six bit hash (2) (4)





  1. These cards claim to have a filter, but it's a simple yes/no
     `accept all multicast packets', or `accept no multicast packets'.

  2. AUTODIN II is the standard ethernet CRC (checksum) polynomial. In
     this scheme multicast addresses are hashed and looked up in a hash
     table. If the corresponding bit is enabled, this packet is
     accepted. Ethernet packets are laid out so that the hardware to do
     this is trivial -- you just latch six (usually) bits from the CRC
     circuit (needed anyway for error checking) after the first six
     octets (the destination address), and use them as an index into the
     hash table (six bits -- a 64-bit table).


  3. These chips use the six bit hash, and must have the table computed
     and loaded by the host. This means the kernel must include the CRC
     code.


  4. The 82586 uses the six bit hash internally, but it computes the
     hash table itself from a list of multicast addresses to accept.

  Note that none of these chips do perfect filtering, and we still need
  a middle-level module to do the final filtering. Also note that in
  every case we must keep a complete list of accepted multicast
  addresses to recompute the hash table when it changes.

  My first pass at device-level support is detailed in the outline
  driver skeleton.c

  It looks like the following:








  ______________________________________________________________________
          #ifdef HAVE_MULTICAST
          static void set_multicast_list(struct device *dev, int num_addrs,
                           void *addrs);
          #endif
          .
          .

          ethercard_open() {
          ...
          #ifdef HAVE_MULTICAST
                  dev->set_multicast_list = &set_multicast_list;
          #endif
          ...

          #ifdef HAVE_MULTICAST
          /* Set or clear the multicast filter for this adaptor.
             num_addrs -- -1      Promiscuous mode, receive all packets
             num_addrs -- 0       Normal mode, clear multicast list
             num_addrs > 0        Multicast mode, receive normal and
                  MC packets, and do best-effort filtering.
           */
          static void
          set_multicast_list(struct device *dev, int num_addrs, void *addrs)
          {
          ...
  ______________________________________________________________________



  Any comments, criticism, etc. are welcome.'


  8.9.  The Berkeley Packet Filter (BPF)


  The general idea of the developers is that the BPF functionality
  should not be provided by the kernel, but should be in a (hopefully
  little-used) compatibility library.

  For those not in the know: BPF (the Berkeley Packet Filter) is an
  mechanism for specifying to the kernel networking layers what packets
  you are interested in. It's implemented as a specialized stack
  language interpreter built into a low level of the networking code. An
  application passes a program written in this language to the kernel,
  and the kernel runs the program on each incoming packet. If the kernel
  has multiple BPF applications, each program is run on each packet.

  The problem is that it's difficult to deduce what kind of packets the
  application is really interested in from the packet filter program, so
  the general solution is to always run the filter. Imagine a program
  that registers a BPF program to pick up a low data-rate stream sent to
  a multicast address.  Most ethernet cards have a hardware multicast
  address filter implemented as a 64 entry hash table that ignores most
  unwanted multicast packets, so the capability exists to make this a
  very inexpensive operation. But with the BFP the kernel must switch
  the interface to promiscuous mode, receive _all_ packets, and run them
  through this filter. This is work, BTW, that's very difficult to
  account back to the process requesting the packets.


  9.  Networking with a Laptop/Notebook Computer


  There are currently only a few ways to put your laptop on a network.
  You can use the SLIP code (and run at serial line speeds); you can buy
  one of the few laptops that come with a NE2000-compatible ethercard;
  you can get a notebook with a supported PCMCIA slot built-in; you can
  get a laptop with a docking station and plug in an ISA ethercard; or
  you can use a parallel port Ethernet adapter such as the D-Link
  DE-600.


  9.1.  Using SLIP


  This is the cheapest solution, but by far the most difficult. Also,
  you will not get very high transmission rates. Since SLIP is not
  really related to ethernet cards, it will not be discussed further
  here. See the NET-2 Howto.


  9.2.  Built in NE2000


  This solution severely limits your laptop choices and is fairly
  expensive. Be sure to read the specifications carefully, as you may
  find that you will have to buy an additional non-standard transceiver
  to actually put the machine on a network. A good idea might be to boot
  the notebook with a kernel that has ne2000 support, and make sure it
  gets detected and works before you lay down your cash.



  9.3.  PCMCIA Support


  As this area of Linux development is fairly young, I'd suggest that
  you join the LAPTOPS mailing channel. See ``Mailing lists...''  which
  describes how to join a mailing list channel.

  Try and determine exactly what hardware you have (ie. card
  manufacturer, PCMCIA chip controller manufacturer) and then ask on the
  LAPTOPS channel. Regardless, don't expect things to be all that
  simple.  Expect to have to fiddle around a bit, and patch kernels,
  etc.  Maybe someday you will be able to type `make config' 8-)

  At present, the two PCMCIA chipsets that are supported are the
  Databook TCIC/2 and the intel i82365.

  There is a number of programs on tsx-11.mit.edu in
  /pub/linux/packages/laptops/ that you may find useful. These range
  from PCMCIA Ethercard drivers to programs that communicate with the
  PCMCIA controller chip. Note that these drivers are usually tied to a
  specific PCMCIA chip (ie. the intel 82365 or the TCIC/2)

  For NE2000 compatible cards, some people have had success with just
  configuring the card under DOS, and then booting linux from the DOS
  command prompt via loadlin.

  For those that are net-surfing you can try:

  Don's PCMCIA Stuff <http://cesdis.gsfc.nasa.gov/linux/pcmcia.html>

  Anyway, the PCMCIA driver problem isn't specific to the Linux world.
  It's been a real disaster in the MS-DOS world. In that world people
  expect the hardware to work if they just follow the manual.  They
  might not expect it to interoperate with any other hardware or
  software, or operate optimally, but they do expect that the software
  shipped with the product will function. Many PCMCIA adaptors don't
  even pass this test.

  Things are looking up for Linux users that want PCMCIA support, as
  substantial progress is being made. Pioneering this effort is David
  Hinds. His latest PCMCIA support package can be obtained from cb-
  iris.stanford.edu in the directory /pub/pcmcia/. Look for a file like
  pcmcia-cs-X.Y.Z.tgz where X.Y.Z will be the latest version number.
  This is most likely uploaded to tsx-11.mit.edu as well.

  Note that Donald's PCMCIA enabler works as a user-level process, and
  David Hinds' is a kernel-level solution.  You may be best served by
  David's package as it is much more widely used.


  9.4.  ISA Ethercard in the Docking Station.


  Docking stations for laptops typically cost about $250 and provide two
  full-size ISA slots, two serial and one parallel port. Most docking
  stations are powered off of the laptop's batteries, and a few allow
  adding extra batteries in the docking station if you use short ISA
  cards. You can add an inexpensive ethercard and enjoy full-speed
  ethernet performance.


  9.5.  Pocket / parallel port adaptors.


  The `pocket' ethernet adaptors may also fit your need.  Until recently
  they actually costed more than a docking station and cheap ethercard,
  and most tie you down with a wall-brick power supply.  At present, you
  can choose from the D-Link, or the RealTek adaptor.  Most other
  companies, especially Xircom, (see ``Xircom'') treat the programming
  information as a trade secret, so support will likely be slow in
  coming. (if ever!)

  Note that the transfer speed will not be all that great (perhaps
  100kB/s tops?) due to the limitations of the parallel port interface.

  See ``DE-600 / DE-620'' and ``RealTek'' for supported pocket adaptors.

  You can sometimes avoid the wall-brick with the adaptors by buying or
  making a cable that draws power from the laptop's keyboard port. (See
  ``keyboard power'')


  10.  Miscellaneous.


  Any other associated stuff that didn't fit in anywhere else gets
  dumped here. It may not be relevant, and it may not be of general
  interest but it is here anyway.


  10.1.  Passing Ethernet Arguments to the Kernel


  Here are two generic kernel commands  that can be passed to the kernel
  at boot time. This can be done with LILO, loadlin, or any other
  booting utility that accepts optional arguments.

  For example, if the command was `blah' and it expected 3 arguments
  (say 123, 456, and 789) then, with LILO, you would use:

  LILO: linux blah=123,456,789

  Note: PCI cards have their i/o and IRQ assigned by the BIOS at boot.
  This means that any boot time arguments for a PCI card's IRQ or i/o
  ports are usually ignored.

  For more information on (and a complete list of) boot time arguments,
  please see the BootPrompt-HOWTO
  <http://sunsite.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html>


  10.1.1.  The ether command


  In its most generic form, it looks something like this:


       ether=IRQ,BASE_ADDR,PARAM_1,PARAM_2,NAME


  All arguments are optional.  The first non-numeric argument is taken
  as the NAME.

  IRQ: Obvious.  An IRQ value of `0' (usually the default) means to
  autoIRQ.  It's a historical accident that the IRQ setting is first
  rather than the base_addr -- this will be fixed whenever something
  else changes.

  BASE_ADDR: Also obvious.  A value of `0' (usually the default) means
  to probe a card-type-specific address list for an ethercard.

  PARAM_1: It was orginally used as an override value for the memory
  start for a shared-memory ethercard, like the WD80*3.  Some drivers
  use the low four bits of this value to set the debug message level.  0
  -- default, 1-7 -- level 1..7, (7 is maximum verbosity)  8 -- level 0
  (no messages). Also, the LANCE driver uses the low four bits of this
  value to select the DMA channel.  Otherwise it uses auto-DMA.

  PARAM_2: The 3c503 driver uses this to select between the internal and
  external transceivers.  0 -- default/internal, 1 -- AUI external.  The
  Cabletron E21XX card also uses the low 4 bits of PARAM_2 to select the
  output media. Otherwise it detects automatically.

  NAME: Selects the network device the values refer to.  The standard
  kernel uses the names `eth0', `eth1', `eth2' and `eth3' for bus-
  attached ethercards, and `atp0' for the parallel port `pocket'
  ethernet adaptor. The arcnet driver uses `arc0' as its name.  The
  default setting is for a single ethercard to be probed for as `eth0'.
  Multiple cards can only be enabled by explicitly setting up their base
  address using these LILO parameters.  The 1.0 kernel has LANCE-based
  ethercards as a special case.  LILO arguments are ignored, and LANCE
  cards are always assigned `eth<n>' names starting at `eth0'.
  Additional non-LANCE ethercards must be explicitly assigned to
  `eth<n+1>', and the usual `eth0' probe disabled with something like
  `ether=0,-1,eth0'.  ( Yes, this is bug. )


  10.1.2.  The reserve command


  This next lilo command is used just like `ether=' above, ie. it is
  appended to the name of the boot select specified in lilo.conf


       reserve=IO-base,extent{,IO-base,extent...}


  In some machines it may be necessary to prevent device drivers from
  checking for devices (auto-probing) in a specific region. This may be
  because of poorly designed hardware that causes the boot to freeze
  (such as some ethercards), hardware that is mistakenly identified,
  hardware whose state is changed by an earlier probe, or merely
  hardware you don't want the kernel to initialize.

  The reserve boot-time argument addresses this problem by specifying an
  I/O port region that shouldn't be probed. That region is reserved in
  the kernel's port registration table as if a device has already been
  found in that region. Note that this mechanism shouldn't be necessary
  on most machines. Only when there is a problem or special case would
  it be necessary to use this.

  The I/O ports in the specified region are protected against device
  probes. This was put in to be used when some driver was hanging on a
  NE2000, or misidentifying some other device as its own.  A correct
  device driver shouldn't probe a reserved region, unless another boot
  argument explicitly specifies that it do so.  This implies that
  reserve will most often be used with some other boot argument. Hence
  if you specify a reserve region to protect a specific device, you must
  generally specify an explicit probe for that device. Most drivers
  ignore the port registration table if they are given an explicit
  address.

  For example, the boot line


       LILO: linux  reserve=0x300,32  ether=0,0x300,eth0


  keeps all device drivers except the ethercard drivers from probing
  0x300-0x31f.

  As usual with boot-time specifiers there is an 11 parameter limit,
  thus you can only specify 5 reserved regions per reserve keyword.
  Multiple reserve specifiers will work if you have an unusually
  complicated request.


  10.2.  Using the Ethernet Drivers as Modules


  At present, all the modules are put in the subdirectory modules in
  your Linux kernel source tree (usually in the form of symbolic links).
  To actually generate the modules, you have to type make modules after
  you have finished building the kernel proper. Earlier kernels built
  them automatically, which wasn't fair to those compiling on 4MB
  386sx-16 machines.

  Most modules accept parameters like io=0x340 and irq=12 on the insmod
  command line. It is STRONGLY ADVISED that you supply these parameters
  to avoid probing for the card. Unlike PCI and EISA devices, there is
  no real safe way to do auto-probing for ISA devices, and so it should
  be avoided when using drivers as modules.

  A list of all the parameters that each module accepts can be found in
  the file:

  /usr/src/linux/Documentation/networking/net-modules.txt

  It is recommended that you read that to find out what options you can
  use for your particular card.

  Once you have figured out the arguments/options you are going to use,
  you can insert the module by typing as root:



  ______________________________________________________________________
          insmod mod_name.o [io=val1[,val2,...]] [irq=val7[,val8,...]]
  ______________________________________________________________________


  The comma separated value lists are used for modules that have the
  capability to handle multiple devices from a single module, such as
  all the 8390 drivers, and the PLIP driver.

  See the insmod(8) manual page for information on passing arguments to
  the module as it is being loaded.  The command lsmod will show you
  what modules are loaded, and rmmod will remove them.

  Once a module is inserted, then you can use it just like normal, and
  give ifconfig commands. If you set up your networking at boot, then
  make sure your /etc/rc* files run the insmod command(s) before getting
  to the ifconfig command.

  Also note that a busy module can't be removed. That means that you
  will have to ifconfig eth0 down  (shut down the ethernet card) before
  you can remove the module(s).


  10.2.1.  8390 Based Cards as Modules


  The present list of 8390 based drivers is: 3c503, ac3200, e2100, hp,
  hp-plus, ne, smc-ultra and wd. These cards were not supported as
  modules for kernel versions prior to 1.3.42.  (This does not include
  some of the separately distributed PCMCIA drivers (e.g. de-650) that
  are also 8390 based, that have had module support for quite some time
  now.)

  If you have an 8390 based card, you may have to insert two modules,
  8390.o and then the module for your card.  If 8390 support has been
  built into your kernel, then you will not need to insert the 8390
  module. (8390 support is built in whenever an 8390 based card is
  selected to be built into the kernel.) Doing a cat /proc/ksyms | grep
  8390 will tell you if 8390 support is in your kernel.

  For an 8390 based card, you will have to remove the card module before
  removing the 8390 module, as the 8390 module is used by the card
  module, and thus marked as busy.


  The 8390 series of network drivers now support multiple card systems
  without reloading the same module multiple times (memory efficient!)
  This is done by specifying multiple comma separated values, such as:


  ______________________________________________________________________
          insmod 3c503.o io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
  ______________________________________________________________________



  The above would have the one module controlling four 3c503 cards, with
  card 2 and 4 using external transcievers.

  It is *STRONGLY RECOMMENDED* that you supply "io=" instead of
  autoprobing.  If an "io=" argument is not supplied, then the ISA 8390
  drivers will complain about autoprobing being not recommended, and
  begrudgingly autoprobe for a *SINGLE CARD ONLY* -- if you want to use
  multiple cards you *have* to supply an "io=0xNNN,0xQQQ,..." argument.


  The ne module is an exception to the above. A NE2000 is essentially an
  8390 chip, some bus glue and some RAM.  Because of this, the ne probe
  is more invasive than the rest, and so at boot we make sure the ne
  probe is done last of all the 8390 cards (so that it won't trip over
  other 8390 based cards) With modules we can't ensure that all other
  non-ne 8390 cards have already been found. Because of this, the ne
  module REQUIRES an io=0xNNN argument passed in via insmod. It will
  refuse to autoprobe.

  It is also worth noting that auto-IRQ probably isn't as reliable
  during the flurry of interrupt activity on a running machine. Cards
  such as the ne2000 that can't get the IRQ setting from an EEPROM or
  configuration register are probably best supplied with an irq=M
  argument as well. The file

  /usr/src/linux/Documentation/networking/net-modules.txt

  also lists how the interrupt settings are determined for the various
  cards if an irq=N value is not given.


  10.3.  Mailing Lists and the Linux Newsgroups


  If you have questions about your ethernet card, please READ this
  document first. You may also want to join the NET channel of the Linux
  mailing lists by sending mail to majordomo@vger.rutgers.edu to get
  help with what lists are available, and how to join them.

  Furthermore keep in mind that the NET channel is for development
  discussions only. General questions on how to configure your system
  should be directed to comp.os.linux.setup unless you are actively
  involved in the development of part of the networking for Linux.  We
  ask that you please respect this general guideline for content.

  Also, the news groups comp.sys.ibm.pc.hardware.networking and
  comp.dcom.lans.ethernet should be used for questions that are not
  Linux specific.


  10.4.  Related Documentation


  Much of this info came from saved postings from the comp.os.linux
  groups, which shows that it is a valuable resource of information.
  Other useful information came from a bunch of small files by Donald
  himself. Of course, if you are setting up an Ethernet card, then you
  will want to read the NET-2 Howto so that you can actually configure
  the software you will use.  Also, if you fancy yourself as a bit of a
  hacker, you can always scrounge some additional info from the driver
  source files as well. There is usually a paragraph or two in there
  describing any important points before any actual code starts..

  For those looking for information that is not specific in any way to
  Linux (i.e. what is 10BaseT, what is AUI, what does a hub do, etc.)  I
  strongly recommend the Ethernet-FAQ  that is posted regularly to the
  newsgroup comp.dcom.lans.ethernet.  You can grab it from the following
  URL:

  Ethernet FAQ
  <ftp://dorm.rutgers.edu/pub/novell/info_and_docs/Ethernet.FAQ>

  You can also have a look at the `Ethernet-HomePage' so to speak, which
  is at the following URL:


  Ethernet-HomePage <http://wwwhost.ots.utexas.edu/ethernet/ethernet-
  home.html>


  10.5.  Contributors


  Other people who have contributed (directly or indirectly) to the
  Ethernet-Howto are, in alphabetical order:


          Ross Biro               <bir7@leland.stanford.edu>
          Alan Cox                <iialan@www.linux.org.uk>
          David C. Davies         <davies@wanton.enet.dec.com>
          Bjorn Ekwall            <bj0rn@blox.se>
          David Hinds             <dhinds@allegro.stanford.edu>
          Michael Hipp            <mhipp@student.uni-tuebingen.de>
          Mike Jagdis             <jaggy@purplet.demon.co.uk>
          Duke Kamstra            <kamstra@ccmail.west.smc.com>
          Russell Nelson          <nelson@crynwr.com>
          Cameron Spitzer         <camerons@NAD.3Com.com>
          Dave Roberts            <david.roberts@amd.com>
          Glenn Talbott           <gt@hprnd.rose.hp.com>




  Many thanks to the above people, and all the other unmentioned testers
  out there.


  10.6.  Closing


  If you have found any glaring typos, or outdated info in this
  document, please let one of us know. It's getting big, and it is easy
  to overlook stuff.

  Thanks,

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

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

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

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

iQCVAwUBML4svXtNTo2suu5NAQH8RAP9Gcene54rMOLhrp1P8w72CO4H7oirHc2d
zZbiAgiecDX9tfvrn+goAu6CLVvQj2IMh29ExWJ2ma+XEmrCqmS4lBK0ygfjBugw
2hR5iEEdJ3J3BpSgHxoIY1Rmmbzyr/rqFn7gbDtXMrHD12yFR9g15L+u32FN9xAD
oL6cHAsE0/0=
=3gPK
-----END PGP SIGNATURE-----