Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

83 files changed, 21285 insertions, 0 deletions

diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
new file mode 100644
index 00000000000..834993d2673
--- /dev/null
+++ b/Documentation/networking/00-INDEX
@@ -0,0 +1,127 @@
+00-INDEX
+        - this file
+3c505.txt
+        - information on the 3Com EtherLink Plus (3c505) driver.
+6pack.txt
+        - info on the 6pack protocol, an alternative to KISS for AX.25
+Configurable
+        - info on some of the configurable network parameters
+DLINK.txt
+        - info on the D-Link DE-600/DE-620 parallel port pocket adapters
+PLIP.txt
+        - PLIP: The Parallel Line Internet Protocol device driver
+README.sb1000
+        - info on General Instrument/NextLevel SURFboard1000 cable modem.
+alias.txt
+        - info on using alias network devices 
+arcnet-hardware.txt
+        - tons of info on ARCnet, hubs, jumper settings for ARCnet cards, etc.
+arcnet.txt
+        - info on the using the ARCnet driver itself.
+atm.txt
+        - info on where to get ATM programs and support for Linux.
+ax25.txt
+        - info on using AX.25 and NET/ROM code for Linux
+baycom.txt
+        - info on the driver for Baycom style amateur radio modems
+bridge.txt
+        - where to get user space programs for ethernet bridging with Linux.
+comx.txt
+        - info on drivers for COMX line of synchronous serial adapters.
+cops.txt
+        - info on the COPS LocalTalk Linux driver
+cs89x0.txt
+        - the Crystal LAN (CS8900/20-based) Ethernet ISA adapter driver
+de4x5.txt
+        - the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
+decnet.txt
+        - info on using the DECnet networking layer in Linux.
+depca.txt
+        - the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver
+dgrs.txt
+        - the Digi International RightSwitch SE-X Ethernet driver
+dmfe.txt
+        - info on the Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver.
+e100.txt
+        - info on Intel's EtherExpress PRO/100 line of 10/100 boards
+e1000.txt
+        - info on Intel's E1000 line of gigabit ethernet boards
+eql.txt
+        - serial IP load balancing
+ethertap.txt
+        - the Ethertap user space packet reception and transmission driver
+ewrk3.txt
+        - the Digital EtherWORKS 3 DE203/4/5 Ethernet driver
+filter.txt
+        - Linux Socket Filtering
+fore200e.txt
+        - FORE Systems PCA-200E/SBA-200E ATM NIC driver info.
+framerelay.txt
+        - info on using Frame Relay/Data Link Connection Identifier (DLCI).
+ip-sysctl.txt
+        - /proc/sys/net/ipv4/* variables
+ip_dynaddr.txt
+        - IP dynamic address hack e.g. for auto-dialup links
+ipddp.txt
+        - AppleTalk-IP Decapsulation and AppleTalk-IP Encapsulation
+iphase.txt
+        - Interphase PCI ATM (i)Chip IA Linux driver info.
+irda.txt
+        - where to get IrDA (infrared) utilities and info for Linux.
+lapb-module.txt
+        - programming information of the LAPB module.
+ltpc.txt
+        - the Apple or Farallon LocalTalk PC card driver
+multicast.txt
+        - Behaviour of cards under Multicast
+ncsa-telnet
+        - notes on how NCSA telnet (DOS) breaks with MTU discovery enabled.
+net-modules.txt
+        - info and "insmod" parameters for all network driver modules.
+netdevices.txt
+        - info on network device driver functions exported to the kernel.
+olympic.txt
+        - IBM PCI Pit/Pit-Phy/Olympic Token Ring driver info.
+policy-routing.txt
+        - IP policy-based routing
+pt.txt
+        - the Gracilis Packetwin AX.25 device driver
+ray_cs.txt
+        - Raylink Wireless LAN card driver info.
+routing.txt
+        - the new routing mechanism
+shaper.txt
+        - info on the module that can shape/limit transmitted traffic.
+sis900.txt
+        - SiS 900/7016 Fast Ethernet device driver info.
+sk98lin.txt
+        - Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit
+          Ethernet Adapter family driver info
+skfp.txt
+        - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info.
+smc9.txt
+        - the driver for SMC's 9000 series of Ethernet cards
+smctr.txt
+        - SMC TokenCard TokenRing Linux driver info.
+tcp.txt
+        - short blurb on how TCP output takes place.
+tlan.txt
+        - ThunderLAN (Compaq Netelligent 10/100, Olicom OC-2xxx) driver info.
+tms380tr.txt
+        - SysKonnect Token Ring ISA/PCI adapter driver info.
+tuntap.txt
+        - TUN/TAP device driver, allowing user space Rx/Tx of packets.
+vortex.txt
+        - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
+wan-router.txt
+        - Wan router documentation
+wanpipe.txt
+        - WANPIPE(tm) Multiprotocol WAN Driver for Linux WAN Router
+wavelan.txt
+        - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver
+x25.txt
+        - general info on X.25 development.
+x25-iface.txt
+        - description of the X.25 Packet Layer to LAPB device interface.
+z8530drv.txt
+        - info about Linux driver for Z8530 based HDLC cards for AX.25
diff --git a/Documentation/networking/3c359.txt b/Documentation/networking/3c359.txt
new file mode 100644
index 00000000000..4af8071a6d1
--- /dev/null
+++ b/Documentation/networking/3c359.txt
@@ -0,0 +1,58 @@
+
+3COM PCI TOKEN LINK VELOCITY XL TOKEN RING CARDS README
+
+Release 0.9.0 - Release   
+        Jul 17th 2000 Mike Phillips 
+
+        1.2.0 - Final
+        Feb 17th 2002 Mike Phillips 
+        Updated for submission to the 2.4.x kernel.
+
+Thanks:
+        Terry Murphy from 3Com for tech docs and support,
+        Adam D. Ligas for testing the driver.
+ 
+Note:
+        This driver will NOT work with the 3C339 Token Ring cards, you need
+to use the tms380 driver instead.
+
+Options:
+
+The driver accepts three options: ringspeed, pkt_buf_sz and message_level.
+
+These options can be specified differently for each card found. 
+
+ringspeed:  Has one of three settings 0 (default), 4 or 16.  0 will 
+make the card autosense the ringspeed and join at the appropriate speed, 
+this will be the default option for most people.  4 or 16 allow you to 
+explicitly force the card to operate at a certain speed.  The card will fail 
+if you try to insert it at the wrong speed. (Although some hubs will allow 
+this so be *very* careful).  The main purpose for explicitly setting the ring
+speed is for when the card is first on the ring.  In autosense mode, if the card
+cannot detect any active monitors on the ring it will open at the same speed as
+its last opening. This can be hazardous if this speed does not match the speed
+you want the ring to operate at.  
+
+pkt_buf_sz:  This is this initial receive buffer allocation size.  This will
+default to 4096 if no value is entered. You may increase performance of the 
+driver by setting this to a value larger than the network packet size, although
+the driver now re-sizes buffers based on MTU settings as well. 
+
+message_level: Controls level of messages created by the driver. Defaults to 0:
+which only displays start-up and critical messages.  Presently any non-zero 
+value will display all soft messages as well.  NB This does not turn 
+debugging messages on, that must be done by modified the source code.
+
+Variable MTU size:
+
+The driver can handle a MTU size upto either 4500 or 18000 depending upon 
+ring speed.  The driver also changes the size of the receive buffers as part
+of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
+to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 
+position = 296,000 bytes of memory space, plus of course anything 
+necessary for the tx sk_buff's.  Remember this is per card, so if you are
+building routers, gateway's etc, you could start to use a lot of memory
+real fast.
+
+2/17/02 Mike Phillips
+
diff --git a/Documentation/networking/3c505.txt b/Documentation/networking/3c505.txt
new file mode 100644
index 00000000000..b9d5b723011
--- /dev/null
+++ b/Documentation/networking/3c505.txt
@@ -0,0 +1,46 @@
+The 3Com Etherlink Plus (3c505) driver.
+
+This driver now uses DMA.  There is currently no support for PIO operation.
+The default DMA channel is 6; this is _not_ autoprobed, so you must
+make sure you configure it correctly.  If loading the driver as a
+module, you can do this with "modprobe 3c505 dma=n".  If the driver is
+linked statically into the kernel, you must either use an "ether="
+statement on the command line, or change the definition of ELP_DMA in 3c505.h.
+
+The driver will warn you if it has to fall back on the compiled in
+default DMA channel. 
+
+If no base address is given at boot time, the driver will autoprobe
+ports 0x300, 0x280 and 0x310 (in that order).  If no IRQ is given, the driver
+will try to probe for it.
+
+The driver can be used as a loadable module.  See net-modules.txt for details
+of the parameters it can take.  
+
+Theoretically, one instance of the driver can now run multiple cards,
+in the standard way (when loading a module, say "modprobe 3c505
+io=0x300,0x340 irq=10,11 dma=6,7" or whatever).  I have not tested
+this, though.
+
+The driver may now support revision 2 hardware; the dependency on
+being able to read the host control register has been removed.  This
+is also untested, since I don't have a suitable card.
+
+Known problems:
+ I still see "DMA upload timed out" messages from time to time.  These
+seem to be fairly non-fatal though.
+ The card is old and slow.
+
+To do:
+ Improve probe/setup code
+ Test multicast and promiscuous operation
+
+Authors:
+ The driver is mainly written by Craig Southeren, email
+ <craigs@ineluki.apana.org.au>.
+ Parts of the driver (adapting the driver to 1.1.4+ kernels,
+ IRQ/address detection, some changes) and this README by
+ Juha Laiho <jlaiho@ichaos.nullnet.fi>.
+ DMA mode, more fixes, etc, by Philip Blundell <pjb27@cam.ac.uk>
+ Multicard support, Software configurable DMA, etc., by
+ Christopher Collins <ccollins@pcug.org.au>
diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt
new file mode 100644
index 00000000000..867a99f88c6
--- /dev/null
+++ b/Documentation/networking/3c509.txt
@@ -0,0 +1,210 @@
+Linux and the 3Com EtherLink III Series Ethercards (driver v1.18c and higher)
+----------------------------------------------------------------------------
+
+This file contains the instructions and caveats for v1.18c and higher versions
+of the 3c509 driver. You should not use the driver without reading this file.
+
+release 1.0
+28 February 2002
+Current maintainer (corrections to):
+  David Ruggiero <jdr@farfalle.com>
+
+----------------------------------------------------------------------------
+
+(0) Introduction
+
+The following are notes and information on using the 3Com EtherLink III series
+ethercards in Linux. These cards are commonly known by the most widely-used
+card's 3Com model number, 3c509. They are all 10mb/s ISA-bus cards and shouldn't
+be (but sometimes are) confused with the similarly-numbered PCI-bus "3c905"
+(aka "Vortex" or "Boomerang") series.  Kernel support for the 3c509 family is
+provided by the module 3c509.c, which has code to support all of the following
+models:
+
+  3c509 (original ISA card)
+  3c509B (later revision of the ISA card; supports full-duplex)
+  3c589 (PCMCIA)
+  3c589B (later revision of the 3c589; supports full-duplex)
+  3c529 (MCA)
+  3c579 (EISA)
+
+Large portions of this documentation were heavily borrowed from the guide
+written the original author of the 3c509 driver, Donald Becker. The master
+copy of that document, which contains notes on older versions of the driver,
+currently resides on Scyld web server: http://www.scyld.com/network/3c509.html.
+
+
+(1) Special Driver Features
+
+Overriding card settings
+
+The driver allows boot- or load-time overriding of the card's detected IOADDR,
+IRQ, and transceiver settings, although this capability shouldn't generally be
+needed except to enable full-duplex mode (see below). An example of the syntax
+for LILO parameters for doing this:
+
+    ether=10,0x310,3,0x3c509,eth0 
+
+This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and
+transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts
+with other card types when overriding the I/O address. When the driver is
+loaded as a module, only the IRQ and transceiver setting may be overridden.
+For example, setting two cards to 10base2/IRQ10 and AUI/IRQ11 is done by using
+the xcvr and irq module options:
+
+   options 3c509 xcvr=3,1 irq=10,11
+
+
+(2) Full-duplex mode
+
+The v1.18c driver added support for the 3c509B's full-duplex capabilities.
+In order to enable and successfully use full-duplex mode, three conditions
+must be met: 
+
+(a) You must have a Etherlink III card model whose hardware supports full-
+duplex operations. Currently, the only members of the 3c509 family that are
+positively known to support full-duplex are the 3c509B (ISA bus) and 3c589B
+(PCMCIA) cards. Cards without the "B" model designation do *not* support
+full-duplex mode; these include the original 3c509 (no "B"), the original
+3c589, the 3c529 (MCA bus), and the 3c579 (EISA bus).
+
+(b) You must be using your card's 10baseT transceiver (i.e., the RJ-45
+connector), not its AUI (thick-net) or 10base2 (thin-net/coax) interfaces.
+AUI and 10base2 network cabling is physically incapable of full-duplex
+operation.
+
+(c) Most importantly, your 3c509B must be connected to a link partner that is
+itself full-duplex capable. This is almost certainly one of two things: a full-
+duplex-capable  Ethernet switch (*not* a hub), or a full-duplex-capable NIC on
+another system that's connected directly to the 3c509B via a crossover cable.
+ 
+/////Extremely important caution concerning full-duplex mode/////
+Understand that the 3c509B's hardware's full-duplex support is much more
+limited than that provide by more modern network interface cards. Although
+at the physical layer of the network it fully supports full-duplex operation,
+the card was designed before the current Ethernet auto-negotiation (N-way)
+spec was written. This means that the 3c509B family ***cannot and will not
+auto-negotiate a full-duplex connection with its link partner under any
+circumstances, no matter how it is initialized***. If the full-duplex mode
+of the 3c509B is enabled, its link partner will very likely need to be
+independently _forced_ into full-duplex mode as well; otherwise various nasty
+failures will occur - at the very least, you'll see massive numbers of packet
+collisions. This is one of very rare circumstances where disabling auto-
+negotiation and forcing the duplex mode of a network interface card or switch
+would ever be necessary or desirable.
+
+
+(3) Available Transceiver Types
+
+For versions of the driver v1.18c and above, the available transceiver types are:
+ 
+0  transceiver type from EEPROM config (normally 10baseT); force half-duplex
+1  AUI (thick-net / DB15 connector)
+2  (undefined)
+3  10base2 (thin-net == coax / BNC connector)
+4  10baseT (RJ-45 connector); force half-duplex mode
+8  transceiver type and duplex mode taken from card's EEPROM config settings
+12 10baseT (RJ-45 connector); force full-duplex mode
+
+Prior to driver version 1.18c, only transceiver codes 0-4 were supported. Note
+that the new transceiver codes 8 and 12 are the *only* ones that will enable
+full-duplex mode, no matter what the card's detected EEPROM settings might be.
+This insured that merely upgrading the driver from an earlier version would
+never automatically enable full-duplex mode in an existing installation;
+it must always be explicitly enabled via one of these code in order to be
+activated.
+  
+
+(4a) Interpretation of error messages and common problems
+
+Error Messages
+
+eth0: Infinite loop in interrupt, status 2011. 
+These are "mostly harmless" message indicating that the driver had too much
+work during that interrupt cycle. With a status of 0x2011 you are receiving
+packets faster than they can be removed from the card. This should be rare
+or impossible in normal operation. Possible causes of this error report are:
+ 
+   - a "green" mode enabled that slows the processor down when there is no
+     keyboard activitiy. 
+
+   - some other device or device driver hogging the bus or disabling interrupts.
+     Check /proc/interrupts for excessive interrupt counts. The timer tick
+     interrupt should always be incrementing faster than the others. 
+
+No received packets 
+If a 3c509, 3c562 or 3c589 can successfully transmit packets, but never
+receives packets (as reported by /proc/net/dev or 'ifconfig') you likely
+have an interrupt line problem. Check /proc/interrupts to verify that the
+card is actually generating interrupts. If the interrupt count is not
+increasing you likely have a physical conflict with two devices trying to
+use the same ISA IRQ line. The common conflict is with a sound card on IRQ10
+or IRQ5, and the easiest solution is to move the 3c509 to a different
+interrupt line. If the device is receiving packets but 'ping' doesn't work,
+you have a routing problem.
+
+Tx Carrier Errors Reported in /proc/net/dev 
+If an EtherLink III appears to transmit packets, but the "Tx carrier errors"
+field in /proc/net/dev increments as quickly as the Tx packet count, you
+likely have an unterminated network or the incorrect media transceiver selected. 
+
+3c509B card is not detected on machines with an ISA PnP BIOS. 
+While the updated driver works with most PnP BIOS programs, it does not work
+with all. This can be fixed by disabling PnP support using the 3Com-supplied
+setup program. 
+
+3c509 card is not detected on overclocked machines 
+Increase the delay time in id_read_eeprom() from the current value, 500,
+to an absurdly high value, such as 5000. 
+
+
+(4b) Decoding Status and Error Messages
+
+The bits in the main status register are: 
+
+value   description
+0x01    Interrupt latch
+0x02    Tx overrun, or Rx underrun
+0x04    Tx complete
+0x08    Tx FIFO room available
+0x10    A complete Rx packet has arrived
+0x20    A Rx packet has started to arrive
+0x40    The driver has requested an interrupt
+0x80    Statistics counter nearly full
+
+The bits in the transmit (Tx) status word are: 
+
+value   description
+0x02    Out-of-window collision.
+0x04    Status stack overflow (normally impossible).
+0x08    16 collisions.
+0x10    Tx underrun (not enough PCI bus bandwidth).
+0x20    Tx jabber.
+0x40    Tx interrupt requested.
+0x80    Status is valid (this should always be set).
+
+
+When a transmit error occurs the driver produces a status message such as 
+
+   eth0: Transmit error, Tx status register 82
+
+The two values typically seen here are:
+
+0x82 
+Out of window collision. This typically occurs when some other Ethernet
+host is incorrectly set to full duplex on a half duplex network. 
+
+0x88 
+16 collisions. This typically occurs when the network is exceptionally busy
+or when another host doesn't correctly back off after a collision. If this
+error is mixed with 0x82 errors it is the result of a host incorrectly set
+to full duplex (see above).
+
+Both of these errors are the result of network problems that should be
+corrected. They do not represent driver malfunction.
+
+
+(5) Revision history (this file)
+
+28Feb02 v1.0  DR   New; major portions based on Becker original 3c509 docs
+
diff --git a/Documentation/networking/6pack.txt b/Documentation/networking/6pack.txt
new file mode 100644
index 00000000000..48ed2b711bd
--- /dev/null
+++ b/Documentation/networking/6pack.txt
@@ -0,0 +1,175 @@
+This is the 6pack-mini-HOWTO, written by
+
+Andreas Könsgen DG3KQ
+Internet: ajk@iehk.rwth-aachen.de
+AMPR-net: dg3kq@db0pra.ampr.org
+AX.25:    dg3kq@db0ach.#nrw.deu.eu
+
+Last update: April 7, 1998
+
+1. What is 6pack, and what are the advantages to KISS?
+
+6pack is a transmission protocol for data exchange between the PC and
+the TNC over a serial line. It can be used as an alternative to KISS.
+
+6pack has two major advantages:
+- The PC is given full control over the radio
+  channel. Special control data is exchanged between the PC and the TNC so
+  that the PC knows at any time if the TNC is receiving data, if a TNC
+  buffer underrun or overrun has occurred, if the PTT is
+  set and so on. This control data is processed at a higher priority than
+  normal data, so a data stream can be interrupted at any time to issue an
+  important event. This helps to improve the channel access and timing 
+  algorithms as everything is computed in the PC. It would even be possible 
+  to experiment with something completely different from the known CSMA and 
+  DAMA channel access methods.
+  This kind of real-time control is especially important to supply several
+  TNCs that are connected between each other and the PC by a daisy chain
+  (however, this feature is not supported yet by the Linux 6pack driver).
+
+- Each packet transferred over the serial line is supplied with a checksum,
+  so it is easy to detect errors due to problems on the serial line.
+  Received packets that are corrupt are not passed on to the AX.25 layer.
+  Damaged packets that the TNC has received from the PC are not transmitted.
+
+More details about 6pack are described in the file 6pack.ps that is located
+in the doc directory of the AX.25 utilities package.
+
+2. Who has developed the 6pack protocol?
+
+The 6pack protocol has been developed by Ekki Plicht DF4OR, Henning Rech
+DF9IC and Gunter Jost DK7WJ. A driver for 6pack, written by Gunter Jost and
+Matthias Welwarsky DG2FEF, comes along with the PC version of FlexNet.
+They have also written a firmware for TNCs to perform the 6pack
+protocol (see section 4 below).
+
+3. Where can I get the latest version of 6pack for LinuX?
+
+At the moment, the 6pack stuff can obtained via anonymous ftp from
+db0bm.automation.fh-aachen.de. In the directory /incoming/dg3kq,
+there is a file named 6pack.tgz.
+
+4. Preparing the TNC for 6pack operation
+
+To be able to use 6pack, a special firmware for the TNC is needed. The EPROM
+of a newly bought TNC does not contain 6pack, so you will have to
+program an EPROM yourself. The image file for 6pack EPROMs should be
+available on any packet radio box where PC/FlexNet can be found. The name of
+the file is 6pack.bin. This file is copyrighted and maintained by the FlexNet
+team. It can be used under the terms of the license that comes along
+with PC/FlexNet. Please do not ask me about the internals of this file as I
+don't know anything about it. I used a textual description of the 6pack
+protocol to program the Linux driver.
+
+TNCs contain a 64kByte EPROM, the lower half of which is used for
+the firmware/KISS. The upper half is either empty or is sometimes
+programmed with software called TAPR. In the latter case, the TNC
+is supplied with a DIP switch so you can easily change between the
+two systems. When programming a new EPROM, one of the systems is replaced
+by 6pack. It is useful to replace TAPR, as this software is rarely used
+nowadays. If your TNC is not equipped with the switch mentioned above, you
+can build in one yourself that switches over the highest address pin
+of the EPROM between HIGH and LOW level. After having inserted the new EPROM
+and switched to 6pack, apply power to the TNC for a first test. The connect
+and the status LED are lit for about a second if the firmware initialises
+the TNC correctly.
+
+5. Building and installing the 6pack driver
+
+The driver has been tested with kernel version 2.1.90. Use with older
+kernels may lead to a compilation error because the interface to a kernel
+function has been changed in the 2.1.8x kernels.
+
+How to turn on 6pack support:
+
+- In the linux kernel configuration program, select the code maturity level
+  options menu and turn on the prompting for development drivers.
+
+- Select the amateur radio support menu and turn on the serial port 6pack
+  driver.
+
+- Compile and install the kernel and the modules.
+
+To use the driver, the kissattach program delivered with the AX.25 utilities
+has to be modified.
+
+- Do a cd to the directory that holds the kissattach sources. Edit the
+  kissattach.c file. At the top, insert the following lines:
+
+  #ifndef N_6PACK
+  #define N_6PACK (N_AX25+1)
+  #endif
+
+  Then find the line
+   
+  int disc = N_AX25;
+
+  and replace N_AX25 by N_6PACK.
+
+- Recompile kissattach. Rename it to spattach to avoid confusions.
+
+Installing the driver:
+
+- Do an insmod 6pack. Look at your /var/log/messages file to check if the 
+  module has printed its initialization message.
+
+- Do a spattach as you would launch kissattach when starting a KISS port.
+  Check if the kernel prints the message '6pack: TNC found'. 
+
+- From here, everything should work as if you were setting up a KISS port.
+  The only difference is that the network device that represents
+  the 6pack port is called sp instead of sl or ax. So, sp0 would be the
+  first 6pack port.
+
+Although the driver has been tested on various platforms, I still declare it
+ALPHA. BE CAREFUL! Sync your disks before insmoding the 6pack module
+and spattaching. Watch out if your computer behaves strangely. Read section
+6 of this file about known problems.
+
+Note that the connect and status LEDs of the TNC are controlled in a
+different way than they are when the TNC is used with PC/FlexNet. When using
+FlexNet, the connect LED is on if there is a connection; the status LED is
+on if there is data in the buffer of the PC's AX.25 engine that has to be
+transmitted. Under Linux, the 6pack layer is beyond the AX.25 layer,
+so the 6pack driver doesn't know anything about connects or data that
+has not yet been transmitted. Therefore the LEDs are controlled
+as they are in KISS mode: The connect LED is turned on if data is transferred
+from the PC to the TNC over the serial line, the status LED if data is
+sent to the PC.
+
+6. Known problems
+
+When testing the driver with 2.0.3x kernels and
+operating with data rates on the radio channel of 9600 Baud or higher,
+the driver may, on certain systems, sometimes print the message '6pack:
+bad checksum', which is due to data loss if the other station sends two
+or more subsequent packets. I have been told that this is due to a problem
+with the serial driver of 2.0.3x kernels. I don't know yet if the problem
+still exists with 2.1.x kernels, as I have heard that the serial driver
+code has been changed with 2.1.x.
+
+When shutting down the sp interface with ifconfig, the kernel crashes if
+there is still an AX.25 connection left over which an IP connection was
+running, even if that IP connection is already closed. The problem does not
+occur when there is a bare AX.25 connection still running. I don't know if
+this is a problem of the 6pack driver or something else in the kernel.
+
+The driver has been tested as a module, not yet as a kernel-builtin driver.
+
+The 6pack protocol supports daisy-chaining of TNCs in a token ring, which is
+connected to one serial port of the PC. This feature is not implemented
+and at least at the moment I won't be able to do it because I do not have
+the opportunity to build a TNC daisy-chain and test it.
+
+Some of the comments in the source code are inaccurate. They are left from
+the SLIP/KISS driver, from which the 6pack driver has been derived.
+I haven't modified or removed them yet -- sorry! The code itself needs
+some cleaning and optimizing. This will be done in a later release.
+
+If you encounter a bug or if you have a question or suggestion concerning the
+driver, feel free to mail me, using the addresses given at the beginning of
+this file.
+
+Have fun!
+
+Andreas
diff --git a/Documentation/networking/Configurable b/Documentation/networking/Configurable
new file mode 100644
index 00000000000..69c0dd466ea
--- /dev/null
+++ b/Documentation/networking/Configurable
@@ -0,0 +1,34 @@
+
+There are a few network parameters that can be tuned to better match
+the kernel to your system hardware and intended usage. The defaults
+are usually a good choice for 99% of the people 99% of the time, but
+you should be aware they do exist and can be changed.
+
+The current list of parameters can be found in the files:
+
+        linux/net/TUNABLE
+        Documentation/networking/ip-sysctl.txt
+
+Some of these are accessible via the sysctl interface, and many more are
+scheduled to be added in this way. For example, some parameters related 
+to Address Resolution Protocol (ARP) are very easily viewed and altered.
+
+        # cat /proc/sys/net/ipv4/arp_timeout
+        6000
+        # echo 7000 > /proc/sys/net/ipv4/arp_timeout
+        # cat /proc/sys/net/ipv4/arp_timeout
+        7000
+
+Others are already accessible via the related user space programs.
+For example, MAX_WINDOW has a default of 32 k which is a good choice for
+modern hardware, but if you have a slow (8 bit) Ethernet card and/or a slow
+machine, then this will be far too big for the card to keep up with fast 
+machines transmitting on the same net, resulting in overruns and receive errors.
+A value of about 4 k would be more appropriate, which can be set via:
+
+        # route add -net 192.168.3.0 window 4096
+
+The remainder of these can only be presently changed by altering a #define
+in the related header file. This means an edit and recompile cycle.
+
+                                                Paul Gortmaker 06/96
diff --git a/Documentation/networking/DLINK.txt b/Documentation/networking/DLINK.txt
new file mode 100644
index 00000000000..083d24752b8
--- /dev/null
+++ b/Documentation/networking/DLINK.txt
@@ -0,0 +1,204 @@
+Released 1994-06-13
+
+
+        CONTENTS:
+
+        1. Introduction.
+        2. License.
+        3. Files in this release.
+        4. Installation.
+        5. Problems and tuning.
+        6. Using the drivers with earlier releases.
+        7. Acknowledgments.
+
+
+        1. INTRODUCTION.
+
+        This is a set of Ethernet drivers for the D-Link DE-600/DE-620
+        pocket adapters, for the parallel port on a Linux based machine.
+        Some adapter "clones" will also work.  Xircom is _not_ a clone...
+        These drivers _can_ be used as loadable modules,
+        and were developed for use on Linux 1.1.13 and above.
+        For use on Linux 1.0.X, or earlier releases, see below.
+
+        I have used these drivers for NFS, ftp, telnet and X-clients on
+        remote machines. Transmissions with ftp seems to work as
+        good as can be expected (i.e. > 80k bytes/sec) from a
+        parallel port...:-)  Receive speeds will be about 60-80% of this.
+        Depending on your machine, somewhat higher speeds can be achieved.
+
+        All comments/fixes to Bjorn Ekwall (bj0rn@blox.se).
+
+
+        2. LICENSE.
+
+        This program is free software; you can redistribute it
+        and/or modify it under the terms of the GNU General Public
+        License as published by the Free Software Foundation; either
+        version 2, or (at your option) any later version.
+
+        This program is distributed in the hope that it will be
+        useful, but WITHOUT ANY WARRANTY; without even the implied
+        warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
+        PURPOSE. See the GNU General Public License for more
+        details.
+
+        You should have received a copy of the GNU General Public
+        License along with this program; if not, write to the Free
+        Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+        02139, USA.
+
+
+        3. FILES IN THIS RELEASE.
+
+        README.DLINK  This file.
+        de600.c       The Source (may it be with You :-) for the DE-600
+        de620.c       ditto for the DE-620
+        de620.h       Macros for de620.c
+
+        If you are upgrading from the d-link tar release, there will
+        also be a "dlink-patches" file that will patch Linux 1.1.18:
+                linux/drivers/net/Makefile
+                linux/drivers/net/CONFIG
+                linux/drivers/net/MODULES
+                linux/drivers/net/Space.c
+                linux/config.in
+        Apply the patch by:
+        "cd /usr/src; patch -p0 < linux/drivers/net/dlink-patches"
+        The old source, "linux/drivers/net/d_link.c", can be removed.
+
+
+        4. INSTALLATION.
+
+        o Get the latest net binaries, according to current net.wisdom.
+
+        o Read the NET-2 and Ethernet HOWTOs and modify your setup.
+
+        o If your parallel port has a strange address or irq,
+          modify "linux/drivers/net/CONFIG" accordingly, or adjust
+          the parameters in the "tuning" section in the sources.
+
+        If you are going to use the drivers as loadable modules, do _not_
+        enable them while doing "make config", but instead make sure that
+        the drivers are included in "linux/drivers/net/MODULES".
+
+        If you are _not_ going to use the driver(s) as loadable modules,
+        but instead have them included in the kernel, remember to enable
+        the drivers while doing "make config".
+
+        o To include networking and DE600/DE620 support in your kernel:
+          # cd /linux
+          (as modules:)
+          #  make config (answer yes on CONFIG_NET and CONFIG_INET)
+          (else included in the kernel:)
+          #  make config (answer yes on CONFIG _NET, _INET and _DE600 or _DE620)
+          # make clean
+          # make zImage (or whatever magic you usually do)
+
+        o I use lilo to boot multiple kernels, so that I at least
+          can have one working kernel :-). If you do too, append
+          these lines to /etc/lilo/config:
+
+                image = /linux/zImage
+                label = newlinux
+                root = /dev/hda2 (or whatever YOU have...)
+
+          # /etc/lilo/install
+
+        o Do "sync" and reboot the new kernel with a D-Link
+          DE-600/DE-620 pocket adapter connected.
+
+        o The adapter can be configured with ifconfig eth?
+          where the actual number is decided by the kernel
+          when the drivers are initialized.
+
+
+        5. "PROBLEMS" AND TUNING,
+
+        o If you see error messages from the driver, and if the traffic
+          stops on the adapter, try to do "ifconfig" and "route" once
+          more, just as in "rc.inet1".  This should take care of most
+          problems, including effects from power loss, or adapters that
+          aren't connected to the printer port in some way or another.
+          You can somewhat change the behaviour by enabling/disabling
+          the macro  SHUTDOWN_WHEN_LOST  in the "tuning" section.
+          For the DE-600 there is another macro, CHECK_LOST_DE600,
+          that you might want to read about in the "tuning" section.
+
+        o Some machines have trouble handling the parallel port and
+          the adapter at high speed. If you experience problems:
+
+          DE-600:
+          - The adapter is not recognized at boot, i.e. an Ethernet
+            address of 00:80:c8:... is not shown, try to add another
+              "; SLOW_DOWN_IO"
+            at DE600_SLOW_DOWN in the "tuning" section. As a last resort,
+            uncomment: "#define REALLY_SLOW_IO" (see <asm/io.h> for hints).
+
+          - You experience "timeout" messages: first try to add another
+              "; SLOW_DOWN_IO"
+            at DE600_SLOW_DOWN in the "tuning" section, _then_ try to
+            increase the value (original value: 5) at
+            "if (tickssofar < 5)" near line 422.
+
+          DE-620:
+          - Your parallel port might be "sluggish".  To cater for
+            this, there are the macros LOWSPEED and READ_DELAY/WRITE_DELAY
+            in the "tuning" section. Your first step should be to enable
+            LOWSPEED, and after that you can "tune" the XXX_DELAY values.
+
+        o If the adapter _is_ recognized at boot but you get messages
+          about "Network Unreachable", then the problem is probably
+          _not_ with the driver.  Check your net configuration instead
+          (ifconfig and route) in "rc.inet1".
+
+        o There is some rudimentary support for debugging, look at
+          the source. Use "-DDE600_DEBUG=3" or "-DDE620_DEBUG=3"
+          when compiling, or include it in "linux/drivers/net/CONFIG".
+          IF YOU HAVE PROBLEMS YOU CAN'T SOLVE: PLEASE COMPILE THE DRIVER
+          WITH DEBUGGING ENABLED, AND SEND ME THE RESULTING OUTPUT!
+
+
+        6. USING THE DRIVERS WITH EARLIER RELEASES.
+
+        The later 1.1.X releases of the Linux kernel include some
+        changes in the networking layer (a.k.a. NET3). This affects
+        these drivers in a few places.  The hints that follow are
+        _not_ tested by me, since I don't have the disk space to keep
+        all releases on-line.
+        Known needed changes to date:
+        - release patchfile: some patches will fail, but they should
+          be easy to apply "by hand", since they are trivial.
+          (Space.c: d_link_init() is now called de600_probe())
+        - de600.c: change  "mark_bh(NET_BH)" to  "mark_bh(INET_BH)".
+        - de620.c: (maybe) change the code around "netif_rx(skb);" to be
+                   similar to the code around "dev_rint(...)" in de600.c
+
+
+        7. ACKNOWLEDGMENTS.
+
+        These drivers wouldn't have been done without the base
+        (and support) from Ross Biro <bir7@leland.stanford.edu>,
+        and D-Link Systems Inc.  The driver relies upon GPL-ed
+        source from D-Link Systems Inc. and from Russel Nelson at
+        Crynwr Software <nelson@crynwr.com>.
+
+        Additional input also from:
+        Donald Becker <becker@super.org>, Alan Cox <A.Cox@swansea.ac.uk>
+        and Fred N. van Kempen <waltje@uWalt.NL.Mugnet.ORG>
+
+        DE-600 alpha release primary victim^H^H^H^H^H^Htester:
+        - Erik Proper <erikp@cs.kun.nl>.
+        Good input also from several users, most notably
+        - Mark Burton <markb@ordern.demon.co.uk>.
+
+        DE-620 alpha release victims^H^H^H^H^H^H^Htesters:
+        - J. Joshua Kopper <kopper@rtsg.mot.com>
+        - Olav Kvittem <Olav.Kvittem@uninett.no>
+        - Germano Caronni <caronni@nessie.cs.id.ethz.ch>
+        - Jeremy Fitzhardinge <jeremy@suite.sw.oz.au>
+
+
+        Happy hacking!
+
+        Bjorn Ekwall == bj0rn@blox.se
diff --git a/Documentation/networking/NAPI_HOWTO.txt b/Documentation/networking/NAPI_HOWTO.txt
new file mode 100644
index 00000000000..54376e8249c
--- /dev/null
+++ b/Documentation/networking/NAPI_HOWTO.txt
@@ -0,0 +1,766 @@
+HISTORY:
+February 16/2002 -- revision 0.2.1:
+COR typo corrected
+February 10/2002 -- revision 0.2:
+some spell checking ;->
+January 12/2002 -- revision 0.1
+This is still work in progress so may change.
+To keep up to date please watch this space.
+
+Introduction to NAPI
+====================
+
+NAPI is a proven (www.cyberus.ca/~hadi/usenix-paper.tgz) technique
+to improve network performance on Linux. For more details please
+read that paper.
+NAPI provides a "inherent mitigation" which is bound by system capacity
+as can be seen from the following data collected by Robert on Gigabit 
+ethernet (e1000):
+
+ Psize    Ipps       Tput     Rxint     Txint    Done     Ndone
+ ---------------------------------------------------------------
+   60    890000     409362        17     27622        7     6823
+  128    758150     464364        21      9301       10     7738
+  256    445632     774646        42     15507       21    12906
+  512    232666     994445    241292     19147   241192     1062
+ 1024    119061    1000003    872519     19258   872511        0
+ 1440     85193    1000003    946576     19505   946569        0
+ 
+
+Legend:
+"Ipps" stands for input packets per second. 
+"Tput" == packets out of total 1M that made it out.
+"txint" == transmit completion interrupts seen
+"Done" == The number of times that the poll() managed to pull all
+packets out of the rx ring. Note from this that the lower the
+load the more we could clean up the rxring
+"Ndone" == is the converse of "Done". Note again, that the higher
+the load the more times we couldnt clean up the rxring.
+
+Observe that:
+when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated. 
+The system cant handle the processing at 1 interrupt/packet at that load level. 
+At lower rates on the other hand, rx interrupts go up and therefore the
+interrupt/packet ratio goes up (as observable from that table). So there is
+possibility that under low enough input, you get one poll call for each
+input packet caused by a single interrupt each time. And if the system 
+cant handle interrupt per packet ratio of 1, then it will just have to 
+chug along ....
+
+
+0) Prerequisites:
+==================
+A driver MAY continue using the old 2.4 technique for interfacing
+to the network stack and not benefit from the NAPI changes.
+NAPI additions to the kernel do not break backward compatibility.
+NAPI, however, requires the following features to be available:
+
+A) DMA ring or enough RAM to store packets in software devices.
+
+B) Ability to turn off interrupts or maybe events that send packets up 
+the stack.
+
+NAPI processes packet events in what is known as dev->poll() method.
+Typically, only packet receive events are processed in dev->poll(). 
+The rest of the events MAY be processed by the regular interrupt handler 
+to reduce processing latency (justified also because there are not that 
+many of them).
+Note, however, NAPI does not enforce that dev->poll() only processes 
+receive events. 
+Tests with the tulip driver indicated slightly increased latency if
+all of the interrupt handler is moved to dev->poll(). Also MII handling
+gets a little trickier.
+The example used in this document is to move the receive processing only
+to dev->poll(); this is shown with the patch for the tulip driver.
+For an example of code that moves all the interrupt driver to 
+dev->poll() look at the ported e1000 code.
+
+There are caveats that might force you to go with moving everything to 
+dev->poll(). Different NICs work differently depending on their status/event 
+acknowledgement setup. 
+There are two types of event register ACK mechanisms.
+        I)  what is known as Clear-on-read (COR).
+        when you read the status/event register, it clears everything!
+        The natsemi and sunbmac NICs are known to do this.
+        In this case your only choice is to move all to dev->poll()
+
+        II) Clear-on-write (COW)
+         i) you clear the status by writing a 1 in the bit-location you want.
+                These are the majority of the NICs and work the best with NAPI.
+                Put only receive events in dev->poll(); leave the rest in
+                the old interrupt handler.
+         ii) whatever you write in the status register clears every thing ;->
+                Cant seem to find any supported by Linux which do this. If
+                someone knows such a chip email us please.
+                Move all to dev->poll()
+
+C) Ability to detect new work correctly.
+NAPI works by shutting down event interrupts when theres work and
+turning them on when theres none. 
+New packets might show up in the small window while interrupts were being 
+re-enabled (refer to appendix 2).  A packet might sneak in during the period 
+we are enabling interrupts. We only get to know about such a packet when the 
+next new packet arrives and generates an interrupt. 
+Essentially, there is a small window of opportunity for a race condition
+which for clarity we'll refer to as the "rotting packet".
+
+This is a very important topic and appendix 2 is dedicated for more 
+discussion.
+
+Locking rules and environmental guarantees
+==========================================
+
+-Guarantee: Only one CPU at any time can call dev->poll(); this is because
+only one CPU can pick the initial interrupt and hence the initial
+netif_rx_schedule(dev);
+- The core layer invokes devices to send packets in a round robin format.
+This implies receive is totaly lockless because of the guarantee only that 
+one CPU is executing it.
+-  contention can only be the result of some other CPU accessing the rx
+ring. This happens only in close() and suspend() (when these methods
+try to clean the rx ring); 
+****guarantee: driver authors need not worry about this; synchronization 
+is taken care for them by the top net layer.
+-local interrupts are enabled (if you dont move all to dev->poll()). For 
+example link/MII and txcomplete continue functioning just same old way. 
+This improves the latency of processing these events. It is also assumed that 
+the receive interrupt is the largest cause of noise. Note this might not 
+always be true. 
+[according to Manfred Spraul, the winbond insists on sending one 
+txmitcomplete interrupt for each packet (although this can be mitigated)].
+For these broken drivers, move all to dev->poll().
+
+For the rest of this text, we'll assume that dev->poll() only
+processes receive events.
+
+new methods introduce by NAPI
+=============================
+
+a) netif_rx_schedule(dev)
+Called by an IRQ handler to schedule a poll for device
+
+b) netif_rx_schedule_prep(dev)
+puts the device in a state which allows for it to be added to the
+CPU polling list if it is up and running. You can look at this as
+the first half of  netif_rx_schedule(dev) above; the second half
+being c) below.
+
+c) __netif_rx_schedule(dev)
+Add device to the poll list for this CPU; assuming that _prep above
+has already been called and returned 1.
+
+d) netif_rx_reschedule(dev, undo)
+Called to reschedule polling for device specifically for some
+deficient hardware. Read Appendix 2 for more details.
+
+e) netif_rx_complete(dev)
+
+Remove interface from the CPU poll list: it must be in the poll list
+on current cpu. This primitive is called by dev->poll(), when
+it completes its work. The device cannot be out of poll list at this
+call, if it is then clearly it is a BUG(). You'll know ;->
+
+All these above nethods are used below. So keep reading for clarity.
+
+Device driver changes to be made when porting NAPI
+==================================================
+
+Below we describe what kind of changes are required for NAPI to work.
+
+1) introduction of dev->poll() method 
+=====================================
+
+This is the method that is invoked by the network core when it requests
+for new packets from the driver. A driver is allowed to send upto
+dev->quota packets by the current CPU before yielding to the network
+subsystem (so other devices can also get opportunity to send to the stack).
+
+dev->poll() prototype looks as follows:
+int my_poll(struct net_device *dev, int *budget)
+
+budget is the remaining number of packets the network subsystem on the
+current CPU can send up the stack before yielding to other system tasks.
+*Each driver is responsible for decrementing budget by the total number of
+packets sent.
+        Total number of packets cannot exceed dev->quota.
+
+dev->poll() method is invoked by the top layer, the driver just sends if it 
+can to the stack the packet quantity requested.
+
+more on dev->poll() below after the interrupt changes are explained.
+
+2) registering dev->poll() method
+===================================
+
+dev->poll should be set in the dev->probe() method. 
+e.g:
+dev->open = my_open;
+.
+.
+/* two new additions */
+/* first register my poll method */
+dev->poll = my_poll;
+/* next register my weight/quanta; can be overridden in /proc */
+dev->weight = 16;
+.
+.
+dev->stop = my_close;
+
+
+
+3) scheduling dev->poll()
+=============================
+This involves modifying the interrupt handler and the code
+path which takes the packet off the NIC and sends them to the 
+stack.
+
+it's important at this point to introduce the classical D Becker 
+interrupt processor:
+
+------------------
+static irqreturn_t
+netdevice_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+
+        struct net_device *dev = (struct net_device *)dev_instance;
+        struct my_private *tp = (struct my_private *)dev->priv;
+
+        int work_count = my_work_count;
+        status = read_interrupt_status_reg();
+        if (status == 0)
+                return IRQ_NONE; /* Shared IRQ: not us */
+        if (status == 0xffff)
+                return IRQ_HANDLED;      /* Hot unplug */
+        if (status & error)
+                do_some_error_handling()
+        
+        do {
+                acknowledge_ints_ASAP();
+
+                if (status & link_interrupt) {
+                        spin_lock(&tp->link_lock);
+                        do_some_link_stat_stuff();
+                        spin_lock(&tp->link_lock);
+                }
+                
+                if (status & rx_interrupt) {
+                        receive_packets(dev);
+                }
+
+                if (status & rx_nobufs) {
+                        make_rx_buffs_avail();
+                }
+                        
+                if (status & tx_related) {
+                        spin_lock(&tp->lock);
+                        tx_ring_free(dev);
+                        if (tx_died)
+                                restart_tx();
+                        spin_unlock(&tp->lock);
+                }
+
+                status = read_interrupt_status_reg();
+
+        } while (!(status & error) || more_work_to_be_done);
+        return IRQ_HANDLED;
+}
+
+----------------------------------------------------------------------
+
+We now change this to what is shown below to NAPI-enable it:
+
+----------------------------------------------------------------------
+static irqreturn_t
+netdevice_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+        struct net_device *dev = (struct net_device *)dev_instance;
+        struct my_private *tp = (struct my_private *)dev->priv;
+
+        status = read_interrupt_status_reg();
+        if (status == 0)
+                return IRQ_NONE;         /* Shared IRQ: not us */
+        if (status == 0xffff)
+                return IRQ_HANDLED;         /* Hot unplug */
+        if (status & error)
+                do_some_error_handling();
+        
+        do {
+/************************ start note *********************************/         
+                acknowledge_ints_ASAP();  // dont ack rx and rxnobuff here
+/************************ end note *********************************/           
+
+                if (status & link_interrupt) {
+                        spin_lock(&tp->link_lock);
+                        do_some_link_stat_stuff();
+                        spin_unlock(&tp->link_lock);
+                }
+/************************ start note *********************************/         
+                if (status & rx_interrupt || (status & rx_nobuffs)) {
+                        if (netif_rx_schedule_prep(dev)) {
+
+                                /* disable interrupts caused 
+                                 *      by arriving packets */
+                                disable_rx_and_rxnobuff_ints();
+                                /* tell system we have work to be done. */
+                                __netif_rx_schedule(dev);
+                        } else {
+                                printk("driver bug! interrupt while in poll\n");
+                                /* FIX by disabling interrupts  */
+                                disable_rx_and_rxnobuff_ints();
+                        }
+                }
+/************************ end note note *********************************/              
+                        
+                if (status & tx_related) {
+                        spin_lock(&tp->lock);
+                        tx_ring_free(dev);
+
+                        if (tx_died)
+                                restart_tx();
+                        spin_unlock(&tp->lock);
+                }
+
+                status = read_interrupt_status_reg();
+
+/************************ start note *********************************/         
+        } while (!(status & error) || more_work_to_be_done(status));
+/************************ end note note *********************************/              
+        return IRQ_HANDLED;
+}
+
+---------------------------------------------------------------------
+
+
+We note several things from above:
+
+I) Any interrupt source which is caused by arriving packets is now
+turned off when it occurs. Depending on the hardware, there could be
+several reasons that arriving packets would cause interrupts; these are the
+interrupt sources we wish to avoid. The two common ones are a) a packet 
+arriving (rxint) b) a packet arriving and finding no DMA buffers available
+(rxnobuff) .
+This means also acknowledge_ints_ASAP() will not clear the status
+register for those two items above; clearing is done in the place where 
+proper work is done within NAPI; at the poll() and refill_rx_ring() 
+discussed further below.
+netif_rx_schedule_prep() returns 1 if device is in running state and
+gets successfully added to the core poll list. If we get a zero value
+we can _almost_ assume are already added to the list (instead of not running. 
+Logic based on the fact that you shouldn't get interrupt if not running)
+We rectify this by disabling rx and rxnobuf interrupts.
+
+II) that receive_packets(dev) and make_rx_buffs_avail() may have disappeared.
+These functionalities are still around actually......
+
+infact, receive_packets(dev) is very close to my_poll() and 
+make_rx_buffs_avail() is invoked from my_poll()
+
+4) converting receive_packets() to dev->poll()
+===============================================
+
+We need to convert the classical D Becker receive_packets(dev) to my_poll()
+
+First the typical receive_packets() below:
+-------------------------------------------------------------------
+
+/* this is called by interrupt handler */
+static void receive_packets (struct net_device *dev)
+{
+
+        struct my_private *tp = (struct my_private *)dev->priv;
+        rx_ring = tp->rx_ring;
+        cur_rx = tp->cur_rx;
+        int entry = cur_rx % RX_RING_SIZE;
+        int received = 0;
+        int rx_work_limit = tp->dirty_rx + RX_RING_SIZE - tp->cur_rx;
+
+        while (rx_ring_not_empty) {
+                u32 rx_status;
+                unsigned int rx_size;
+                unsigned int pkt_size;
+                struct sk_buff *skb;
+                /* read size+status of next frame from DMA ring buffer */
+                /* the number 16 and 4 are just examples */
+                rx_status = le32_to_cpu (*(u32 *) (rx_ring + ring_offset));
+                rx_size = rx_status >> 16;
+                pkt_size = rx_size - 4;
+
+                /* process errors */
+                if ((rx_size > (MAX_ETH_FRAME_SIZE+4)) ||
+                    (!(rx_status & RxStatusOK))) {
+                        netdrv_rx_err (rx_status, dev, tp, ioaddr);
+                        return;
+                }
+
+                if (--rx_work_limit < 0)
+                        break;
+
+                /* grab a skb */
+                skb = dev_alloc_skb (pkt_size + 2);
+                if (skb) {
+                        .
+                        .
+                        netif_rx (skb);
+                        .
+                        .
+                } else {  /* OOM */
+                        /*seems very driver specific ... some just pass
+                        whatever is on the ring already. */
+                }
+
+                /* move to the next skb on the ring */
+                entry = (++tp->cur_rx) % RX_RING_SIZE;
+                received++ ;
+
+        }
+
+        /* store current ring pointer state */
+        tp->cur_rx = cur_rx;
+
+        /* Refill the Rx ring buffers if they are needed */
+        refill_rx_ring();
+        .
+        .
+
+}
+-------------------------------------------------------------------
+We change it to a new one below; note the additional parameter in
+the call.
+
+-------------------------------------------------------------------
+
+/* this is called by the network core */
+static int my_poll (struct net_device *dev, int *budget)
+{
+
+        struct my_private *tp = (struct my_private *)dev->priv;
+        rx_ring = tp->rx_ring;
+        cur_rx = tp->cur_rx;
+        int entry = cur_rx % RX_BUF_LEN;
+        /* maximum packets to send to the stack */
+/************************ note note *********************************/          
+        int rx_work_limit = dev->quota;
+
+/************************ end note note *********************************/              
+    do {  // outer beginning loop starts here
+
+        clear_rx_status_register_bit();
+
+        while (rx_ring_not_empty) {
+                u32 rx_status;
+                unsigned int rx_size;
+                unsigned int pkt_size;
+                struct sk_buff *skb;
+                /* read size+status of next frame from DMA ring buffer */
+                /* the number 16 and 4 are just examples */
+                rx_status = le32_to_cpu (*(u32 *) (rx_ring + ring_offset));
+                rx_size = rx_status >> 16;
+                pkt_size = rx_size - 4;
+
+                /* process errors */
+                if ((rx_size > (MAX_ETH_FRAME_SIZE+4)) ||
+                    (!(rx_status & RxStatusOK))) {
+                        netdrv_rx_err (rx_status, dev, tp, ioaddr);
+                        return 1;
+                }
+
+/************************ note note *********************************/          
+                if (--rx_work_limit < 0) { /* we got packets, but no quota */
+                        /* store current ring pointer state */
+                        tp->cur_rx = cur_rx;
+
+                        /* Refill the Rx ring buffers if they are needed */
+                        refill_rx_ring(dev);
+                        goto not_done;
+                }
+/**********************  end note **********************************/
+
+                /* grab a skb */
+                skb = dev_alloc_skb (pkt_size + 2);
+                if (skb) {
+                        .
+                        .
+/************************ note note *********************************/          
+                        netif_receive_skb (skb);
+/**********************  end note **********************************/
+                        .
+                        .
+                } else {  /* OOM */
+                        /*seems very driver specific ... common is just pass
+                        whatever is on the ring already. */
+                }
+
+                /* move to the next skb on the ring */
+                entry = (++tp->cur_rx) % RX_RING_SIZE;
+                received++ ;
+
+        }
+
+        /* store current ring pointer state */
+        tp->cur_rx = cur_rx;
+
+        /* Refill the Rx ring buffers if they are needed */
+        refill_rx_ring(dev);
+        
+        /* no packets on ring; but new ones can arrive since we last 
+           checked  */
+        status = read_interrupt_status_reg();
+        if (rx status is not set) {
+                        /* If something arrives in this narrow window,
+                        an interrupt will be generated */
+                        goto done;
+        }
+        /* done! at least thats what it looks like ;->
+        if new packets came in after our last check on status bits
+        they'll be caught by the while check and we go back and clear them 
+        since we havent exceeded our quota */
+    } while (rx_status_is_set); 
+
+done:
+
+/************************ note note *********************************/          
+        dev->quota -= received;
+        *budget -= received;
+
+        /* If RX ring is not full we are out of memory. */
+        if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
+                goto oom;
+
+        /* we are happy/done, no more packets on ring; put us back
+        to where we can start processing interrupts again */
+        netif_rx_complete(dev);
+        enable_rx_and_rxnobuf_ints();
+
+       /* The last op happens after poll completion. Which means the following:
+        * 1. it can race with disabling irqs in irq handler (which are done to 
+        * schedule polls)
+        * 2. it can race with dis/enabling irqs in other poll threads
+        * 3. if an irq raised after the begining of the outer  beginning 
+        * loop(marked in the code above), it will be immediately
+        * triggered here.
+        *
+        * Summarizing: the logic may results in some redundant irqs both
+        * due to races in masking and due to too late acking of already
+        * processed irqs. The good news: no events are ever lost.
+        */
+
+        return 0;   /* done */
+
+not_done:
+        if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 ||
+            tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
+                refill_rx_ring(dev);
+
+        if (!received) {
+                printk("received==0\n");
+                received = 1;
+        }
+        dev->quota -= received;
+        *budget -= received;
+        return 1;  /* not_done */
+
+oom:
+        /* Start timer, stop polling, but do not enable rx interrupts. */
+        start_poll_timer(dev);
+        return 0;  /* we'll take it from here so tell core "done"*/
+
+/************************ End note note *********************************/              
+}
+-------------------------------------------------------------------
+
+From above we note that:
+0) rx_work_limit = dev->quota 
+1) refill_rx_ring() is in charge of clearing the bit for rxnobuff when
+it does the work.
+2) We have a done and not_done state.
+3) instead of netif_rx() we call netif_receive_skb() to pass the skb.
+4) we have a new way of handling oom condition
+5) A new outer for (;;) loop has been added. This serves the purpose of
+ensuring that if a new packet has come in, after we are all set and done,
+and we have not exceeded our quota that we continue sending packets up.
+ 
+
+-----------------------------------------------------------
+Poll timer code will need to do the following:
+
+a) 
+
+        if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 ||
+            tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) 
+                refill_rx_ring(dev);
+
+        /* If RX ring is not full we are still out of memory.
+           Restart the timer again. Else we re-add ourselves 
+           to the master poll list.
+         */
+
+        if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
+                restart_timer();
+
+        else netif_rx_schedule(dev);  /* we are back on the poll list */
+        
+5) dev->close() and dev->suspend() issues
+==========================================
+The driver writter neednt worry about this. The top net layer takes
+care of it.
+
+6) Adding new Stats to /proc 
+=============================
+In order to debug some of the new features, we introduce new stats
+that need to be collected.
+TODO: Fill this later.
+
+APPENDIX 1: discussion on using ethernet HW FC
+==============================================
+Most chips with FC only send a pause packet when they run out of Rx buffers.
+Since packets are pulled off the DMA ring by a softirq in NAPI,
+if the system is slow in grabbing them and we have a high input
+rate (faster than the system's capacity to remove packets), then theoretically
+there will only be one rx interrupt for all packets during a given packetstorm.
+Under low load, we might have a single interrupt per packet.
+FC should be programmed to apply in the case when the system cant pull out
+packets fast enough i.e send a pause only when you run out of rx buffers.
+Note FC in itself is a good solution but we have found it to not be
+much of a commodity feature (both in NICs and switches) and hence falls
+under the same category as using NIC based mitigation. Also experiments
+indicate that its much harder to resolve the resource allocation
+issue (aka lazy receiving that NAPI offers) and hence quantify its usefullness
+proved harder. In any case, FC works even better with NAPI but is not
+necessary.
+
+
+APPENDIX 2: the "rotting packet" race-window avoidance scheme 
+=============================================================
+
+There are two types of associations seen here
+
+1) status/int which honors level triggered IRQ
+
+If a status bit for receive or rxnobuff is set and the corresponding 
+interrupt-enable bit is not on, then no interrupts will be generated. However, 
+as soon as the "interrupt-enable" bit is unmasked, an immediate interrupt is 
+generated.  [assuming the status bit was not turned off].
+Generally the concept of level triggered IRQs in association with a status and
+interrupt-enable CSR register set is used to avoid the race.
+
+If we take the example of the tulip:
+"pending work" is indicated by the status bit(CSR5 in tulip).
+the corresponding interrupt bit (CSR7 in tulip) might be turned off (but
+the CSR5 will continue to be turned on with new packet arrivals even if
+we clear it the first time)
+Very important is the fact that if we turn on the interrupt bit on when
+status is set that an immediate irq is triggered.
+ 
+If we cleared the rx ring and proclaimed there was "no more work
+to be done" and then went on to do a few other things;  then when we enable
+interrupts, there is a possibility that a new packet might sneak in during
+this phase. It helps to look at the pseudo code for the tulip poll
+routine:
+
+--------------------------
+        do {
+                ACK;
+                while (ring_is_not_empty()) {
+                        work-work-work
+                        if quota is exceeded: exit, no touching irq status/mask
+                }
+                /* No packets, but new can arrive while we are doing this*/
+                CSR5 := read
+                if (CSR5 is not set) {
+                        /* If something arrives in this narrow window here,
+                        *  where the comments are ;-> irq will be generated */
+                        unmask irqs;
+                        exit poll;
+                }
+        } while (rx_status_is_set);
+------------------------
+
+CSR5 bit of interest is only the rx status. 
+If you look at the last if statement: 
+you just finished grabbing all the packets from the rx ring .. you check if
+status bit says theres more packets just in ... it says none; you then
+enable rx interrupts again; if a new packet just came in during this check,
+we are counting that CSR5 will be set in that small window of opportunity
+and that by re-enabling interrupts, we would actually triger an interrupt
+to register the new packet for processing.
+
+[The above description nay be very verbose, if you have better wording 
+that will make this more understandable, please suggest it.]
+
+2) non-capable hardware
+
+These do not generally respect level triggered IRQs. Normally,
+irqs may be lost while being masked and the only way to leave poll is to do
+a double check for new input after netif_rx_complete() is invoked
+and re-enable polling (after seeing this new input).
+
+Sample code:
+
+---------
+        .
+        .
+restart_poll:
+        while (ring_is_not_empty()) {
+                work-work-work
+                if quota is exceeded: exit, not touching irq status/mask
+        }
+        .
+        .
+        .
+        enable_rx_interrupts()
+        netif_rx_complete(dev);
+        if (ring_has_new_packet() && netif_rx_reschedule(dev, received)) {
+                disable_rx_and_rxnobufs()
+                goto restart_poll
+        } while (rx_status_is_set);
+---------
+                
+Basically netif_rx_complete() removes us from the poll list, but because a
+new packet which will never be caught due to the possibility of a race
+might come in, we attempt to re-add ourselves to the poll list. 
+
+
+
+
+APPENDIX 3: Scheduling issues.
+==============================
+As seen NAPI moves processing to softirq level. Linux uses the ksoftirqd as the 
+general solution to schedule softirq's to run before next interrupt and by putting 
+them under scheduler control. Also this prevents consecutive softirq's from 
+monopolize the CPU. This also have the effect that the priority of ksoftirq needs 
+to be considered when running very CPU-intensive applications and networking to
+get the proper balance of softirq/user balance. Increasing ksoftirq priority to 0 
+(eventually more) is reported cure problems with low network performance at high 
+CPU load.
+
+Most used processes in a GIGE router:
+USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
+root         3  0.2  0.0     0     0  ?  RWN Aug 15 602:00 (ksoftirqd_CPU0)
+root       232  0.0  7.9 41400 40884  ?  S   Aug 15  74:12 gated 
+
+--------------------------------------------------------------------
+
+relevant sites:
+==================
+ftp://robur.slu.se/pub/Linux/net-development/NAPI/
+
+
+--------------------------------------------------------------------
+TODO: Write net-skeleton.c driver.
+-------------------------------------------------------------
+
+Authors:
+========
+Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
+Jamal Hadi Salim <hadi@cyberus.ca>
+Robert Olsson <Robert.Olsson@data.slu.se>
+
+Acknowledgements:
+================
+People who made this document better:
+
+Lennert Buytenhek <buytenh@gnu.org>
+Andrew Morton  <akpm@zip.com.au>
+Manfred Spraul <manfred@colorfullife.com>
+Donald Becker <becker@scyld.com>
+Jeff Garzik <jgarzik@pobox.com>
diff --git a/Documentation/networking/PLIP.txt b/Documentation/networking/PLIP.txt
new file mode 100644
index 00000000000..ad7e3f7c3bb
--- /dev/null
+++ b/Documentation/networking/PLIP.txt
@@ -0,0 +1,215 @@
+PLIP: The Parallel Line Internet Protocol Device
+
+Donald Becker (becker@super.org)
+I.D.A. Supercomputing Research Center, Bowie MD 20715
+
+At some point T. Thorn will probably contribute text,
+Tommy Thorn (tthorn@daimi.aau.dk)
+
+PLIP Introduction
+-----------------
+
+This document describes the parallel port packet pusher for Net/LGX.
+This device interface allows a point-to-point connection between two
+parallel ports to appear as a IP network interface.
+
+What is PLIP?
+=============
+
+PLIP is Parallel Line IP, that is, the transportation of IP packages
+over a parallel port. In the case of a PC, the obvious choice is the
+printer port.  PLIP is a non-standard, but [can use] uses the standard
+LapLink null-printer cable [can also work in turbo mode, with a PLIP
+cable]. [The protocol used to pack IP packages, is a simple one
+initiated by Crynwr.]
+
+Advantages of PLIP
+==================
+
+It's cheap, it's available everywhere, and it's easy.
+
+The PLIP cable is all that's needed to connect two Linux boxes, and it
+can be built for very few bucks.
+
+Connecting two Linux boxes takes only a second's decision and a few
+minutes' work, no need to search for a [supported] netcard. This might
+even be especially important in the case of notebooks, where netcards
+are not easily available.
+
+Not requiring a netcard also means that apart from connecting the
+cables, everything else is software configuration [which in principle
+could be made very easy.]
+
+Disadvantages of PLIP
+=====================
+
+Doesn't work over a modem, like SLIP and PPP. Limited range, 15 m.
+Can only be used to connect three (?) Linux boxes. Doesn't connect to
+an existing Ethernet. Isn't standard (not even de facto standard, like
+SLIP).
+
+Performance
+===========
+
+PLIP easily outperforms Ethernet cards....(ups, I was dreaming, but
+it *is* getting late. EOB)
+
+PLIP driver details
+-------------------
+
+The Linux PLIP driver is an implementation of the original Crynwr protocol,
+that uses the parallel port subsystem of the kernel in order to properly
+share parallel ports between PLIP and other services.
+
+IRQs and trigger timeouts
+=========================
+
+When a parallel port used for a PLIP driver has an IRQ configured to it, the
+PLIP driver is signaled whenever data is sent to it via the cable, such that
+when no data is available, the driver isn't being used.
+
+However, on some machines it is hard, if not impossible, to configure an IRQ
+to a certain parallel port, mainly because it is used by some other device.
+On these machines, the PLIP driver can be used in IRQ-less mode, where
+the PLIP driver would constantly poll the parallel port for data waiting,
+and if such data is available, process it. This mode is less efficient than
+the IRQ mode, because the driver has to check the parallel port many times
+per second, even when no data at all is sent. Some rough measurements
+indicate that there isn't a noticeable performance drop when using IRQ-less
+mode as compared to IRQ mode as far as the data transfer speed is involved.
+There is a performance drop on the machine hosting the driver.
+
+When the PLIP driver is used in IRQ mode, the timeout used for triggering a
+data transfer (the maximal time the PLIP driver would allow the other side
+before announcing a timeout, when trying to handshake a transfer of some
+data) is, by default, 500usec. As IRQ delivery is more or less immediate,
+this timeout is quite sufficient. 
+
+When in IRQ-less mode, the PLIP driver polls the parallel port HZ times
+per second (where HZ is typically 100 on most platforms, and 1024 on an
+Alpha, as of this writing). Between two such polls, there are 10^6/HZ usecs.
+On an i386, for example, 10^6/100 = 10000usec. It is easy to see that it is
+quite possible for the trigger timeout to expire between two such polls, as
+the timeout is only 500usec long. As a result, it is required to change the
+trigger timeout on the *other* side of a PLIP connection, to about
+10^6/HZ usecs. If both sides of a PLIP connection are used in IRQ-less mode,
+this timeout is required on both sides.
+
+It appears that in practice, the trigger timeout can be shorter than in the
+above calculation. It isn't an important issue, unless the wire is faulty,
+in which case a long timeout would stall the machine when, for whatever
+reason, bits are dropped.
+
+A utility that can perform this change in Linux is plipconfig, which is part
+of the net-tools package (its location can be found in the
+Documentation/Changes file). An example command would be
+'plipconfig plipX trigger 10000', where plipX is the appropriate
+PLIP device.
+
+PLIP hardware interconnection
+-----------------------------
+
+PLIP uses several different data transfer methods.  The first (and the
+only one implemented in the early version of the code) uses a standard
+printer "null" cable to transfer data four bits at a time using
+data bit outputs connected to status bit inputs.
+
+The second data transfer method relies on both machines having
+bi-directional parallel ports, rather than output-only ``printer''
+ports.  This allows byte-wide transfers and avoids reconstructing
+nibbles into bytes, leading to much faster transfers.
+
+Parallel Transfer Mode 0 Cable
+==============================
+
+The cable for the first transfer mode is a standard
+printer "null" cable which transfers data four bits at a time using
+data bit outputs of the first port (machine T) connected to the
+status bit inputs of the second port (machine R).  There are five
+status inputs, and they are used as four data inputs and a clock (data
+strobe) input, arranged so that the data input bits appear as contiguous
+bits with standard status register implementation.
+
+A cable that implements this protocol is available commercially as a
+"Null Printer" or "Turbo Laplink" cable.  It can be constructed with
+two DB-25 male connectors symmetrically connected as follows:
+
+    STROBE output       1*
+    D0->ERROR   2 - 15          15 - 2
+    D1->SLCT    3 - 13          13 - 3
+    D2->PAPOUT  4 - 12          12 - 4
+    D3->ACK     5 - 10          10 - 5
+    D4->BUSY    6 - 11          11 - 6
+    D5,D6,D7 are   7*, 8*, 9*
+    AUTOFD output 14*
+    INIT   output 16*
+    SLCTIN      17 - 17
+    extra grounds are 18*,19*,20*,21*,22*,23*,24*
+    GROUND      25 - 25
+* Do not connect these pins on either end
+
+If the cable you are using has a metallic shield it should be
+connected to the metallic DB-25 shell at one end only.
+
+Parallel Transfer Mode 1
+========================
+
+The second data transfer method relies on both machines having
+bi-directional parallel ports, rather than output-only ``printer''
+ports.  This allows byte-wide transfers, and avoids reconstructing
+nibbles into bytes.  This cable should not be used on unidirectional
+``printer'' (as opposed to ``parallel'') ports or when the machine
+isn't configured for PLIP, as it will result in output driver
+conflicts and the (unlikely) possibility of damage.
+
+The cable for this transfer mode should be constructed as follows:
+
+    STROBE->BUSY 1 - 11
+    D0->D0      2 - 2
+    D1->D1      3 - 3
+    D2->D2      4 - 4
+    D3->D3      5 - 5
+    D4->D4      6 - 6
+    D5->D5      7 - 7
+    D6->D6      8 - 8
+    D7->D7      9 - 9
+    INIT -> ACK  16 - 10
+    AUTOFD->PAPOUT 14 - 12
+    SLCT->SLCTIN 13 - 17
+    GND->ERROR  18 - 15
+    extra grounds are 19*,20*,21*,22*,23*,24*
+    GROUND      25 - 25
+* Do not connect these pins on either end
+
+Once again, if the cable you are using has a metallic shield it should
+be connected to the metallic DB-25 shell at one end only.
+
+PLIP Mode 0 transfer protocol
+=============================
+
+The PLIP driver is compatible with the "Crynwr" parallel port transfer
+standard in Mode 0.  That standard specifies the following protocol:
+
+   send header nibble '0x8'
+   count-low octet
+   count-high octet
+   ... data octets
+   checksum octet
+
+Each octet is sent as
+        <wait for rx. '0x1?'>   <send 0x10+(octet&0x0F)>
+        <wait for rx. '0x0?'>   <send 0x00+((octet>>4)&0x0F)>
+
+To start a transfer the transmitting machine outputs a nibble 0x08.
+That raises the ACK line, triggering an interrupt in the receiving
+machine.  The receiving machine disables interrupts and raises its own ACK
+line. 
+
+Restated:
+
+(OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
+Send_Byte:
+   OUT := low nibble, OUT.4 := 1
+   WAIT FOR IN.4 = 1
+   OUT := high nibble, OUT.4 := 0
+   WAIT FOR IN.4 = 0
diff --git a/Documentation/networking/README.sb1000 b/Documentation/networking/README.sb1000
new file mode 100644
index 00000000000..f82d42584e9
--- /dev/null
+++ b/Documentation/networking/README.sb1000
@@ -0,0 +1,207 @@
+sb1000 is a module network device driver for the General Instrument (also known
+as NextLevel) SURFboard1000 internal cable modem board.  This is an ISA card
+which is used by a number of cable TV companies to provide cable modem access.
+It's a one-way downstream-only cable modem, meaning that your upstream net link
+is provided by your regular phone modem.
+
+This driver was written by Franco Venturi <fventuri@mediaone.net>.  He deserves
+a great deal of thanks for this wonderful piece of code!
+
+-----------------------------------------------------------------------------
+
+Support for this device is now a part of the standard Linux kernel.  The
+driver source code file is drivers/net/sb1000.c.  In addition to this
+you will need:
+
+1.) The "cmconfig" program.  This is a utility which supplements "ifconfig"
+to configure the cable modem and network interface (usually called "cm0");
+and
+
+2.) Several PPP scripts which live in /etc/ppp to make connecting via your
+cable modem easy.
+
+   These utilities can be obtained from:
+
+      http://www.jacksonville.net/~fventuri/
+
+   in Franco's original source code distribution .tar.gz file.  Support for
+   the sb1000 driver can be found at:
+
+      http://home.adelphia.net/~siglercm/sb1000.html
+      http://linuxpower.cx/~cable/
+
+   along with these utilities.
+
+3.) The standard isapnp tools.  These are necessary to configure your SB1000
+card at boot time (or afterwards by hand) since it's a PnP card.
+
+   If you don't have these installed as a standard part of your Linux
+   distribution, you can find them at:
+
+      http://www.roestock.demon.co.uk/isapnptools/
+
+   or check your Linux distribution binary CD or their web site.  For help with
+   isapnp, pnpdump, or /etc/isapnp.conf, go to:
+
+      http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html
+
+-----------------------------------------------------------------------------
+
+To make the SB1000 card work, follow these steps:
+
+1.) Run `make config', or `make menuconfig', or `make xconfig', whichever
+you prefer, in the top kernel tree directory to set up your kernel
+configuration.  Make sure to say "Y" to "Prompt for development drivers"
+and to say "M" to the sb1000 driver.  Also say "Y" or "M" to all the standard
+networking questions to get TCP/IP and PPP networking support.
+
+2.) *BEFORE* you build the kernel, edit drivers/net/sb1000.c.  Make sure
+to redefine the value of READ_DATA_PORT to match the I/O address used
+by isapnp to access your PnP cards.  This is the value of READPORT in
+/etc/isapnp.conf or given by the output of pnpdump.
+
+3.) Build and install the kernel and modules as usual.
+
+4.) Boot your new kernel following the usual procedures.
+
+5.) Set up to configure the new SB1000 PnP card by capturing the output
+of "pnpdump" to a file and editing this file to set the correct I/O ports,
+IRQ, and DMA settings for all your PnP cards.  Make sure none of the settings
+conflict with one another.  Then test this configuration by running the
+"isapnp" command with your new config file as the input.  Check for
+errors and fix as necessary.  (As an aside, I use I/O ports 0x110 and
+0x310 and IRQ 11 for my SB1000 card and these work well for me.  YMMV.)
+Then save the finished config file as /etc/isapnp.conf for proper configuration
+on subsequent reboots.
+
+6.) Download the original file sb1000-1.1.2.tar.gz from Franco's site or one of
+the others referenced above.  As root, unpack it into a temporary directory and
+do a `make cmconfig' and then `install -c cmconfig /usr/local/sbin'.  Don't do
+`make install' because it expects to find all the utilities built and ready for
+installation, not just cmconfig.
+
+7.) As root, copy all the files under the ppp/ subdirectory in Franco's
+tar file into /etc/ppp, being careful not to overwrite any files that are
+already in there.  Then modify ppp@gi-on to set the correct login name,
+phone number, and frequency for the cable modem.  Also edit pap-secrets
+to specify your login name and password and any site-specific information
+you need.
+
+8.) Be sure to modify /etc/ppp/firewall to use ipchains instead of
+the older ipfwadm commands from the 2.0.x kernels.  There's a neat utility to
+convert ipfwadm commands to ipchains commands:
+
+   http://users.dhp.com/~whisper/ipfwadm2ipchains/
+
+You may also wish to modify the firewall script to implement a different
+firewalling scheme.
+
+9.) Start the PPP connection via the script /etc/ppp/ppp@gi-on.  You must be
+root to do this.  It's better to use a utility like sudo to execute
+frequently used commands like this with root permissions if possible.  If you
+connect successfully the cable modem interface will come up and you'll see a
+driver message like this at the console:
+
+         cm0: sb1000 at (0x110,0x310), csn 1, S/N 0x2a0d16d8, IRQ 11.
+         sb1000.c:v1.1.2 6/01/98 (fventuri@mediaone.net)
+
+The "ifconfig" command should show two new interfaces, ppp0 and cm0.
+The command "cmconfig cm0" will give you information about the cable modem
+interface.
+
+10.) Try pinging a site via `ping -c 5 www.yahoo.com', for example.  You should
+see packets received.
+
+11.) If you can't get site names (like www.yahoo.com) to resolve into
+IP addresses (like 204.71.200.67), be sure your /etc/resolv.conf file
+has no syntax errors and has the right nameserver IP addresses in it.
+If this doesn't help, try something like `ping -c 5 204.71.200.67' to
+see if the networking is running but the DNS resolution is where the
+problem lies.
+
+12.) If you still have problems, go to the support web sites mentioned above
+and read the information and documentation there.
+
+-----------------------------------------------------------------------------
+
+Common problems:
+
+1.) Packets go out on the ppp0 interface but don't come back on the cm0
+interface.  It looks like I'm connected but I can't even ping any
+numerical IP addresses.  (This happens predominantly on Debian systems due
+to a default boot-time configuration script.)
+
+Solution -- As root `echo 0 > /proc/sys/net/ipv4/conf/cm0/rp_filter' so it
+can share the same IP address as the ppp0 interface.  Note that this
+command should probably be added to the /etc/ppp/cablemodem script
+*right*between* the "/sbin/ifconfig" and "/sbin/cmconfig" commands.
+You may need to do this to /proc/sys/net/ipv4/conf/ppp0/rp_filter as well.
+If you do this to /proc/sys/net/ipv4/conf/default/rp_filter on each reboot
+(in rc.local or some such) then any interfaces can share the same IP
+addresses.
+
+2.) I get "unresolved symbol" error messages on executing `insmod sb1000.o'.
+
+Solution -- You probably have a non-matching kernel source tree and
+/usr/include/linux and /usr/include/asm header files.  Make sure you
+install the correct versions of the header files in these two directories.
+Then rebuild and reinstall the kernel.
+
+3.) When isapnp runs it reports an error, and my SB1000 card isn't working.
+
+Solution -- There's a problem with later versions of isapnp using the "(CHECK)"
+option in the lines that allocate the two I/O addresses for the SB1000 card.
+This first popped up on RH 6.0.  Delete "(CHECK)" for the SB1000 I/O addresses.
+Make sure they don't conflict with any other pieces of hardware first!  Then
+rerun isapnp and go from there.
+
+4.) I can't execute the /etc/ppp/ppp@gi-on file.
+
+Solution -- As root do `chmod ug+x /etc/ppp/ppp@gi-on'.
+
+5.) The firewall script isn't working (with 2.2.x and higher kernels).
+
+Solution -- Use the ipfwadm2ipchains script referenced above to convert the
+/etc/ppp/firewall script from the deprecated ipfwadm commands to ipchains.
+
+6.) I'm getting *tons* of firewall deny messages in the /var/kern.log,
+/var/messages, and/or /var/syslog files, and they're filling up my /var
+partition!!!
+
+Solution -- First, tell your ISP that you're receiving DoS (Denial of Service)
+and/or portscanning (UDP connection attempts) attacks!  Look over the deny
+messages to figure out what the attack is and where it's coming from.  Next,
+edit /etc/ppp/cablemodem and make sure the ",nobroadcast" option is turned on
+to the "cmconfig" command (uncomment that line).  If you're not receiving these
+denied packets on your broadcast interface (IP address xxx.yyy.zzz.255
+typically), then someone is attacking your machine in particular.  Be careful
+out there....
+
+7.) Everything seems to work fine but my computer locks up after a while
+(and typically during a lengthy download through the cable modem)!
+
+Solution -- You may need to add a short delay in the driver to 'slow down' the
+SURFboard because your PC might not be able to keep up with the transfer rate
+of the SB1000. To do this, it's probably best to download Franco's
+sb1000-1.1.2.tar.gz archive and build and install sb1000.o manually.  You'll
+want to edit the 'Makefile' and look for the 'SB1000_DELAY'
+define.  Uncomment those 'CFLAGS' lines (and comment out the default ones)
+and try setting the delay to something like 60 microseconds with:
+'-DSB1000_DELAY=60'.  Then do `make' and as root `make install' and try
+it out.  If it still doesn't work or you like playing with the driver, you may
+try other numbers.  Remember though that the higher the delay, the slower the
+driver (which slows down the rest of the PC too when it is actively
+used). Thanks to Ed Daiga for this tip!
+
+-----------------------------------------------------------------------------
+
+Credits:  This README came from Franco Venturi's original README file which is
+still supplied with his driver .tar.gz archive.  I and all other sb1000 users
+owe Franco a tremendous "Thank you!"  Additional thanks goes to Carl Patten
+and Ralph Bonnell who are now managing the Linux SB1000 web site, and to
+the SB1000 users who reported and helped debug the common problems listed
+above.
+
+
+                                        Clemmitt Sigler
+                                        csigler@vt.edu
diff --git a/Documentation/networking/TODO b/Documentation/networking/TODO
new file mode 100644
index 00000000000..66d36ff14ba
--- /dev/null
+++ b/Documentation/networking/TODO
@@ -0,0 +1,18 @@
+To-do items for network drivers
+-------------------------------
+
+* Move ethernet crc routine to generic code
+
+* (for 2.5) Integrate Jamal Hadi Salim's netdev Rx polling API change
+
+* Audit all net drivers to make sure magic packet / wake-on-lan /
+  similar features are disabled in the driver by default.
+
+* Audit all net drivers to make sure the module always prints out a
+  version string when loaded as a module, but only prints a version
+  string when built into the kernel if a device is detected.
+
+* Add ETHTOOL_GDRVINFO ioctl support to all ethernet drivers.
+
+* dmfe PCI DMA is totally wrong and only works on x86
+
diff --git a/Documentation/networking/alias.txt b/Documentation/networking/alias.txt
new file mode 100644
index 00000000000..cd12c2ff518
--- /dev/null
+++ b/Documentation/networking/alias.txt
@@ -0,0 +1,53 @@
+
+IP-Aliasing:
+============
+
+IP-aliases are additional IP-addresses/masks hooked up to a base 
+interface by adding a colon and a string when running ifconfig. 
+This string is usually numeric, but this is not a must.
+
+IP-Aliases are avail if CONFIG_INET (`standard' IPv4 networking) 
+is configured in the kernel.
+
+
+o Alias creation.
+  Alias creation is done by 'magic' interface naming: eg. to create a
+  200.1.1.1 alias for eth0 ...
+  
+    # ifconfig eth0:0 200.1.1.1  etc,etc....
+                   ~~ -> request alias #0 creation (if not yet exists) for eth0
+
+    The corresponding route is also set up by this command. 
+    Please note: The route always points to the base interface.
+        
+
+o Alias deletion.
+  The alias is removed by shutting the alias down:
+
+    # ifconfig eth0:0 down
+                 ~~~~~~~~~~ -> will delete alias
+
+                                   
+o Alias (re-)configuring
+
+  Aliases are not real devices, but programs should be able to configure and
+  refer to them as usual (ifconfig, route, etc).
+
+
+o Relationship with main device
+
+  If the base device is shut down the added aliases will be deleted 
+  too.
+
+
+Contact
+-------
+Please finger or e-mail me:
+   Juan Jose Ciarlante <jjciarla@raiz.uncu.edu.ar>
+
+Updated by Erik Schoenfelder <schoenfr@gaertner.DE>
+
+; local variables:
+; mode: indented-text
+; mode: auto-fill
+; end:
diff --git a/Documentation/networking/arcnet-hardware.txt b/Documentation/networking/arcnet-hardware.txt
new file mode 100644
index 00000000000..30a5f01403d
--- /dev/null
+++ b/Documentation/networking/arcnet-hardware.txt
@@ -0,0 +1,3133 @@
+ 
+-----------------------------------------------------------------------------
+1) This file is a supplement to arcnet.txt.  Please read that for general
+   driver configuration help.
+-----------------------------------------------------------------------------
+2) This file is no longer Linux-specific.  It should probably be moved out of
+   the kernel sources.  Ideas?
+-----------------------------------------------------------------------------
+
+Because so many people (myself included) seem to have obtained ARCnet cards
+without manuals, this file contains a quick introduction to ARCnet hardware,
+some cabling tips, and a listing of all jumper settings I can find. Please
+e-mail apenwarr@worldvisions.ca with any settings for your particular card,
+or any other information you have!
+
+
+INTRODUCTION TO ARCNET
+----------------------
+
+ARCnet is a network type which works in a way similar to popular Ethernet
+networks but which is also different in some very important ways.
+
+First of all, you can get ARCnet cards in at least two speeds: 2.5 Mbps
+(slower than Ethernet) and 100 Mbps (faster than normal Ethernet).  In fact,
+there are others as well, but these are less common.  The different hardware
+types, as far as I'm aware, are not compatible and so you cannot wire a
+100 Mbps card to a 2.5 Mbps card, and so on.  From what I hear, my driver does
+work with 100 Mbps cards, but I haven't been able to verify this myself,
+since I only have the 2.5 Mbps variety.  It is probably not going to saturate
+your 100 Mbps card.  Stop complaining. :)
+
+You also cannot connect an ARCnet card to any kind of Ethernet card and
+expect it to work.  
+
+There are two "types" of ARCnet - STAR topology and BUS topology.  This
+refers to how the cards are meant to be wired together.  According to most
+available documentation, you can only connect STAR cards to STAR cards and
+BUS cards to BUS cards.  That makes sense, right?  Well, it's not quite
+true; see below under "Cabling."
+
+Once you get past these little stumbling blocks, ARCnet is actually quite a
+well-designed standard.  It uses something called "modified token passing"
+which makes it completely incompatible with so-called "Token Ring" cards,
+but which makes transfers much more reliable than Ethernet does.  In fact,
+ARCnet will guarantee that a packet arrives safely at the destination, and
+even if it can't possibly be delivered properly (ie. because of a cable
+break, or because the destination computer does not exist) it will at least
+tell the sender about it.
+
+Because of the carefully defined action of the "token", it will always make
+a pass around the "ring" within a maximum length of time.  This makes it
+useful for realtime networks.
+
+In addition, all known ARCnet cards have an (almost) identical programming
+interface.  This means that with one ARCnet driver you can support any
+card, whereas with Ethernet each manufacturer uses what is sometimes a
+completely different programming interface, leading to a lot of different,
+sometimes very similar, Ethernet drivers.  Of course, always using the same
+programming interface also means that when high-performance hardware
+facilities like PCI bus mastering DMA appear, it's hard to take advantage of
+them.  Let's not go into that.
+
+One thing that makes ARCnet cards difficult to program for, however, is the
+limit on their packet sizes; standard ARCnet can only send packets that are
+up to 508 bytes in length.  This is smaller than the Internet "bare minimum"
+of 576 bytes, let alone the Ethernet MTU of 1500.  To compensate, an extra
+level of encapsulation is defined by RFC1201, which I call "packet
+splitting," that allows "virtual packets" to grow as large as 64K each,
+although they are generally kept down to the Ethernet-style 1500 bytes.
+
+For more information on the advantages and disadvantages (mostly the
+advantages) of ARCnet networks, you might try the "ARCnet Trade Association"
+WWW page:
+        http://www.arcnet.com
+
+
+CABLING ARCNET NETWORKS
+-----------------------
+
+This section was rewritten by 
+        Vojtech Pavlik     <vojtech@suse.cz>
+using information from several people, including:
+        Avery Pennraun     <apenwarr@worldvisions.ca>
+        Stephen A. Wood    <saw@hallc1.cebaf.gov>
+        John Paul Morrison <jmorriso@bogomips.ee.ubc.ca>
+        Joachim Koenig     <jojo@repas.de>
+and Avery touched it up a bit, at Vojtech's request.
+
+ARCnet (the classic 2.5 Mbps version) can be connected by two different
+types of cabling: coax and twisted pair.  The other ARCnet-type networks
+(100 Mbps TCNS and 320 kbps - 32 Mbps ARCnet Plus) use different types of
+cabling (Type1, Fiber, C1, C4, C5).
+
+For a coax network, you "should" use 93 Ohm RG-62 cable.  But other cables
+also work fine, because ARCnet is a very stable network. I personally use 75
+Ohm TV antenna cable.
+
+Cards for coax cabling are shipped in two different variants: for BUS and
+STAR network topologies.  They are mostly the same.  The only difference
+lies in the hybrid chip installed.  BUS cards use high impedance output,
+while STAR use low impedance.  Low impedance card (STAR) is electrically
+equal to a high impedance one with a terminator installed.
+
+Usually, the ARCnet networks are built up from STAR cards and hubs.  There
+are two types of hubs - active and passive.  Passive hubs are small boxes
+with four BNC connectors containing four 47 Ohm resistors:
+
+   |         | wires
+   R         + junction
+-R-+-R-      R 47 Ohm resistors
+   R
+   |
+
+The shielding is connected together.  Active hubs are much more complicated;
+they are powered and contain electronics to amplify the signal and send it
+to other segments of the net.  They usually have eight connectors.  Active
+hubs come in two variants - dumb and smart.  The dumb variant just
+amplifies, but the smart one decodes to digital and encodes back all packets
+coming through.  This is much better if you have several hubs in the net,
+since many dumb active hubs may worsen the signal quality.
+
+And now to the cabling.  What you can connect together:
+
+1. A card to a card.  This is the simplest way of creating a 2-computer
+   network.
+
+2. A card to a passive hub.  Remember that all unused connectors on the hub
+   must be properly terminated with 93 Ohm (or something else if you don't
+   have the right ones) terminators.
+        (Avery's note: oops, I didn't know that.  Mine (TV cable) works
+        anyway, though.)
+
+3. A card to an active hub.  Here is no need to terminate the unused
+   connectors except some kind of aesthetic feeling.  But, there may not be
+   more than eleven active hubs between any two computers.  That of course
+   doesn't limit the number of active hubs on the network.
+   
+4. An active hub to another.
+
+5. An active hub to passive hub.
+
+Remember, that you can not connect two passive hubs together.  The power loss
+implied by such a connection is too high for the net to operate reliably.
+
+An example of a typical ARCnet network:
+
+           R                     S - STAR type card              
+    S------H--------A-------S    R - Terminator
+           |        |            H - Hub                         
+           |        |            A - Active hub                  
+           |   S----H----S                                       
+           S        |                                            
+                    |                                            
+                    S                                            
+                                                                          
+The BUS topology is very similar to the one used by Ethernet.  The only
+difference is in cable and terminators: they should be 93 Ohm.  Ethernet
+uses 50 Ohm impedance. You use T connectors to put the computers on a single
+line of cable, the bus. You have to put terminators at both ends of the
+cable. A typical BUS ARCnet network looks like:
+
+    RT----T------T------T------T------TR
+     B    B      B      B      B      B
+
+  B - BUS type card
+  R - Terminator
+  T - T connector
+
+But that is not all! The two types can be connected together.  According to
+the official documentation the only way of connecting them is using an active
+hub:
+
+         A------T------T------TR
+         |      B      B      B
+     S---H---S
+         |
+         S
+
+The official docs also state that you can use STAR cards at the ends of
+BUS network in place of a BUS card and a terminator:
+
+     S------T------T------S
+            B      B
+
+But, according to my own experiments, you can simply hang a BUS type card
+anywhere in middle of a cable in a STAR topology network.  And more - you
+can use the bus card in place of any star card if you use a terminator. Then
+you can build very complicated networks fulfilling all your needs!  An
+example:
+
+                                  S
+                                  |
+           RT------T-------T------H------S
+            B      B       B      |
+                                  |       R
+    S------A------T-------T-------A-------H------TR                    
+           |      B       B       |       |      B                         
+           |   S                 BT       |                                 
+           |   |                  |  S----A-----S
+    S------H---A----S             |       | 
+           |   |      S------T----H---S   |
+           S   S             B    R       S  
+                                                               
+A basically different cabling scheme is used with Twisted Pair cabling. Each
+of the TP cards has two RJ (phone-cord style) connectors.  The cards are
+then daisy-chained together using a cable connecting every two neighboring
+cards.  The ends are terminated with RJ 93 Ohm terminators which plug into
+the empty connectors of cards on the ends of the chain.  An example:
+
+          ___________   ___________
+      _R_|_         _|_|_         _|_R_  
+     |     |       |     |       |     |      
+     |Card |       |Card |       |Card |     
+     |_____|       |_____|       |_____|          
+
+
+There are also hubs for the TP topology.  There is nothing difficult
+involved in using them; you just connect a TP chain to a hub on any end or
+even at both.  This way you can create almost any network configuration. 
+The maximum of 11 hubs between any two computers on the net applies here as
+well.  An example:
+
+    RP-------P--------P--------H-----P------P-----PR
+                               |
+      RP-----H--------P--------H-----P------PR
+             |                 |
+             PR                PR
+
+    R - RJ Terminator
+    P - TP Card
+    H - TP Hub
+
+Like any network, ARCnet has a limited cable length.  These are the maximum
+cable lengths between two active ends (an active end being an active hub or
+a STAR card).
+
+                RG-62       93 Ohm up to 650 m
+                RG-59/U     75 Ohm up to 457 m
+                RG-11/U     75 Ohm up to 533 m
+                IBM Type 1 150 Ohm up to 200 m
+                IBM Type 3 100 Ohm up to 100 m
+
+The maximum length of all cables connected to a passive hub is limited to 65
+meters for RG-62 cabling; less for others.  You can see that using passive
+hubs in a large network is a bad idea. The maximum length of a single "BUS
+Trunk" is about 300 meters for RG-62. The maximum distance between the two
+most distant points of the net is limited to 3000 meters. The maximum length
+of a TP cable between two cards/hubs is 650 meters.
+
+
+SETTING THE JUMPERS
+-------------------
+
+All ARCnet cards should have a total of four or five different settings:
+
+  - the I/O address:  this is the "port" your ARCnet card is on.  Probed
+    values in the Linux ARCnet driver are only from 0x200 through 0x3F0. (If
+    your card has additional ones, which is possible, please tell me.) This
+    should not be the same as any other device on your system.  According to
+    a doc I got from Novell, MS Windows prefers values of 0x300 or more,
+    eating net connections on my system (at least) otherwise.  My guess is
+    this may be because, if your card is at 0x2E0, probing for a serial port
+    at 0x2E8 will reset the card and probably mess things up royally.
+        - Avery's favourite: 0x300.
+
+  - the IRQ: on  8-bit cards, it might be 2 (9), 3, 4, 5, or 7.
+             on 16-bit cards, it might be 2 (9), 3, 4, 5, 7, or 10-15.
+             
+    Make sure this is different from any other card on your system.  Note
+    that IRQ2 is the same as IRQ9, as far as Linux is concerned.  You can
+    "cat /proc/interrupts" for a somewhat complete list of which ones are in
+    use at any given time.  Here is a list of common usages from Vojtech
+    Pavlik <vojtech@suse.cz>:
+        ("Not on bus" means there is no way for a card to generate this
+        interrupt)
+        IRQ  0 - Timer 0 (Not on bus)
+        IRQ  1 - Keyboard (Not on bus)
+        IRQ  2 - IRQ Controller 2 (Not on bus, nor does interrupt the CPU)
+        IRQ  3 - COM2
+        IRQ  4 - COM1
+        IRQ  5 - FREE (LPT2 if you have it; sometimes COM3; maybe PLIP)
+        IRQ  6 - Floppy disk controller
+        IRQ  7 - FREE (LPT1 if you don't use the polling driver; PLIP) 
+        IRQ  8 - Realtime Clock Interrupt (Not on bus)
+        IRQ  9 - FREE (VGA vertical sync interrupt if enabled)
+        IRQ 10 - FREE
+        IRQ 11 - FREE
+        IRQ 12 - FREE
+        IRQ 13 - Numeric Coprocessor (Not on bus)
+        IRQ 14 - Fixed Disk Controller
+        IRQ 15 - FREE (Fixed Disk Controller 2 if you have it) 
+        
+        Note: IRQ 9 is used on some video cards for the "vertical retrace"
+        interrupt.  This interrupt would have been handy for things like
+        video games, as it occurs exactly once per screen refresh, but
+        unfortunately IBM cancelled this feature starting with the original
+        VGA and thus many VGA/SVGA cards do not support it.  For this
+        reason, no modern software uses this interrupt and it can almost
+        always be safely disabled, if your video card supports it at all.
+        
+        If your card for some reason CANNOT disable this IRQ (usually there
+        is a jumper), one solution would be to clip the printed circuit
+        contact on the board: it's the fourth contact from the left on the
+        back side.  I take no responsibility if you try this.
+
+        - Avery's favourite: IRQ2 (actually IRQ9).  Watch that VGA, though.
+
+  - the memory address:  Unlike most cards, ARCnets use "shared memory" for
+    copying buffers around.  Make SURE it doesn't conflict with any other
+    used memory in your system!
+        A0000           - VGA graphics memory (ok if you don't have VGA)
+        B0000           - Monochrome text mode
+        C0000           \  One of these is your VGA BIOS - usually C0000.
+        E0000           /
+        F0000           - System BIOS
+
+    Anything less than 0xA0000 is, well, a BAD idea since it isn't above
+    640k.
+        - Avery's favourite: 0xD0000
+
+  - the station address:  Every ARCnet card has its own "unique" network
+    address from 0 to 255.  Unlike Ethernet, you can set this address
+    yourself with a jumper or switch (or on some cards, with special
+    software).  Since it's only 8 bits, you can only have 254 ARCnet cards
+    on a network.  DON'T use 0 or 255, since these are reserved (although
+    neat stuff will probably happen if you DO use them).  By the way, if you
+    haven't already guessed, don't set this the same as any other ARCnet on
+    your network!
+        - Avery's favourite:  3 and 4.  Not that it matters.
+
+  - There may be ETS1 and ETS2 settings.  These may or may not make a
+    difference on your card (many manuals call them "reserved"), but are
+    used to change the delays used when powering up a computer on the
+    network.  This is only necessary when wiring VERY long range ARCnet
+    networks, on the order of 4km or so; in any case, the only real
+    requirement here is that all cards on the network with ETS1 and ETS2
+    jumpers have them in the same position.  Chris Hindy <chrish@io.org>
+    sent in a chart with actual values for this:
+        ET1     ET2     Response Time   Reconfiguration Time
+        ---     ---     -------------   --------------------
+        open    open    74.7us          840us
+        open    closed  283.4us         1680us
+        closed  open    561.8us         1680us
+        closed  closed  1118.6us        1680us
+    
+    Make sure you set ETS1 and ETS2 to the SAME VALUE for all cards on your
+    network.
+    
+Also, on many cards (not mine, though) there are red and green LED's. 
+Vojtech Pavlik <vojtech@suse.cz> tells me this is what they mean:
+        GREEN           RED             Status
+        -----           ---             ------
+        OFF             OFF             Power off
+        OFF             Short flashes   Cabling problems (broken cable or not
+                                          terminated)
+        OFF (short)     ON              Card init
+        ON              ON              Normal state - everything OK, nothing
+                                          happens
+        ON              Long flashes    Data transfer
+        ON              OFF             Never happens (maybe when wrong ID)
+
+
+The following is all the specific information people have sent me about
+their own particular ARCnet cards.  It is officially a mess, and contains
+huge amounts of duplicated information.  I have no time to fix it.  If you
+want to, PLEASE DO!  Just send me a 'diff -u' of all your changes.
+
+The model # is listed right above specifics for that card, so you should be
+able to use your text viewer's "search" function to find the entry you want. 
+If you don't KNOW what kind of card you have, try looking through the
+various diagrams to see if you can tell.
+
+If your model isn't listed and/or has different settings, PLEASE PLEASE
+tell me.  I had to figure mine out without the manual, and it WASN'T FUN!
+
+Even if your ARCnet model isn't listed, but has the same jumpers as another
+model that is, please e-mail me to say so.
+
+Cards Listed in this file (in this order, mostly):
+
+        Manufacturer    Model #                 Bits
+        ------------    -------                 ----
+        SMC             PC100                   8
+        SMC             PC110                   8
+        SMC             PC120                   8
+        SMC             PC130                   8
+        SMC             PC270E                  8
+        SMC             PC500                   16
+        SMC             PC500Longboard          16
+        SMC             PC550Longboard          16
+        SMC             PC600                   16
+        SMC             PC710                   8
+        SMC?            LCS-8830(-T)            8/16
+        Puredata        PDI507                  8
+        CNet Tech       CN120-Series            8
+        CNet Tech       CN160-Series            16
+        Lantech?        UM9065L chipset         8
+        Acer            5210-003                8
+        Datapoint?      LAN-ARC-8               8
+        Topware         TA-ARC/10               8
+        Thomas-Conrad   500-6242-0097 REV A     8
+        Waterloo?       (C)1985 Waterloo Micro. 8
+        No Name         --                      8/16
+        No Name         Taiwan R.O.C?           8
+        No Name         Model 9058              8
+        Tiara           Tiara Lancard?          8
+        
+
+** SMC = Standard Microsystems Corp.
+** CNet Tech = CNet Technology, Inc.
+
+
+Unclassified Stuff
+------------------
+  - Please send any other information you can find.
+  
+  - And some other stuff (more info is welcome!):
+     From: root@ultraworld.xs4all.nl (Timo Hilbrink)
+     To: apenwarr@foxnet.net (Avery Pennarun)
+     Date: Wed, 26 Oct 1994 02:10:32 +0000 (GMT)
+     Reply-To: timoh@xs4all.nl
+
+     [...parts deleted...]
+
+     About the jumpers: On my PC130 there is one more jumper, located near the
+     cable-connector and it's for changing to star or bus topology; 
+     closed: star - open: bus
+     On the PC500 are some more jumper-pins, one block labeled with RX,PDN,TXI
+     and another with ALE,LA17,LA18,LA19 these are undocumented..
+
+     [...more parts deleted...]
+
+     --- CUT ---
+
+
+** Standard Microsystems Corp (SMC) **
+PC100, PC110, PC120, PC130 (8-bit cards)
+PC500, PC600 (16-bit cards)
+---------------------------------
+  - mainly from Avery Pennarun <apenwarr@worldvisions.ca>.  Values depicted
+    are from Avery's setup.
+  - special thanks to Timo Hilbrink <timoh@xs4all.nl> for noting that PC120,
+    130, 500, and 600 all have the same switches as Avery's PC100. 
+    PC500/600 have several extra, undocumented pins though. (?)
+  - PC110 settings were verified by Stephen A. Wood <saw@cebaf.gov>
+  - Also, the JP- and S-numbers probably don't match your card exactly.  Try
+    to find jumpers/switches with the same number of settings - it's
+    probably more reliable.
+  
+
+     JP5                       [|]    :    :    :    :
+(IRQ Setting)                 IRQ2  IRQ3 IRQ4 IRQ5 IRQ7
+                Put exactly one jumper on exactly one set of pins.
+
+
+                          1  2   3  4  5  6   7  8  9 10
+     S1                /----------------------------------\
+(I/O and Memory        |  1  1 * 0  0  0  0 * 1  1  0  1  |
+ addresses)            \----------------------------------/
+                          |--|   |--------|   |--------|
+                          (a)       (b)           (m)
+                          
+                WARNING.  It's very important when setting these which way
+                you're holding the card, and which way you think is '1'!
+                
+                If you suspect that your settings are not being made
+                correctly, try reversing the direction or inverting the
+                switch positions.
+
+                a: The first digit of the I/O address.
+                        Setting         Value
+                        -------         -----
+                        00              0
+                        01              1
+                        10              2
+                        11              3
+
+                b: The second digit of the I/O address.
+                        Setting         Value
+                        -------         -----
+                        0000            0
+                        0001            1
+                        0010            2
+                        ...             ...
+                        1110            E
+                        1111            F
+
+                The I/O address is in the form ab0.  For example, if
+                a is 0x2 and b is 0xE, the address will be 0x2E0.
+
+                DO NOT SET THIS LESS THAN 0x200!!!!!
+
+
+                m: The first digit of the memory address.
+                        Setting         Value
+                        -------         -----
+                        0000            0
+                        0001            1
+                        0010            2
+                        ...             ...
+                        1110            E
+                        1111            F
+
+                The memory address is in the form m0000.  For example, if
+                m is D, the address will be 0xD0000.
+
+                DO NOT SET THIS TO C0000, F0000, OR LESS THAN A0000!
+
+                          1  2  3  4  5  6  7  8
+     S2                /--------------------------\
+(Station Address)      |  1  1  0  0  0  0  0  0  |
+                       \--------------------------/
+
+                        Setting         Value
+                        -------         -----
+                        00000000        00
+                        10000000        01
+                        01000000        02
+                        ...
+                        01111111        FE
+                        11111111        FF
+
+                Note that this is binary with the digits reversed!
+
+                DO NOT SET THIS TO 0 OR 255 (0xFF)!
+
+
+*****************************************************************************
+
+** Standard Microsystems Corp (SMC) **
+PC130E/PC270E (8-bit cards)
+---------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+
+
+STANDARD MICROSYSTEMS CORPORATION (SMC) ARCNET(R)-PC130E/PC270E
+===============================================================
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the following Original SMC Manual 
+
+             "Configuration Guide for
+             ARCNET(R)-PC130E/PC270
+            Network Controller Boards
+                Pub. # 900.044A
+                   June, 1989"
+
+ARCNET is a registered trademark of the Datapoint Corporation
+SMC is a registered trademark of the Standard Microsystems Corporation  
+
+The PC130E is an enhanced version of the PC130 board, is equipped with a 
+standard BNC female connector for connection to RG-62/U coax cable.
+Since this board is designed both for point-to-point connection in star
+networks and for connection to bus networks, it is downwardly compatible 
+with all the other standard boards designed for coax networks (that is,
+the PC120, PC110 and PC100 star topology boards and the PC220, PC210 and 
+PC200 bus topology boards).
+
+The PC270E is an enhanced version of the PC260 board, is equipped with two 
+modular RJ11-type jacks for connection to twisted pair wiring.
+It can be used in a star or a daisy-chained network.
+
+
+         8 7 6 5 4 3 2 1
+    ________________________________________________________________
+   |   |       S1        |                                          |
+   |   |_________________|                                          |
+   |    Offs|Base |I/O Addr                                         |
+   |     RAM Addr |                                              ___|
+   |         ___  ___                                       CR3 |___|
+   |        |   \/   |                                      CR4 |___|
+   |        |  PROM  |                                           ___|
+   |        |        |                                        N |   | 8
+   |        | SOCKET |                                        o |   | 7
+   |        |________|                                        d |   | 6
+   |                   ___________________                    e |   | 5
+   |                  |                   |                   A | S | 4
+   |       |oo| EXT2  |                   |                   d | 2 | 3
+   |       |oo| EXT1  |       SMC         |                   d |   | 2
+   |       |oo| ROM   |      90C63        |                   r |___| 1
+   |       |oo| IRQ7  |                   |               |o|  _____|
+   |       |oo| IRQ5  |                   |               |o| | J1  |
+   |       |oo| IRQ4  |                   |              STAR |_____|
+   |       |oo| IRQ3  |                   |                   | J2  |
+   |       |oo| IRQ2  |___________________|                   |_____|
+   |___                                               ______________|
+       |                                             |
+       |_____________________________________________|
+
+Legend:
+
+SMC 90C63       ARCNET Controller / Transceiver /Logic
+S1      1-3:    I/O Base Address Select
+        4-6:    Memory Base Address Select
+        7-8:    RAM Offset Select
+S2      1-8:    Node ID Select
+EXT             Extended Timeout Select
+ROM             ROM Enable Select
+STAR            Selected - Star Topology        (PC130E only)
+                Deselected - Bus Topology       (PC130E only)
+CR3/CR4         Diagnostic LEDs
+J1              BNC RG62/U Connector            (PC130E only)
+J1              6-position Telephone Jack       (PC270E only)
+J2              6-position Telephone Jack       (PC270E only)
+
+Setting one of the switches to Off/Open means "1", On/Closed means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group S2 are used to set the node ID.
+These switches work in a way similar to the PC100-series cards; see that
+entry for more information.
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first three switches in switch group S1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch | Hex I/O
+   1 2 3  | Address
+   -------|--------
+   0 0 0  |  260
+   0 0 1  |  290
+   0 1 0  |  2E0  (Manufacturer's default)
+   0 1 1  |  2F0
+   1 0 0  |  300
+   1 0 1  |  350
+   1 1 0  |  380
+   1 1 1  |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer requires 2K of a 16K block of RAM. The base of this
+16K block can be located in any of eight positions.
+Switches 4-6 of switch group S1 select the Base of the 16K block.
+Within that 16K address space, the buffer may be assigned any one of four 
+positions, determined by the offset, switches 7 and 8 of group S1.
+
+   Switch     | Hex RAM | Hex ROM
+   4 5 6  7 8 | Address | Address *)
+   -----------|---------|-----------
+   0 0 0  0 0 |  C0000  |  C2000
+   0 0 0  0 1 |  C0800  |  C2000
+   0 0 0  1 0 |  C1000  |  C2000
+   0 0 0  1 1 |  C1800  |  C2000
+              |         |
+   0 0 1  0 0 |  C4000  |  C6000
+   0 0 1  0 1 |  C4800  |  C6000
+   0 0 1  1 0 |  C5000  |  C6000
+   0 0 1  1 1 |  C5800  |  C6000
+              |         |
+   0 1 0  0 0 |  CC000  |  CE000
+   0 1 0  0 1 |  CC800  |  CE000
+   0 1 0  1 0 |  CD000  |  CE000
+   0 1 0  1 1 |  CD800  |  CE000
+              |         |
+   0 1 1  0 0 |  D0000  |  D2000  (Manufacturer's default)
+   0 1 1  0 1 |  D0800  |  D2000
+   0 1 1  1 0 |  D1000  |  D2000
+   0 1 1  1 1 |  D1800  |  D2000
+              |         |
+   1 0 0  0 0 |  D4000  |  D6000
+   1 0 0  0 1 |  D4800  |  D6000
+   1 0 0  1 0 |  D5000  |  D6000
+   1 0 0  1 1 |  D5800  |  D6000
+              |         |
+   1 0 1  0 0 |  D8000  |  DA000
+   1 0 1  0 1 |  D8800  |  DA000
+   1 0 1  1 0 |  D9000  |  DA000
+   1 0 1  1 1 |  D9800  |  DA000
+              |         |
+   1 1 0  0 0 |  DC000  |  DE000
+   1 1 0  0 1 |  DC800  |  DE000
+   1 1 0  1 0 |  DD000  |  DE000
+   1 1 0  1 1 |  DD800  |  DE000
+              |         |
+   1 1 1  0 0 |  E0000  |  E2000
+   1 1 1  0 1 |  E0800  |  E2000
+   1 1 1  1 0 |  E1000  |  E2000
+   1 1 1  1 1 |  E1800  |  E2000
+  
+*) To enable the 8K Boot PROM install the jumper ROM.
+   The default is jumper ROM not installed.
+
+
+Setting the Timeouts and Interrupt
+----------------------------------
+
+The jumpers labeled EXT1 and EXT2 are used to determine the timeout 
+parameters. These two jumpers are normally left open.
+
+To select a hardware interrupt level set one (only one!) of the jumpers
+IRQ2, IRQ3, IRQ4, IRQ5, IRQ7. The Manufacturer's default is IRQ2.
+ 
+
+Configuring the PC130E for Star or Bus Topology
+-----------------------------------------------
+
+The single jumper labeled STAR is used to configure the PC130E board for 
+star or bus topology.
+When the jumper is installed, the board may be used in a star network, when 
+it is removed, the board can be used in a bus topology.
+
+
+Diagnostic LEDs
+---------------
+
+Two diagnostic LEDs are visible on the rear bracket of the board.
+The green LED monitors the network activity: the red one shows the
+board activity:
+
+ Green  | Status               Red      | Status
+ -------|-------------------   ---------|-------------------
+  on    | normal activity      flash/on | data transfer
+  blink | reconfiguration      off      | no data transfer;
+  off   | defective board or            | incorrect memory or
+        | node ID is zero               | I/O address
+
+
+*****************************************************************************
+
+** Standard Microsystems Corp (SMC) **
+PC500/PC550 Longboard (16-bit cards)
+-------------------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+
+
+STANDARD MICROSYSTEMS CORPORATION (SMC) ARCNET-PC500/PC550 Long Board
+=====================================================================
+
+Note: There is another Version of the PC500 called Short Version, which 
+      is different in hard- and software! The most important differences
+      are:
+      - The long board has no Shared memory.
+      - On the long board the selection of the interrupt is done by binary
+        coded switch, on the short board directly by jumper.
+        
+[Avery's note: pay special attention to that: the long board HAS NO SHARED
+MEMORY.  This means the current Linux-ARCnet driver can't use these cards. 
+I have obtained a PC500Longboard and will be doing some experiments on it in
+the future, but don't hold your breath.  Thanks again to Juergen Seifert for
+his advice about this!]
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the following Original SMC Manual 
+
+             "Configuration Guide for
+             SMC ARCNET-PC500/PC550
+         Series Network Controller Boards
+             Pub. # 900.033 Rev. A
+                November, 1989"
+
+ARCNET is a registered trademark of the Datapoint Corporation
+SMC is a registered trademark of the Standard Microsystems Corporation  
+
+The PC500 is equipped with a standard BNC female connector for connection
+to RG-62/U coax cable.
+The board is designed both for point-to-point connection in star networks
+and for connection to bus networks.
+
+The PC550 is equipped with two modular RJ11-type jacks for connection
+to twisted pair wiring.
+It can be used in a star or a daisy-chained (BUS) network.
+
+       1 
+       0 9 8 7 6 5 4 3 2 1     6 5 4 3 2 1
+    ____________________________________________________________________
+   < |         SW1         | |     SW2     |                            |
+   > |_____________________| |_____________|                            |
+   <   IRQ    |I/O Addr                                                 |
+   >                                                                 ___|
+   <                                                            CR4 |___|
+   >                                                            CR3 |___|
+   <                                                                 ___|
+   >                                                              N |   | 8
+   <                                                              o |   | 7
+   >                                                              d | S | 6
+   <                                                              e | W | 5
+   >                                                              A | 3 | 4
+   <                                                              d |   | 3
+   >                                                              d |   | 2
+   <                                                              r |___| 1
+   >                                                        |o|    _____|
+   <                                                        |o|   | J1  |
+   >  3 1                                                   JP6   |_____|
+   < |o|o| JP2                                                    | J2  |
+   > |o|o|                                                        |_____|
+   <  4 2__                                               ______________|
+   >    |  |                                             |
+   <____|  |_____________________________________________|
+
+Legend:
+
+SW1     1-6:    I/O Base Address Select
+        7-10:   Interrupt Select
+SW2     1-6:    Reserved for Future Use
+SW3     1-8:    Node ID Select
+JP2     1-4:    Extended Timeout Select
+JP6             Selected - Star Topology        (PC500 only)
+                Deselected - Bus Topology       (PC500 only)
+CR3     Green   Monitors Network Activity
+CR4     Red     Monitors Board Activity
+J1              BNC RG62/U Connector            (PC500 only)
+J1              6-position Telephone Jack       (PC550 only)
+J2              6-position Telephone Jack       (PC550 only)
+
+Setting one of the switches to Off/Open means "1", On/Closed means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group SW3 are used to set the node ID. Each node
+attached to the network must have an unique node ID which must be 
+different from 0.
+Switch 1 serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+    Switch | Value
+    -------|-------
+      1    |   1
+      2    |   2
+      3    |   4
+      4    |   8
+      5    |  16
+      6    |  32
+      7    |  64
+      8    | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   8 7 6 5 4 3 2 1 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255 
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first six switches in switch group SW1 are used to select one
+of 32 possible I/O Base addresses using the following table
+
+   Switch       | Hex I/O
+   6 5  4 3 2 1 | Address
+   -------------|--------
+   0 1  0 0 0 0 |  200
+   0 1  0 0 0 1 |  210
+   0 1  0 0 1 0 |  220
+   0 1  0 0 1 1 |  230
+   0 1  0 1 0 0 |  240
+   0 1  0 1 0 1 |  250
+   0 1  0 1 1 0 |  260
+   0 1  0 1 1 1 |  270
+   0 1  1 0 0 0 |  280
+   0 1  1 0 0 1 |  290
+   0 1  1 0 1 0 |  2A0
+   0 1  1 0 1 1 |  2B0
+   0 1  1 1 0 0 |  2C0
+   0 1  1 1 0 1 |  2D0
+   0 1  1 1 1 0 |  2E0 (Manufacturer's default)
+   0 1  1 1 1 1 |  2F0
+   1 1  0 0 0 0 |  300
+   1 1  0 0 0 1 |  310
+   1 1  0 0 1 0 |  320
+   1 1  0 0 1 1 |  330
+   1 1  0 1 0 0 |  340
+   1 1  0 1 0 1 |  350
+   1 1  0 1 1 0 |  360
+   1 1  0 1 1 1 |  370
+   1 1  1 0 0 0 |  380
+   1 1  1 0 0 1 |  390
+   1 1  1 0 1 0 |  3A0
+   1 1  1 0 1 1 |  3B0
+   1 1  1 1 0 0 |  3C0
+   1 1  1 1 0 1 |  3D0
+   1 1  1 1 1 0 |  3E0
+   1 1  1 1 1 1 |  3F0
+
+
+Setting the Interrupt
+---------------------
+
+Switches seven through ten of switch group SW1 are used to select the 
+interrupt level. The interrupt level is binary coded, so selections 
+from 0 to 15 would be possible, but only the following eight values will
+be supported: 3, 4, 5, 7, 9, 10, 11, 12.
+
+   Switch   | IRQ
+   10 9 8 7 | 
+   ---------|-------- 
+    0 0 1 1 |  3
+    0 1 0 0 |  4
+    0 1 0 1 |  5
+    0 1 1 1 |  7
+    1 0 0 1 |  9 (=2) (default)
+    1 0 1 0 | 10
+    1 0 1 1 | 11
+    1 1 0 0 | 12
+
+
+Setting the Timeouts 
+--------------------
+
+The two jumpers JP2 (1-4) are used to determine the timeout parameters. 
+These two jumpers are normally left open.
+Refer to the COM9026 Data Sheet for alternate configurations.
+
+
+Configuring the PC500 for Star or Bus Topology
+----------------------------------------------
+
+The single jumper labeled JP6 is used to configure the PC500 board for 
+star or bus topology.
+When the jumper is installed, the board may be used in a star network, when 
+it is removed, the board can be used in a bus topology.
+
+
+Diagnostic LEDs
+---------------
+
+Two diagnostic LEDs are visible on the rear bracket of the board.
+The green LED monitors the network activity: the red one shows the
+board activity:
+
+ Green  | Status               Red      | Status
+ -------|-------------------   ---------|-------------------
+  on    | normal activity      flash/on | data transfer
+  blink | reconfiguration      off      | no data transfer;
+  off   | defective board or            | incorrect memory or
+        | node ID is zero               | I/O address
+
+
+*****************************************************************************
+
+** SMC **
+PC710 (8-bit card)
+------------------
+  - from J.S. van Oosten <jvoosten@compiler.tdcnet.nl>
+  
+Note: this data is gathered by experimenting and looking at info of other
+cards. However, I'm sure I got 99% of the settings right.
+
+The SMC710 card resembles the PC270 card, but is much more basic (i.e. no
+LEDs, RJ11 jacks, etc.) and 8 bit. Here's a little drawing:
+
+    _______________________________________   
+   | +---------+  +---------+              |____
+   | |   S2    |  |   S1    |              |
+   | +---------+  +---------+              |
+   |                                       |
+   |  +===+    __                          |
+   |  | R |   |  | X-tal                 ###___
+   |  | O |   |__|                      ####__'|
+   |  | M |    ||                        ###
+   |  +===+                                |
+   |                                       |
+   |   .. JP1   +----------+               |
+   |   ..       | big chip |               |   
+   |   ..       |  90C63   |               |
+   |   ..       |          |               |
+   |   ..       +----------+               |
+    -------                     -----------
+           |||||||||||||||||||||
+
+The row of jumpers at JP1 actually consists of 8 jumpers, (sometimes
+labelled) the same as on the PC270, from top to bottom: EXT2, EXT1, ROM,
+IRQ7, IRQ5, IRQ4, IRQ3, IRQ2 (gee, wonder what they would do? :-) )
+
+S1 and S2 perform the same function as on the PC270, only their numbers
+are swapped (S1 is the nodeaddress, S2 sets IO- and RAM-address).
+
+I know it works when connected to a PC110 type ARCnet board.
+
+        
+*****************************************************************************
+
+** Possibly SMC **
+LCS-8830(-T) (8 and 16-bit cards)
+---------------------------------
+  - from Mathias Katzer <mkatzer@HRZ.Uni-Bielefeld.DE>
+  - Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl> says the
+    LCS-8830 is slightly different from LCS-8830-T.  These are 8 bit, BUS
+    only (the JP0 jumper is hardwired), and BNC only.
+        
+This is a LCS-8830-T made by SMC, I think ('SMC' only appears on one PLCC,
+nowhere else, not even on the few Xeroxed sheets from the manual).
+
+SMC ARCnet Board Type LCS-8830-T
+
+   ------------------------------------
+  |                                    |
+  |              JP3 88  8 JP2         |
+  |       #####      | \               |
+  |       #####    ET1 ET2          ###|
+  |                              8  ###|
+  |  U3   SW 1                  JP0 ###|  Phone Jacks
+  |  --                             ###|
+  | |  |                               |
+  | |  |   SW2                         |
+  | |  |                               |
+  | |  |  #####                        |
+  |  --   #####                       ####  BNC Connector 
+  |                                   ####
+  |   888888 JP1                       |
+  |   234567                           |
+   --                           -------
+     |||||||||||||||||||||||||||
+      --------------------------
+
+
+SW1: DIP-Switches for Station Address
+SW2: DIP-Switches for Memory Base and I/O Base addresses
+
+JP0: If closed, internal termination on (default open)
+JP1: IRQ Jumpers
+JP2: Boot-ROM enabled if closed
+JP3: Jumpers for response timeout
+ 
+U3: Boot-ROM Socket          
+
+
+ET1 ET2     Response Time     Idle Time    Reconfiguration Time
+
+               78                86               840
+ X            285               316              1680
+     X        563               624              1680
+ X   X       1130              1237              1680
+
+(X means closed jumper)
+
+(DIP-Switch downwards means "0")
+
+The station address is binary-coded with SW1.
+
+The I/O base address is coded with DIP-Switches 6,7 and 8 of SW2:
+
+Switches        Base
+678             Address
+000             260-26f
+100             290-29f
+010             2e0-2ef
+110             2f0-2ff
+001             300-30f
+101             350-35f
+011             380-38f
+111             3e0-3ef
+
+
+DIP Switches 1-5 of SW2 encode the RAM and ROM Address Range:
+
+Switches        RAM           ROM
+12345           Address Range  Address Range
+00000           C:0000-C:07ff   C:2000-C:3fff
+10000           C:0800-C:0fff
+01000           C:1000-C:17ff
+11000           C:1800-C:1fff
+00100           C:4000-C:47ff   C:6000-C:7fff
+10100           C:4800-C:4fff
+01100           C:5000-C:57ff 
+11100           C:5800-C:5fff
+00010           C:C000-C:C7ff   C:E000-C:ffff
+10010           C:C800-C:Cfff
+01010           C:D000-C:D7ff
+11010           C:D800-C:Dfff
+00110           D:0000-D:07ff   D:2000-D:3fff
+10110           D:0800-D:0fff
+01110           D:1000-D:17ff
+11110           D:1800-D:1fff
+00001           D:4000-D:47ff   D:6000-D:7fff
+10001           D:4800-D:4fff
+01001           D:5000-D:57ff
+11001           D:5800-D:5fff
+00101           D:8000-D:87ff   D:A000-D:bfff
+10101           D:8800-D:8fff
+01101           D:9000-D:97ff
+11101           D:9800-D:9fff 
+00011           D:C000-D:c7ff   D:E000-D:ffff
+10011           D:C800-D:cfff
+01011           D:D000-D:d7ff
+11011           D:D800-D:dfff
+00111           E:0000-E:07ff   E:2000-E:3fff
+10111           E:0800-E:0fff
+01111           E:1000-E:17ff
+11111           E:1800-E:1fff
+
+
+*****************************************************************************
+
+** PureData Corp **
+PDI507 (8-bit card)
+--------------------
+  - from Mark Rejhon <mdrejhon@magi.com> (slight modifications by Avery)
+  - Avery's note: I think PDI508 cards (but definitely NOT PDI508Plus cards)
+    are mostly the same as this.  PDI508Plus cards appear to be mainly
+    software-configured.
+
+Jumpers:
+        There is a jumper array at the bottom of the card, near the edge
+        connector.  This array is labelled J1.  They control the IRQs and
+        something else.  Put only one jumper on the IRQ pins.
+
+        ETS1, ETS2 are for timing on very long distance networks.  See the
+        more general information near the top of this file.
+
+        There is a J2 jumper on two pins.  A jumper should be put on them,
+        since it was already there when I got the card.  I don't know what
+        this jumper is for though.
+
+        There is a two-jumper array for J3.  I don't know what it is for,
+        but there were already two jumpers on it when I got the card.  It's
+        a six pin grid in a two-by-three fashion.  The jumpers were
+        configured as follows:
+
+           .-------.
+         o | o   o |
+           :-------:    ------> Accessible end of card with connectors
+         o | o   o |             in this direction ------->
+           `-------'
+
+Carl de Billy <CARL@carainfo.com> explains J3 and J4:
+
+        J3 Diagram:
+
+           .-------.
+         o | o   o |
+           :-------:    TWIST Technology
+         o | o   o |
+           `-------'
+           .-------.
+           | o   o | o
+           :-------:    COAX Technology
+           | o   o | o
+           `-------'
+
+  - If using coax cable in a bus topology the J4 jumper must be removed;
+    place it on one pin.
+
+  - If using bus topology with twisted pair wiring move the J3 
+    jumpers so they connect the middle pin and the pins closest to the RJ11
+    Connectors.  Also the J4 jumper must be removed; place it on one pin of
+    J4 jumper for storage.
+
+  - If using  star topology with twisted pair wiring move the J3 
+    jumpers so they connect the middle pin and the pins closest to the RJ11
+    connectors.
+
+
+DIP Switches:
+
+        The DIP switches accessible on the accessible end of the card while
+        it is installed, is used to set the ARCnet address.  There are 8
+        switches.  Use an address from 1 to 254.
+
+        Switch No.
+        12345678        ARCnet address
+        -----------------------------------------
+        00000000        FF      (Don't use this!)
+        00000001        FE
+        00000010        FD
+        ....
+        11111101        2       
+        11111110        1
+        11111111        0       (Don't use this!)
+
+        There is another array of eight DIP switches at the top of the
+        card.  There are five labelled MS0-MS4 which seem to control the
+        memory address, and another three labelled IO0-IO2 which seem to
+        control the base I/O address of the card.
+
+        This was difficult to test by trial and error, and the I/O addresses
+        are in a weird order.  This was tested by setting the DIP switches,
+        rebooting the computer, and attempting to load ARCETHER at various
+        addresses (mostly between 0x200 and 0x400).  The address that caused
+        the red transmit LED to blink, is the one that I thought works.
+
+        Also, the address 0x3D0 seem to have a special meaning, since the
+        ARCETHER packet driver loaded fine, but without the red LED
+        blinking.  I don't know what 0x3D0 is for though.  I recommend using
+        an address of 0x300 since Windows may not like addresses below
+        0x300.
+
+        IO Switch No.
+        210             I/O address
+        -------------------------------
+        111             0x260
+        110             0x290
+        101             0x2E0
+        100             0x2F0
+        011             0x300
+        010             0x350
+        001             0x380
+        000             0x3E0
+
+        The memory switches set a reserved address space of 0x1000 bytes
+        (0x100 segment units, or 4k).  For example if I set an address of
+        0xD000, it will use up addresses 0xD000 to 0xD100.
+
+        The memory switches were tested by booting using QEMM386 stealth,
+        and using LOADHI to see what address automatically became excluded
+        from the upper memory regions, and then attempting to load ARCETHER
+        using these addresses.
+
+        I recommend using an ARCnet memory address of 0xD000, and putting
+        the EMS page frame at 0xC000 while using QEMM stealth mode.  That
+        way, you get contiguous high memory from 0xD100 almost all the way
+        the end of the megabyte.
+
+        Memory Switch 0 (MS0) didn't seem to work properly when set to OFF
+        on my card.  It could be malfunctioning on my card.  Experiment with
+        it ON first, and if it doesn't work, set it to OFF.  (It may be a
+        modifier for the 0x200 bit?)
+
+        MS Switch No.
+        43210           Memory address
+        --------------------------------
+        00001           0xE100  (guessed - was not detected by QEMM)
+        00011           0xE000  (guessed - was not detected by QEMM)
+        00101           0xDD00
+        00111           0xDC00
+        01001           0xD900
+        01011           0xD800
+        01101           0xD500
+        01111           0xD400
+        10001           0xD100
+        10011           0xD000
+        10101           0xCD00
+        10111           0xCC00
+        11001           0xC900 (guessed - crashes tested system)
+        11011           0xC800 (guessed - crashes tested system)
+        11101           0xC500 (guessed - crashes tested system)
+        11111           0xC400 (guessed - crashes tested system)
+        
+        
+*****************************************************************************
+
+** CNet Technology Inc. **
+120 Series (8-bit cards)
+------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+
+
+CNET TECHNOLOGY INC. (CNet) ARCNET 120A SERIES
+==============================================
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the following Original CNet Manual 
+
+              "ARCNET
+            USER'S MANUAL 
+                for
+               CN120A
+               CN120AB
+               CN120TP
+               CN120ST
+               CN120SBT
+             P/N:12-01-0007
+             Revision 3.00"
+
+ARCNET is a registered trademark of the Datapoint Corporation
+
+P/N 120A   ARCNET 8 bit XT/AT Star
+P/N 120AB  ARCNET 8 bit XT/AT Bus
+P/N 120TP  ARCNET 8 bit XT/AT Twisted Pair
+P/N 120ST  ARCNET 8 bit XT/AT Star, Twisted Pair
+P/N 120SBT ARCNET 8 bit XT/AT Star, Bus, Twisted Pair
+
+    __________________________________________________________________
+   |                                                                  |
+   |                                                               ___|
+   |                                                          LED |___|
+   |                                                               ___|
+   |                                                            N |   | ID7
+   |                                                            o |   | ID6
+   |                                                            d | S | ID5
+   |                                                            e | W | ID4
+   |                     ___________________                    A | 2 | ID3
+   |                    |                   |                   d |   | ID2
+   |                    |                   |  1 2 3 4 5 6 7 8  d |   | ID1
+   |                    |                   | _________________ r |___| ID0
+   |                    |      90C65        ||       SW1       |  ____|
+   |  JP 8 7            |                   ||_________________| |    |
+   |    |o|o|  JP1      |                   |                    | J2 |
+   |    |o|o|  |oo|     |                   |         JP 1 1 1   |    |
+   |   ______________   |                   |            0 1 2   |____|
+   |  |  PROM        |  |___________________|           |o|o|o|  _____|
+   |  >  SOCKET      |  JP 6 5 4 3 2                    |o|o|o| | J1  |
+   |  |______________|    |o|o|o|o|o|                   |o|o|o| |_____|
+   |_____                 |o|o|o|o|o|                   ______________|
+         |                                             |
+         |_____________________________________________|
+
+Legend:
+
+90C65       ARCNET Probe
+S1  1-5:    Base Memory Address Select
+    6-8:    Base I/O Address Select
+S2  1-8:    Node ID Select (ID0-ID7)
+JP1     ROM Enable Select
+JP2     IRQ2
+JP3     IRQ3
+JP4     IRQ4
+JP5     IRQ5
+JP6     IRQ7
+JP7/JP8     ET1, ET2 Timeout Parameters
+JP10/JP11   Coax / Twisted Pair Select  (CN120ST/SBT only)
+JP12        Terminator Select       (CN120AB/ST/SBT only)
+J1      BNC RG62/U Connector        (all except CN120TP)
+J2      Two 6-position Telephone Jack   (CN120TP/ST/SBT only)
+
+Setting one of the switches to Off means "1", On means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must be different from 0.
+Switch 1 (ID0) serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+   Switch | Label | Value
+   -------|-------|-------
+     1    | ID0   |   1
+     2    | ID1   |   2
+     3    | ID2   |   4
+     4    | ID3   |   8
+     5    | ID4   |  16
+     6    | ID5   |  32
+     7    | ID6   |  64
+     8    | ID7   | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   8 7 6 5 4 3 2 1 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch block SW1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch      | Hex I/O
+    6   7   8  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   OFF ON  ON  |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   OFF OFF ON  |  2F0
+   ON  ON  OFF |  300
+   OFF ON  OFF |  350
+   ON  OFF OFF |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be 
+located in any of eight positions. The address of the Boot Prom is
+memory base + 8K or memory base + 0x2000.
+Switches 1-5 of switch block SW1 select the Memory Base address.
+
+   Switch              | Hex RAM | Hex ROM
+    1   2   3   4   5  | Address | Address *)
+   --------------------|---------|-----------
+   ON  ON  ON  ON  ON  |  C0000  |  C2000
+   ON  ON  OFF ON  ON  |  C4000  |  C6000
+   ON  ON  ON  OFF ON  |  CC000  |  CE000
+   ON  ON  OFF OFF ON  |  D0000  |  D2000  (Manufacturer's default)
+   ON  ON  ON  ON  OFF |  D4000  |  D6000
+   ON  ON  OFF ON  OFF |  D8000  |  DA000
+   ON  ON  ON  OFF OFF |  DC000  |  DE000
+   ON  ON  OFF OFF OFF |  E0000  |  E2000
+  
+*) To enable the Boot ROM install the jumper JP1
+
+Note: Since the switches 1 and 2 are always set to ON it may be possible
+      that they can be used to add an offset of 2K, 4K or 6K to the base
+      address, but this feature is not documented in the manual and I
+      haven't tested it yet.
+
+
+Setting the Interrupt Line
+--------------------------
+
+To select a hardware interrupt level install one (only one!) of the jumpers
+JP2, JP3, JP4, JP5, JP6. JP2 is the default.
+
+   Jumper | IRQ     
+   -------|-----
+     2    |  2
+     3    |  3
+     4    |  4
+     5    |  5
+     6    |  7
+
+
+Setting the Internal Terminator on CN120AB/TP/SBT
+--------------------------------------------------
+
+The jumper JP12 is used to enable the internal terminator. 
+
+                         -----
+       0                |  0  |     
+     -----   ON         |     |  ON
+    |  0  |             |  0  |
+    |     |  OFF         -----   OFF
+    |  0  |                0
+     -----
+   Terminator          Terminator 
+    disabled            enabled
+  
+
+Selecting the Connector Type on CN120ST/SBT
+-------------------------------------------
+
+     JP10    JP11        JP10    JP11
+                         -----   -----
+       0       0        |  0  | |  0  |       
+     -----   -----      |     | |     |
+    |  0  | |  0  |     |  0  | |  0  |
+    |     | |     |      -----   -----
+    |  0  | |  0  |        0       0 
+     -----   -----
+     Coaxial Cable       Twisted Pair Cable 
+       (Default)
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The jumpers labeled EXT1 and EXT2 are used to determine the timeout 
+parameters. These two jumpers are normally left open.
+
+
+
+*****************************************************************************
+
+** CNet Technology Inc. **
+160 Series (16-bit cards)
+-------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+
+CNET TECHNOLOGY INC. (CNet) ARCNET 160A SERIES
+==============================================
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the following Original CNet Manual 
+
+              "ARCNET
+            USER'S MANUAL 
+                for
+               CN160A
+               CN160AB
+               CN160TP
+             P/N:12-01-0006
+             Revision 3.00"
+
+ARCNET is a registered trademark of the Datapoint Corporation
+
+P/N 160A   ARCNET 16 bit XT/AT Star
+P/N 160AB  ARCNET 16 bit XT/AT Bus
+P/N 160TP  ARCNET 16 bit XT/AT Twisted Pair
+
+   ___________________________________________________________________
+  <                             _________________________          ___|
+  >               |oo| JP2     |                         |    LED |___|
+  <               |oo| JP1     |        9026             |    LED |___|
+  >                            |_________________________|         ___|
+  <                                                             N |   | ID7
+  >                                                      1      o |   | ID6
+  <                                    1 2 3 4 5 6 7 8 9 0      d | S | ID5
+  >         _______________           _____________________     e | W | ID4
+  <        |     PROM      |         |         SW1         |    A | 2 | ID3
+  >        >    SOCKET     |         |_____________________|    d |   | ID2
+  <        |_______________|          | IO-Base   | MEM   |     d |   | ID1
+  >                                                             r |___| ID0
+  <                                                               ____|
+  >                                                              |    |
+  <                                                              | J1 |
+  >                                                              |    |
+  <                                                              |____|
+  >                            1 1 1 1                                |
+  <  3 4 5 6 7      JP     8 9 0 1 2 3                                |
+  > |o|o|o|o|o|           |o|o|o|o|o|o|                               |
+  < |o|o|o|o|o| __        |o|o|o|o|o|o|                    ___________|
+  >            |  |                                       |
+  <____________|  |_______________________________________|
+
+Legend:
+
+9026            ARCNET Probe
+SW1 1-6:    Base I/O Address Select
+    7-10:   Base Memory Address Select
+SW2 1-8:    Node ID Select (ID0-ID7)
+JP1/JP2     ET1, ET2 Timeout Parameters
+JP3-JP13    Interrupt Select
+J1      BNC RG62/U Connector        (CN160A/AB only)
+J1      Two 6-position Telephone Jack   (CN160TP only)
+LED
+
+Setting one of the switches to Off means "1", On means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must be different from 0.
+Switch 1 (ID0) serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+   Switch | Label | Value
+   -------|-------|-------
+     1    | ID0   |   1
+     2    | ID1   |   2
+     3    | ID2   |   4
+     4    | ID3   |   8
+     5    | ID4   |  16
+     6    | ID5   |  32
+     7    | ID6   |  64
+     8    | ID7   | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   8 7 6 5 4 3 2 1 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first six switches in switch block SW1 are used to select the I/O Base
+address using the following table:
+
+             Switch        | Hex I/O
+    1   2   3   4   5   6  | Address
+   ------------------------|--------
+   OFF ON  ON  OFF OFF ON  |  260
+   OFF ON  OFF ON  ON  OFF |  290
+   OFF ON  OFF OFF OFF ON  |  2E0  (Manufacturer's default)
+   OFF ON  OFF OFF OFF OFF |  2F0
+   OFF OFF ON  ON  ON  ON  |  300
+   OFF OFF ON  OFF ON  OFF |  350
+   OFF OFF OFF ON  ON  ON  |  380
+   OFF OFF OFF OFF OFF ON  |  3E0
+
+Note: Other IO-Base addresses seem to be selectable, but only the above
+      combinations are documented.
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The switches 7-10 of switch block SW1 are used to select the Memory
+Base address of the RAM (2K) and the PROM.
+
+   Switch          | Hex RAM | Hex ROM
+    7   8   9  10  | Address | Address
+   ----------------|---------|-----------
+   OFF OFF ON  ON  |  C0000  |  C8000
+   OFF OFF ON  OFF |  D0000  |  D8000 (Default)
+   OFF OFF OFF ON  |  E0000  |  E8000
+
+Note: Other MEM-Base addresses seem to be selectable, but only the above
+      combinations are documented.
+
+
+Setting the Interrupt Line
+--------------------------
+
+To select a hardware interrupt level install one (only one!) of the jumpers
+JP3 through JP13 using the following table:
+
+   Jumper | IRQ     
+   -------|-----------------
+     3    |  14
+     4    |  15
+     5    |  12
+     6    |  11
+     7    |  10
+     8    |   3
+     9    |   4
+    10    |   5
+    11    |   6
+    12    |   7
+    13    |   2 (=9) Default!
+
+Note:  - Do not use JP11=IRQ6, it may conflict with your Floppy Disk
+         Controller
+       - Use JP3=IRQ14 only, if you don't have an IDE-, MFM-, or RLL-
+         Hard Disk, it may conflict with their controllers
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The jumpers labeled JP1 and JP2 are used to determine the timeout
+parameters. These two jumpers are normally left open.
+
+
+*****************************************************************************
+
+** Lantech **
+8-bit card, unknown model
+-------------------------
+  - from Vlad Lungu <vlungu@ugal.ro> - his e-mail address seemed broken at
+    the time I tried to reach him.  Sorry Vlad, if you didn't get my reply.
+
+   ________________________________________________________________
+   |   1         8                                                 |
+   |   ___________                                               __|
+   |   |   SW1    |                                         LED |__|
+   |   |__________|                                                |
+   |                                                            ___|
+   |                _____________________                       |S | 8
+   |                |                   |                       |W |
+   |                |                   |                       |2 |
+   |                |                   |                       |__| 1
+   |                |      UM9065L      |     |o|  JP4         ____|____
+   |                |                   |     |o|              |  CN    |
+   |                |                   |                      |________|
+   |                |                   |                          |
+   |                |___________________|                          |
+   |                                                               |
+   |                                                               |
+   |      _____________                                            |
+   |      |            |                                           |
+   |      |    PROM    |        |ooooo|  JP6                       |
+   |      |____________|        |ooooo|                            |
+   |_____________                                             _   _|
+                |____________________________________________| |__|
+
+
+UM9065L : ARCnet Controller
+
+SW 1    : Shared Memory Address and I/O Base
+
+        ON=0
+
+        12345|Memory Address
+        -----|--------------
+        00001|  D4000
+        00010|  CC000
+        00110|  D0000
+        01110|  D1000
+        01101|  D9000
+        10010|  CC800
+        10011|  DC800
+        11110|  D1800
+
+It seems that the bits are considered in reverse order.  Also, you must
+observe that some of those addresses are unusual and I didn't probe them; I
+used a memory dump in DOS to identify them.  For the 00000 configuration and
+some others that I didn't write here the card seems to conflict with the
+video card (an S3 GENDAC). I leave the full decoding of those addresses to
+you.
+
+        678| I/O Address
+        ---|------------
+        000|    260
+        001|    failed probe
+        010|    2E0
+        011|    380
+        100|    290
+        101|    350
+        110|    failed probe
+        111|    3E0
+
+SW 2  : Node ID (binary coded)
+
+JP 4  : Boot PROM enable   CLOSE - enabled
+                           OPEN  - disabled
+
+JP 6  : IRQ set (ONLY ONE jumper on 1-5 for IRQ 2-6)
+
+
+*****************************************************************************
+
+** Acer **
+8-bit card, Model 5210-003
+--------------------------
+  - from Vojtech Pavlik <vojtech@suse.cz> using portions of the existing
+    arcnet-hardware file.
+
+This is a 90C26 based card.  Its configuration seems similar to the SMC
+PC100, but has some additional jumpers I don't know the meaning of.
+
+               __
+              |  |
+   ___________|__|_________________________
+  |         |      |                       |
+  |         | BNC  |                       |
+  |         |______|                    ___|
+  |  _____________________             |___  
+  | |                     |                |
+  | | Hybrid IC           |                |
+  | |                     |       o|o J1   |
+  | |_____________________|       8|8      |
+  |                               8|8 J5   |
+  |                               o|o      |
+  |                               8|8      |
+  |__                             8|8      |
+ (|__| LED                        o|o      |
+  |                               8|8      |
+  |                               8|8 J15  |
+  |                                        |
+  |                    _____               |
+  |                   |     |   _____      |
+  |                   |     |  |     |  ___|
+  |                   |     |  |     | |    
+  |  _____            | ROM |  | UFS | |    
+  | |     |           |     |  |     | |   
+  | |     |     ___   |     |  |     | |   
+  | |     |    |   |  |__.__|  |__.__| |   
+  | | NCR |    |XTL|   _____    _____  |   
+  | |     |    |___|  |     |  |     | |   
+  | |90C26|           |     |  |     | |   
+  | |     |           | RAM |  | UFS | |   
+  | |     | J17 o|o   |     |  |     | |   
+  | |     | J16 o|o   |     |  |     | |   
+  | |__.__|           |__.__|  |__.__| |   
+  |  ___                               |   
+  | |   |8                             |   
+  | |SW2|                              |   
+  | |   |                              |   
+  | |___|1                             |   
+  |  ___                               |   
+  | |   |10           J18 o|o          |   
+  | |   |                 o|o          |   
+  | |SW1|                 o|o          |   
+  | |   |             J21 o|o          |   
+  | |___|1                             |   
+  |                                    |   
+  |____________________________________|   
+
+
+Legend:
+
+90C26       ARCNET Chip
+XTL         20 MHz Crystal
+SW1 1-6     Base I/O Address Select
+    7-10    Memory Address Select
+SW2 1-8     Node ID Select (ID0-ID7)
+J1-J5       IRQ Select
+J6-J21      Unknown (Probably extra timeouts & ROM enable ...)
+LED1        Activity LED 
+BNC         Coax connector (STAR ARCnet)
+RAM         2k of SRAM
+ROM         Boot ROM socket
+UFS         Unidentified Flying Sockets
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must not be 0.
+Switch 1 (ID0) serves as the least significant bit (LSB).
+
+Setting one of the switches to OFF means "1", ON means "0".
+
+The node ID is the sum of the values of all switches set to "1"
+These values are:
+
+   Switch | Value
+   -------|-------
+     1    |   1
+     2    |   2
+     3    |   4
+     4    |   8
+     5    |  16
+     6    |  32
+     7    |  64
+     8    | 128
+
+Don't set this to 0 or 255; these values are reserved.
+
+
+Setting the I/O Base Address
+----------------------------
+
+The switches 1 to 6 of switch block SW1 are used to select one
+of 32 possible I/O Base addresses using the following tables
+   
+          | Hex
+   Switch | Value
+   -------|-------
+     1    | 200  
+     2    | 100  
+     3    |  80  
+     4    |  40  
+     5    |  20  
+     6    |  10 
+
+The I/O address is sum of all switches set to "1". Remember that
+the I/O address space bellow 0x200 is RESERVED for mainboard, so
+switch 1 should be ALWAYS SET TO OFF. 
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be
+located in any of sixteen positions. However, the addresses below
+A0000 are likely to cause system hang because there's main RAM.
+
+Jumpers 7-10 of switch block SW1 select the Memory Base address.
+
+   Switch          | Hex RAM
+    7   8   9  10  | Address
+   ----------------|---------
+   OFF OFF OFF OFF |  F0000 (conflicts with main BIOS)
+   OFF OFF OFF ON  |  E0000 
+   OFF OFF ON  OFF |  D0000
+   OFF OFF ON  ON  |  C0000 (conflicts with video BIOS)
+   OFF ON  OFF OFF |  B0000 (conflicts with mono video)
+   OFF ON  OFF ON  |  A0000 (conflicts with graphics)
+
+
+Setting the Interrupt Line
+--------------------------
+
+Jumpers 1-5 of the jumper block J1 control the IRQ level. ON means 
+shorted, OFF means open.
+
+    Jumper              |  IRQ
+    1   2   3   4   5   |
+   ----------------------------
+    ON  OFF OFF OFF OFF |  7
+    OFF ON  OFF OFF OFF |  5
+    OFF OFF ON  OFF OFF |  4
+    OFF OFF OFF ON  OFF |  3
+    OFF OFF OFF OFF ON  |  2
+
+
+Unknown jumpers & sockets
+-------------------------
+
+I know nothing about these. I just guess that J16&J17 are timeout
+jumpers and maybe one of J18-J21 selects ROM. Also J6-J10 and
+J11-J15 are connecting IRQ2-7 to some pins on the UFSs. I can't
+guess the purpose.
+
+
+*****************************************************************************
+
+** Datapoint? **
+LAN-ARC-8, an 8-bit card
+------------------------
+  - from Vojtech Pavlik <vojtech@suse.cz>
+
+This is another SMC 90C65-based ARCnet card. I couldn't identify the
+manufacturer, but it might be DataPoint, because the card has the
+original arcNet logo in its upper right corner.
+
+          _______________________________________________________
+         |                         _________                     |
+         |                        |   SW2   | ON      arcNet     |
+         |                        |_________| OFF             ___|
+         |  _____________         1 ______  8                |   | 8  
+         | |             | SW1     | XTAL | ____________     | S |    
+         | > RAM (2k)    |         |______||            |    | W |    
+         | |_____________|                 |      H     |    | 3 |    
+         |                        _________|_____ y     |    |___| 1  
+         |  _________            |         |     |b     |        |    
+         | |_________|           |         |     |r     |        |    
+         |                       |     SMC |     |i     |        |    
+         |                       |    90C65|     |d     |        |      
+         |  _________            |         |     |      |        |
+         | |   SW1   | ON        |         |     |I     |        |
+         | |_________| OFF       |_________|_____/C     |   _____|
+         |  1       8                      |            |  |     |___
+         |  ______________                 |            |  | BNC |___|
+         | |              |                |____________|  |_____|
+         | > EPROM SOCKET |              _____________           |
+         | |______________|             |_____________|          |
+         |                                         ______________|
+         |                                        | 
+         |________________________________________|
+
+Legend:
+
+90C65       ARCNET Chip 
+SW1 1-5:    Base Memory Address Select
+    6-8:    Base I/O Address Select
+SW2 1-8:    Node ID Select
+SW3 1-5:    IRQ Select   
+    6-7:    Extra Timeout
+    8  :    ROM Enable   
+BNC         Coax connector
+XTAL        20 MHz Crystal
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW3 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must not be 0.
+Switch 1 serves as the least significant bit (LSB).
+
+Setting one of the switches to Off means "1", On means "0".
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+   Switch | Value
+   -------|-------
+     1    |   1
+     2    |   2
+     3    |   4
+     4    |   8
+     5    |  16
+     6    |  32
+     7    |  64
+     8    | 128
+
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch block SW1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch      | Hex I/O
+    6   7   8  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   OFF ON  ON  |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   OFF OFF ON  |  2F0
+   ON  ON  OFF |  300
+   OFF ON  OFF |  350
+   ON  OFF OFF |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be 
+located in any of eight positions. The address of the Boot Prom is
+memory base + 0x2000.
+Jumpers 3-5 of switch block SW1 select the Memory Base address.
+
+   Switch              | Hex RAM | Hex ROM
+    1   2   3   4   5  | Address | Address *)
+   --------------------|---------|-----------
+   ON  ON  ON  ON  ON  |  C0000  |  C2000
+   ON  ON  OFF ON  ON  |  C4000  |  C6000
+   ON  ON  ON  OFF ON  |  CC000  |  CE000
+   ON  ON  OFF OFF ON  |  D0000  |  D2000  (Manufacturer's default)
+   ON  ON  ON  ON  OFF |  D4000  |  D6000
+   ON  ON  OFF ON  OFF |  D8000  |  DA000
+   ON  ON  ON  OFF OFF |  DC000  |  DE000
+   ON  ON  OFF OFF OFF |  E0000  |  E2000
+  
+*) To enable the Boot ROM set the switch 8 of switch block SW3 to position ON.
+
+The switches 1 and 2 probably add 0x0800 and 0x1000 to RAM base address.
+
+
+Setting the Interrupt Line
+--------------------------
+
+Switches 1-5 of the switch block SW3 control the IRQ level.
+
+    Jumper              |  IRQ
+    1   2   3   4   5   |
+   ----------------------------
+    ON  OFF OFF OFF OFF |  3
+    OFF ON  OFF OFF OFF |  4
+    OFF OFF ON  OFF OFF |  5
+    OFF OFF OFF ON  OFF |  7
+    OFF OFF OFF OFF ON  |  2
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The switches 6-7 of the switch block SW3 are used to determine the timeout
+parameters.  These two switches are normally left in the OFF position.
+
+
+*****************************************************************************
+
+** Topware **
+8-bit card, TA-ARC/10
+-------------------------
+  - from Vojtech Pavlik <vojtech@suse.cz>
+
+This is another very similar 90C65 card. Most of the switches and jumpers
+are the same as on other clones.
+
+ _____________________________________________________________________
+|  ___________   |                         |            ______        |
+| |SW2 NODE ID|  |                         |           | XTAL |       |
+| |___________|  |  Hybrid IC              |           |______|       |
+|  ___________   |                         |                        __|    
+| |SW1 MEM+I/O|  |_________________________|                   LED1|__|)   
+| |___________|           1 2                                         |     
+|                     J3 |o|o| TIMEOUT                          ______|    
+|     ______________     |o|o|                                 |      |    
+|    |              |  ___________________                     | RJ   |    
+|    > EPROM SOCKET | |                   \                    |------|     
+|J2  |______________| |                    |                   |      |    
+||o|                  |                    |                   |______|
+||o| ROM ENABLE       |        SMC         |    _________             |
+|     _____________   |       90C65        |   |_________|       _____|    
+|    |             |  |                    |                    |     |___ 
+|    > RAM (2k)    |  |                    |                    | BNC |___|
+|    |_____________|  |                    |                    |_____|    
+|                     |____________________|                          |    
+| ________ IRQ 2 3 4 5 7                  ___________                 |
+||________|   |o|o|o|o|o|                |___________|                |
+|________   J1|o|o|o|o|o|                               ______________|
+         |                                             |
+         |_____________________________________________|
+
+Legend:
+
+90C65       ARCNET Chip
+XTAL        20 MHz Crystal
+SW1 1-5     Base Memory Address Select
+    6-8     Base I/O Address Select
+SW2 1-8     Node ID Select (ID0-ID7)
+J1          IRQ Select
+J2          ROM Enable
+J3          Extra Timeout
+LED1        Activity LED 
+BNC         Coax connector (BUS ARCnet)
+RJ          Twisted Pair Connector (daisy chain)
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached to
+the network must have an unique node ID which must not be 0.  Switch 1 (ID0)
+serves as the least significant bit (LSB).
+
+Setting one of the switches to Off means "1", On means "0".
+
+The node ID is the sum of the values of all switches set to "1"
+These values are:
+
+   Switch | Label | Value
+   -------|-------|-------
+     1    | ID0   |   1
+     2    | ID1   |   2
+     3    | ID2   |   4
+     4    | ID3   |   8
+     5    | ID4   |  16
+     6    | ID5   |  32
+     7    | ID6   |  64
+     8    | ID7   | 128
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch block SW1 are used to select one
+of eight possible I/O Base addresses using the following table:
+
+
+   Switch      | Hex I/O
+    6   7   8  | Address
+   ------------|--------
+   ON  ON  ON  |  260  (Manufacturer's default)
+   OFF ON  ON  |  290
+   ON  OFF ON  |  2E0                         
+   OFF OFF ON  |  2F0
+   ON  ON  OFF |  300
+   OFF ON  OFF |  350
+   ON  OFF OFF |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be
+located in any of eight positions. The address of the Boot Prom is
+memory base + 0x2000.
+Jumpers 3-5 of switch block SW1 select the Memory Base address.
+
+   Switch              | Hex RAM | Hex ROM
+    1   2   3   4   5  | Address | Address *)
+   --------------------|---------|-----------
+   ON  ON  ON  ON  ON  |  C0000  |  C2000
+   ON  ON  OFF ON  ON  |  C4000  |  C6000  (Manufacturer's default) 
+   ON  ON  ON  OFF ON  |  CC000  |  CE000
+   ON  ON  OFF OFF ON  |  D0000  |  D2000  
+   ON  ON  ON  ON  OFF |  D4000  |  D6000
+   ON  ON  OFF ON  OFF |  D8000  |  DA000
+   ON  ON  ON  OFF OFF |  DC000  |  DE000
+   ON  ON  OFF OFF OFF |  E0000  |  E2000
+
+*) To enable the Boot ROM short the jumper J2.
+
+The jumpers 1 and 2 probably add 0x0800 and 0x1000 to RAM address.
+
+
+Setting the Interrupt Line
+--------------------------
+
+Jumpers 1-5 of the jumper block J1 control the IRQ level.  ON means
+shorted, OFF means open.
+
+    Jumper              |  IRQ
+    1   2   3   4   5   |
+   ----------------------------
+    ON  OFF OFF OFF OFF |  2
+    OFF ON  OFF OFF OFF |  3
+    OFF OFF ON  OFF OFF |  4
+    OFF OFF OFF ON  OFF |  5
+    OFF OFF OFF OFF ON  |  7
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The jumpers J3 are used to set the timeout parameters. These two 
+jumpers are normally left open.
+
+  
+*****************************************************************************
+
+** Thomas-Conrad **
+Model #500-6242-0097 REV A (8-bit card)
+---------------------------------------
+  - from Lars Karlsson <100617.3473@compuserve.com>
+
+     ________________________________________________________
+   |          ________   ________                           |_____
+   |         |........| |........|                            |
+   |         |________| |________|                         ___|
+   |            SW 3       SW 1                           |   |
+   |         Base I/O   Base Addr.                Station |   |
+   |                                              address |   |
+   |    ______                                    switch  |   |
+   |   |      |                                           |   |
+   |   |      |                                           |___|    
+   |   |      |                                 ______        |___._
+   |   |______|                                |______|         ____| BNC
+   |                                            Jumper-        _____| Connector
+   |   Main chip                                block  _    __|   '  
+   |                                                  | |  |    RJ Connector
+   |                                                  |_|  |    with 110 Ohm
+   |                                                       |__  Terminator
+   |    ___________                                         __|
+   |   |...........|                                       |    RJ-jack
+   |   |...........|    _____                              |    (unused)
+   |   |___________|   |_____|                             |__
+   |  Boot PROM socket IRQ-jumpers                            |_  Diagnostic
+   |________                                       __          _| LED (red)
+            | | | | | | | | | | | | | | | | | | | |  |        |
+            | | | | | | | | | | | | | | | | | | | |  |________|
+                                                              |
+                                                              |
+
+And here are the settings for some of the switches and jumpers on the cards.
+
+
+          I/O
+
+         1 2 3 4 5 6 7 8
+
+2E0----- 0 0 0 1 0 0 0 1
+2F0----- 0 0 0 1 0 0 0 0
+300----- 0 0 0 0 1 1 1 1
+350----- 0 0 0 0 1 1 1 0
+
+"0" in the above example means switch is off "1" means that it is on.
+
+
+    ShMem address.
+
+      1 2 3 4 5 6 7 8
+
+CX00--0 0 1 1 | |   |
+DX00--0 0 1 0       |
+X000--------- 1 1   |
+X400--------- 1 0   |
+X800--------- 0 1   |
+XC00--------- 0 0   
+ENHANCED----------- 1
+COMPATIBLE--------- 0
+
+
+       IRQ
+
+
+   3 4 5 7 2
+   . . . . .
+   . . . . .
+
+
+There is a DIP-switch with 8 switches, used to set the shared memory address
+to be used. The first 6 switches set the address, the 7th doesn't have any
+function, and the 8th switch is used to select "compatible" or "enhanced".
+When I got my two cards, one of them had this switch set to "enhanced". That
+card didn't work at all, it wasn't even recognized by the driver. The other
+card had this switch set to "compatible" and it behaved absolutely normally. I
+guess that the switch on one of the cards, must have been changed accidentally
+when the card was taken out of its former host. The question remains
+unanswered, what is the purpose of the "enhanced" position?
+
+[Avery's note: "enhanced" probably either disables shared memory (use IO
+ports instead) or disables IO ports (use memory addresses instead).  This
+varies by the type of card involved.  I fail to see how either of these
+enhance anything.  Send me more detailed information about this mode, or
+just use "compatible" mode instead.]
+
+
+*****************************************************************************
+
+** Waterloo Microsystems Inc. ?? **
+8-bit card (C) 1985
+-------------------
+  - from Robert Michael Best <rmb117@cs.usask.ca>
+
+[Avery's note: these don't work with my driver for some reason.  These cards
+SEEM to have settings similar to the PDI508Plus, which is
+software-configured and doesn't work with my driver either.  The "Waterloo
+chip" is a boot PROM, probably designed specifically for the University of
+Waterloo.  If you have any further information about this card, please
+e-mail me.]
+
+The probe has not been able to detect the card on any of the J2 settings,
+and I tried them again with the "Waterloo" chip removed.
+ 
+ _____________________________________________________________________
+| \/  \/              ___  __ __                                      |
+| C4  C4     |^|     | M ||  ^  ||^|                                  |
+| --  --     |_|     | 5 ||     || | C3                               |
+| \/  \/      C10    |___||     ||_|                                  | 
+| C4  C4             _  _ |     |                 ??                  | 
+| --  --            | \/ ||     |                                     | 
+|                   |    ||     |                                     | 
+|                   |    ||  C1 |                                     | 
+|                   |    ||     |  \/                            _____|    
+|                   | C6 ||     |  C9                           |     |___ 
+|                   |    ||     |  --                           | BNC |___| 
+|                   |    ||     |          >C7|                 |_____|
+|                   |    ||     |                                     |
+| __ __             |____||_____|       1 2 3     6                   |
+||  ^  |     >C4|                      |o|o|o|o|o|o| J2    >C4|       |
+||     |                               |o|o|o|o|o|o|                  |
+|| C2  |     >C4|                                          >C4|       |
+||     |                                   >C8|                       |
+||     |       2 3 4 5 6 7  IRQ                            >C4|       |
+||_____|      |o|o|o|o|o|o| J3                                        |
+|_______      |o|o|o|o|o|o|                            _______________|
+        |                                             |
+        |_____________________________________________|
+
+C1 -- "COM9026
+       SMC 8638"
+      In a chip socket.
+
+C2 -- "@Copyright
+       Waterloo Microsystems Inc.
+       1985"
+      In a chip Socket with info printed on a label covering a round window
+      showing the circuit inside. (The window indicates it is an EPROM chip.)
+
+C3 -- "COM9032
+       SMC 8643"
+      In a chip socket.
+
+C4 -- "74LS"
+      9 total no sockets.
+
+M5 -- "50006-136
+       20.000000 MHZ
+       MTQ-T1-S3
+       0 M-TRON 86-40"
+      Metallic case with 4 pins, no socket.
+
+C6 -- "MOSTEK@TC8643
+       MK6116N-20
+       MALAYSIA"
+      No socket.
+
+C7 -- No stamp or label but in a 20 pin chip socket.
+
+C8 -- "PAL10L8CN
+       8623"
+      In a 20 pin socket.
+
+C9 -- "PAl16R4A-2CN
+       8641"
+      In a 20 pin socket.
+
+C10 -- "M8640
+          NMC
+        9306N"
+       In an 8 pin socket.
+
+?? -- Some components on a smaller board and attached with 20 pins all 
+      along the side closest to the BNC connector.  The are coated in a dark 
+      resin.
+
+On the board there are two jumper banks labeled J2 and J3. The 
+manufacturer didn't put a J1 on the board. The two boards I have both 
+came with a jumper box for each bank.
+
+J2 -- Numbered 1 2 3 4 5 6. 
+      4 and 5 are not stamped due to solder points.
+       
+J3 -- IRQ 2 3 4 5 6 7
+
+The board itself has a maple leaf stamped just above the irq jumpers 
+and "-2 46-86" beside C2. Between C1 and C6 "ASS 'Y 300163" and "@1986 
+CORMAN CUSTOM ELECTRONICS CORP." stamped just below the BNC connector.
+Below that "MADE IN CANADA"
+
+  
+*****************************************************************************
+
+** No Name **
+8-bit cards, 16-bit cards
+-------------------------
+  - from Juergen Seifert <seifert@htwm.de>
+  
+NONAME 8-BIT ARCNET
+===================
+
+I have named this ARCnet card "NONAME", since there is no name of any
+manufacturer on the Installation manual nor on the shipping box. The only
+hint to the existence of a manufacturer at all is written in copper,
+it is "Made in Taiwan"
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the Original
+                    "ARCnet Installation Manual"
+
+
+    ________________________________________________________________
+   | |STAR| BUS| T/P|                                               |
+   | |____|____|____|                                               |
+   |                            _____________________               |
+   |                           |                     |              |
+   |                           |                     |              |
+   |                           |                     |              |
+   |                           |        SMC          |              |
+   |                           |                     |              |
+   |                           |       COM90C65      |              |
+   |                           |                     |              |
+   |                           |                     |              |
+   |                           |__________-__________|              |
+   |                                                           _____|
+   |      _______________                                     |  CN |
+   |     | PROM          |                                    |_____|
+   |     > SOCKET        |                                          |
+   |     |_______________|         1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8 |
+   |                               _______________  _______________ |
+   |           |o|o|o|o|o|o|o|o|  |      SW1      ||      SW2      ||
+   |           |o|o|o|o|o|o|o|o|  |_______________||_______________||
+   |___         2 3 4 5 7 E E R        Node ID       IOB__|__MEM____|
+       |        \ IRQ   / T T O                      |
+       |__________________1_2_M______________________|
+
+Legend:
+
+COM90C65:       ARCnet Probe
+S1  1-8:    Node ID Select
+S2  1-3:    I/O Base Address Select
+    4-6:    Memory Base Address Select
+    7-8:    RAM Offset Select
+ET1, ET2    Extended Timeout Select
+ROM     ROM Enable Select
+CN              RG62 Coax Connector
+STAR| BUS | T/P Three fields for placing a sign (colored circle)
+                indicating the topology of the card
+
+Setting one of the switches to Off means "1", On means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group SW1 are used to set the node ID.
+Each node attached to the network must have an unique node ID which
+must be different from 0.
+Switch 8 serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+    Switch | Value
+    -------|-------
+      8    |   1
+      7    |   2
+      6    |   4
+      5    |   8
+      4    |  16
+      3    |  32
+      2    |  64
+      1    | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   1 2 3 4 5 6 7 8 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first three switches in switch group SW2 are used to select one
+of eight possible I/O Base addresses using the following table
+
+   Switch      | Hex I/O
+    1   2   3  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   ON  ON  OFF |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   ON  OFF OFF |  2F0
+   OFF ON  ON  |  300
+   OFF ON  OFF |  350
+   OFF OFF ON  |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer requires 2K of a 16K block of RAM. The base of this
+16K block can be located in any of eight positions.
+Switches 4-6 of switch group SW2 select the Base of the 16K block.
+Within that 16K address space, the buffer may be assigned any one of four
+positions, determined by the offset, switches 7 and 8 of group SW2.
+
+   Switch     | Hex RAM | Hex ROM
+   4 5 6  7 8 | Address | Address *)
+   -----------|---------|-----------
+   0 0 0  0 0 |  C0000  |  C2000
+   0 0 0  0 1 |  C0800  |  C2000
+   0 0 0  1 0 |  C1000  |  C2000
+   0 0 0  1 1 |  C1800  |  C2000
+              |         |
+   0 0 1  0 0 |  C4000  |  C6000
+   0 0 1  0 1 |  C4800  |  C6000
+   0 0 1  1 0 |  C5000  |  C6000
+   0 0 1  1 1 |  C5800  |  C6000
+              |         |
+   0 1 0  0 0 |  CC000  |  CE000
+   0 1 0  0 1 |  CC800  |  CE000
+   0 1 0  1 0 |  CD000  |  CE000
+   0 1 0  1 1 |  CD800  |  CE000
+              |         |
+   0 1 1  0 0 |  D0000  |  D2000  (Manufacturer's default)
+   0 1 1  0 1 |  D0800  |  D2000
+   0 1 1  1 0 |  D1000  |  D2000
+   0 1 1  1 1 |  D1800  |  D2000
+              |         |
+   1 0 0  0 0 |  D4000  |  D6000
+   1 0 0  0 1 |  D4800  |  D6000
+   1 0 0  1 0 |  D5000  |  D6000
+   1 0 0  1 1 |  D5800  |  D6000
+              |         |
+   1 0 1  0 0 |  D8000  |  DA000
+   1 0 1  0 1 |  D8800  |  DA000
+   1 0 1  1 0 |  D9000  |  DA000
+   1 0 1  1 1 |  D9800  |  DA000
+              |         |
+   1 1 0  0 0 |  DC000  |  DE000
+   1 1 0  0 1 |  DC800  |  DE000
+   1 1 0  1 0 |  DD000  |  DE000
+   1 1 0  1 1 |  DD800  |  DE000
+              |         |
+   1 1 1  0 0 |  E0000  |  E2000
+   1 1 1  0 1 |  E0800  |  E2000
+   1 1 1  1 0 |  E1000  |  E2000
+   1 1 1  1 1 |  E1800  |  E2000
+  
+*) To enable the 8K Boot PROM install the jumper ROM.
+   The default is jumper ROM not installed.
+
+
+Setting Interrupt Request Lines (IRQ)
+-------------------------------------
+
+To select a hardware interrupt level set one (only one!) of the jumpers
+IRQ2, IRQ3, IRQ4, IRQ5 or IRQ7. The manufacturer's default is IRQ2.
+ 
+
+Setting the Timeouts
+--------------------
+
+The two jumpers labeled ET1 and ET2 are used to determine the timeout
+parameters (response and reconfiguration time). Every node in a network
+must be set to the same timeout values.
+
+   ET1 ET2 | Response Time (us) | Reconfiguration Time (ms)
+   --------|--------------------|--------------------------
+   Off Off |        78          |          840   (Default)
+   Off On  |       285          |         1680
+   On  Off |       563          |         1680
+   On  On  |      1130          |         1680
+
+On means jumper installed, Off means jumper not installed
+
+
+NONAME 16-BIT ARCNET
+====================
+
+The manual of my 8-Bit NONAME ARCnet Card contains another description
+of a 16-Bit Coax / Twisted Pair Card. This description is incomplete,
+because there are missing two pages in the manual booklet. (The table
+of contents reports pages ... 2-9, 2-11, 2-12, 3-1, ... but inside
+the booklet there is a different way of counting ... 2-9, 2-10, A-1,
+(empty page), 3-1, ..., 3-18, A-1 (again), A-2)
+Also the picture of the board layout is not as good as the picture of
+8-Bit card, because there isn't any letter like "SW1" written to the
+picture.
+Should somebody have such a board, please feel free to complete this
+description or to send a mail to me!
+
+This description has been written by Juergen Seifert <seifert@htwm.de>
+using information from the Original
+                    "ARCnet Installation Manual"
+
+
+   ___________________________________________________________________
+  <                    _________________  _________________           |
+  >                   |       SW?       ||      SW?        |          |
+  <                   |_________________||_________________|          |
+  >                       ____________________                        |
+  <                      |                    |                       |
+  >                      |                    |                       |
+  <                      |                    |                       |
+  >                      |                    |                       |
+  <                      |                    |                       |
+  >                      |                    |                       |
+  <                      |                    |                       |
+  >                      |____________________|                       |
+  <                                                               ____|
+  >                       ____________________                   |    |
+  <                      |                    |                  | J1 |
+  >                      |                    <                  |    |
+  <                      |____________________|  ? ? ? ? ? ?     |____|
+  >                                             |o|o|o|o|o|o|         |
+  <                                             |o|o|o|o|o|o|         |
+  >                                                                   |
+  <             __                                         ___________|
+  >            |  |                                       |
+  <____________|  |_______________________________________|
+
+
+Setting one of the switches to Off means "1", On means "0".
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group SW2 are used to set the node ID.
+Each node attached to the network must have an unique node ID which
+must be different from 0.
+Switch 8 serves as the least significant bit (LSB).
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+    Switch | Value
+    -------|-------
+      8    |   1
+      7    |   2
+      6    |   4
+      5    |   8
+      4    |  16
+      3    |  32
+      2    |  64
+      1    | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   1 2 3 4 5 6 7 8 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The first three switches in switch group SW1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+   Switch      | Hex I/O
+    3   2   1  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   ON  ON  OFF |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   ON  OFF OFF |  2F0
+   OFF ON  ON  |  300
+   OFF ON  OFF |  350
+   OFF OFF ON  |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer requires 2K of a 16K block of RAM. The base of this
+16K block can be located in any of eight positions.
+Switches 6-8 of switch group SW1 select the Base of the 16K block.
+Within that 16K address space, the buffer may be assigned any one of four
+positions, determined by the offset, switches 4 and 5 of group SW1.
+
+   Switch     | Hex RAM | Hex ROM
+   8 7 6  5 4 | Address | Address
+   -----------|---------|-----------
+   0 0 0  0 0 |  C0000  |  C2000
+   0 0 0  0 1 |  C0800  |  C2000
+   0 0 0  1 0 |  C1000  |  C2000
+   0 0 0  1 1 |  C1800  |  C2000
+              |         |
+   0 0 1  0 0 |  C4000  |  C6000
+   0 0 1  0 1 |  C4800  |  C6000
+   0 0 1  1 0 |  C5000  |  C6000
+   0 0 1  1 1 |  C5800  |  C6000
+              |         |
+   0 1 0  0 0 |  CC000  |  CE000
+   0 1 0  0 1 |  CC800  |  CE000
+   0 1 0  1 0 |  CD000  |  CE000
+   0 1 0  1 1 |  CD800  |  CE000
+              |         |
+   0 1 1  0 0 |  D0000  |  D2000  (Manufacturer's default)
+   0 1 1  0 1 |  D0800  |  D2000
+   0 1 1  1 0 |  D1000  |  D2000
+   0 1 1  1 1 |  D1800  |  D2000
+              |         |
+   1 0 0  0 0 |  D4000  |  D6000
+   1 0 0  0 1 |  D4800  |  D6000
+   1 0 0  1 0 |  D5000  |  D6000
+   1 0 0  1 1 |  D5800  |  D6000
+              |         |
+   1 0 1  0 0 |  D8000  |  DA000
+   1 0 1  0 1 |  D8800  |  DA000
+   1 0 1  1 0 |  D9000  |  DA000
+   1 0 1  1 1 |  D9800  |  DA000
+              |         |
+   1 1 0  0 0 |  DC000  |  DE000
+   1 1 0  0 1 |  DC800  |  DE000
+   1 1 0  1 0 |  DD000  |  DE000
+   1 1 0  1 1 |  DD800  |  DE000
+              |         |
+   1 1 1  0 0 |  E0000  |  E2000
+   1 1 1  0 1 |  E0800  |  E2000
+   1 1 1  1 0 |  E1000  |  E2000
+   1 1 1  1 1 |  E1800  |  E2000
+  
+
+Setting Interrupt Request Lines (IRQ)
+-------------------------------------
+
+??????????????????????????????????????
+
+
+Setting the Timeouts
+--------------------
+
+??????????????????????????????????????
+
+
+*****************************************************************************
+
+** No Name **
+8-bit cards ("Made in Taiwan R.O.C.")
+-----------
+  - from Vojtech Pavlik <vojtech@suse.cz>
+
+I have named this ARCnet card "NONAME", since I got only the card with
+no manual at all and the only text identifying the manufacturer is 
+"MADE IN TAIWAN R.O.C" printed on the card.
+
+          ____________________________________________________________
+         |                 1 2 3 4 5 6 7 8                            |
+         | |o|o| JP1       o|o|o|o|o|o|o|o| ON                        |
+         |  +              o|o|o|o|o|o|o|o|                        ___|
+         |  _____________  o|o|o|o|o|o|o|o| OFF         _____     |   | ID7
+         | |             | SW1                         |     |    |   | ID6
+         | > RAM (2k)    |        ____________________ |  H  |    | S | ID5
+         | |_____________|       |                    ||  y  |    | W | ID4
+         |                       |                    ||  b  |    | 2 | ID3
+         |                       |                    ||  r  |    |   | ID2
+         |                       |                    ||  i  |    |   | ID1
+         |                       |       90C65        ||  d  |    |___| ID0
+         |      SW3              |                    ||     |        |      
+         | |o|o|o|o|o|o|o|o| ON  |                    ||  I  |        |
+         | |o|o|o|o|o|o|o|o|     |                    ||  C  |        |
+         | |o|o|o|o|o|o|o|o| OFF |____________________||     |   _____|
+         |  1 2 3 4 5 6 7 8                            |     |  |     |___
+         |  ______________                             |     |  | BNC |___|
+         | |              |                            |_____|  |_____|
+         | > EPROM SOCKET |                                           |
+         | |______________|                                           |
+         |                                              ______________|
+         |                                             |
+         |_____________________________________________|
+
+Legend:
+
+90C65       ARCNET Chip 
+SW1 1-5:    Base Memory Address Select
+    6-8:    Base I/O Address Select
+SW2 1-8:    Node ID Select (ID0-ID7)
+SW3 1-5:    IRQ Select   
+    6-7:    Extra Timeout
+    8  :    ROM Enable   
+JP1         Led connector
+BNC         Coax connector
+
+Although the jumpers SW1 and SW3 are marked SW, not JP, they are jumpers, not 
+switches.
+
+Setting the jumpers to ON means connecting the upper two pins, off the bottom 
+two - or - in case of IRQ setting, connecting none of them at all.
+
+Setting the Node ID
+-------------------
+
+The eight switches in SW2 are used to set the node ID. Each node attached
+to the network must have an unique node ID which must not be 0.
+Switch 1 (ID0) serves as the least significant bit (LSB).
+
+Setting one of the switches to Off means "1", On means "0".
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+
+   Switch | Label | Value
+   -------|-------|-------
+     1    | ID0   |   1
+     2    | ID1   |   2
+     3    | ID2   |   4
+     4    | ID3   |   8
+     5    | ID4   |  16
+     6    | ID5   |  32
+     7    | ID6   |  64
+     8    | ID7   | 128
+
+Some Examples:
+
+    Switch         | Hex     | Decimal 
+   8 7 6 5 4 3 2 1 | Node ID | Node ID
+   ----------------|---------|---------
+   0 0 0 0 0 0 0 0 |    not allowed
+   0 0 0 0 0 0 0 1 |    1    |    1 
+   0 0 0 0 0 0 1 0 |    2    |    2
+   0 0 0 0 0 0 1 1 |    3    |    3
+       . . .       |         |
+   0 1 0 1 0 1 0 1 |   55    |   85
+       . . .       |         |
+   1 0 1 0 1 0 1 0 |   AA    |  170
+       . . .       |         |  
+   1 1 1 1 1 1 0 1 |   FD    |  253
+   1 1 1 1 1 1 1 0 |   FE    |  254
+   1 1 1 1 1 1 1 1 |   FF    |  255
+
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch block SW1 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch      | Hex I/O
+    6   7   8  | Address
+   ------------|--------
+   ON  ON  ON  |  260
+   OFF ON  ON  |  290
+   ON  OFF ON  |  2E0  (Manufacturer's default)
+   OFF OFF ON  |  2F0
+   ON  ON  OFF |  300
+   OFF ON  OFF |  350
+   ON  OFF OFF |  380
+   OFF OFF OFF |  3E0
+
+
+Setting the Base Memory (RAM) buffer Address
+--------------------------------------------
+
+The memory buffer (RAM) requires 2K. The base of this buffer can be 
+located in any of eight positions. The address of the Boot Prom is
+memory base + 0x2000.
+Jumpers 3-5 of jumper block SW1 select the Memory Base address.
+
+   Switch              | Hex RAM | Hex ROM
+    1   2   3   4   5  | Address | Address *)
+   --------------------|---------|-----------
+   ON  ON  ON  ON  ON  |  C0000  |  C2000
+   ON  ON  OFF ON  ON  |  C4000  |  C6000
+   ON  ON  ON  OFF ON  |  CC000  |  CE000
+   ON  ON  OFF OFF ON  |  D0000  |  D2000  (Manufacturer's default)
+   ON  ON  ON  ON  OFF |  D4000  |  D6000
+   ON  ON  OFF ON  OFF |  D8000  |  DA000
+   ON  ON  ON  OFF OFF |  DC000  |  DE000
+   ON  ON  OFF OFF OFF |  E0000  |  E2000
+  
+*) To enable the Boot ROM set the jumper 8 of jumper block SW3 to position ON.
+
+The jumpers 1 and 2 probably add 0x0800, 0x1000 and 0x1800 to RAM adders.
+
+Setting the Interrupt Line
+--------------------------
+
+Jumpers 1-5 of the jumper block SW3 control the IRQ level.
+
+    Jumper              |  IRQ
+    1   2   3   4   5   |
+   ----------------------------
+    ON  OFF OFF OFF OFF |  2
+    OFF ON  OFF OFF OFF |  3
+    OFF OFF ON  OFF OFF |  4
+    OFF OFF OFF ON  OFF |  5
+    OFF OFF OFF OFF ON  |  7
+
+
+Setting the Timeout Parameters
+------------------------------
+
+The jumpers 6-7 of the jumper block SW3 are used to determine the timeout 
+parameters. These two jumpers are normally left in the OFF position.
+
+
+*****************************************************************************
+
+** No Name **
+(Generic Model 9058)
+--------------------
+  - from Andrew J. Kroll <ag784@freenet.buffalo.edu>
+  - Sorry this sat in my to-do box for so long, Andrew! (yikes - over a
+    year!)
+                                                                      _____
+                                                                     |    <
+                                                                     | .---'
+    ________________________________________________________________ | |
+   |                           |     SW2     |                      |  |
+   |   ___________             |_____________|                      |  |
+   |  |           |              1 2 3 4 5 6                     ___|  |
+   |  >  6116 RAM |         _________                         8 |   |  |
+   |  |___________|        |20MHzXtal|                        7 |   |  |
+   |                       |_________|       __________       6 | S |  |
+   |    74LS373                             |          |-     5 | W |  |
+   |   _________                            |      E   |-     4 |   |  |
+   |   >_______|              ______________|..... P   |-     3 | 3 |  |
+   |                         |              |    : O   |-     2 |   |  |
+   |                         |              |    : X   |-     1 |___|  |
+   |   ________________      |              |    : Y   |-           |  |
+   |  |      SW1       |     |      SL90C65 |    :     |-           |  |
+   |  |________________|     |              |    : B   |-           |  |
+   |    1 2 3 4 5 6 7 8      |              |    : O   |-           |  |
+   |                         |_________o____|..../ A   |-    _______|  |
+   |    ____________________                |      R   |-   |       |------,   
+   |   |                    |               |      D   |-   |  BNC  |   #  |
+   |   > 2764 PROM SOCKET   |               |__________|-   |_______|------'
+   |   |____________________|              _________                |  |
+   |                                       >________| <- 74LS245    |  |
+   |                                                                |  |
+   |___                                               ______________|  |
+       |H H H H H H H H H H H H H H H H H H H H H H H|               | |
+       |U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U|               | |
+                                                                      \|
+Legend:
+
+SL90C65         ARCNET Controller / Transceiver /Logic
+SW1     1-5:    IRQ Select
+          6:    ET1
+          7:    ET2
+          8:    ROM ENABLE 
+SW2     1-3:    Memory Buffer/PROM Address
+        3-6:    I/O Address Map
+SW3     1-8:    Node ID Select
+BNC             BNC RG62/U Connection 
+                *I* have had success using RG59B/U with *NO* terminators!
+                What gives?!
+
+SW1: Timeouts, Interrupt and ROM
+---------------------------------
+
+To select a hardware interrupt level set one (only one!) of the dip switches
+up (on) SW1...(switches 1-5)
+IRQ3, IRQ4, IRQ5, IRQ7, IRQ2. The Manufacturer's default is IRQ2.
+
+The switches on SW1 labeled EXT1 (switch 6) and EXT2 (switch 7)
+are used to determine the timeout parameters. These two dip switches
+are normally left off (down).
+
+   To enable the 8K Boot PROM position SW1 switch 8 on (UP) labeled ROM.
+   The default is jumper ROM not installed.
+
+
+Setting the I/O Base Address
+----------------------------
+
+The last three switches in switch group SW2 are used to select one
+of eight possible I/O Base addresses using the following table
+
+
+   Switch | Hex I/O
+   4 5 6  | Address
+   -------|--------
+   0 0 0  |  260
+   0 0 1  |  290
+   0 1 0  |  2E0  (Manufacturer's default)
+   0 1 1  |  2F0
+   1 0 0  |  300
+   1 0 1  |  350
+   1 1 0  |  380
+   1 1 1  |  3E0
+
+
+Setting the Base Memory Address (RAM & ROM)
+-------------------------------------------
+
+The memory buffer requires 2K of a 16K block of RAM. The base of this
+16K block can be located in any of eight positions.
+Switches 1-3 of switch group SW2 select the Base of the 16K block.
+(0 = DOWN, 1 = UP)
+I could, however, only verify two settings...
+
+   Switch| Hex RAM | Hex ROM
+   1 2 3 | Address | Address
+   ------|---------|-----------
+   0 0 0 |  E0000  |  E2000
+   0 0 1 |  D0000  |  D2000  (Manufacturer's default)
+   0 1 0 |  ?????  |  ?????
+   0 1 1 |  ?????  |  ?????  
+   1 0 0 |  ?????  |  ?????
+   1 0 1 |  ?????  |  ?????
+   1 1 0 |  ?????  |  ?????
+   1 1 1 |  ?????  |  ?????
+
+
+Setting the Node ID
+-------------------
+
+The eight switches in group SW3 are used to set the node ID.
+Each node attached to the network must have an unique node ID which
+must be different from 0.
+Switch 1 serves as the least significant bit (LSB).
+switches in the DOWN position are OFF (0) and in the UP position are ON (1)
+
+The node ID is the sum of the values of all switches set to "1"  
+These values are:
+    Switch | Value
+    -------|-------
+      1    |   1
+      2    |   2
+      3    |   4
+      4    |   8
+      5    |  16
+      6    |  32
+      7    |  64
+      8    | 128
+
+Some Examples:
+
+    Switch#     |   Hex   | Decimal 
+8 7 6 5 4 3 2 1 | Node ID | Node ID
+----------------|---------|---------
+0 0 0 0 0 0 0 0 |    not allowed  <-.
+0 0 0 0 0 0 0 1 |    1    |    1    | 
+0 0 0 0 0 0 1 0 |    2    |    2    |
+0 0 0 0 0 0 1 1 |    3    |    3    |
+    . . .       |         |         |
+0 1 0 1 0 1 0 1 |   55    |   85    |
+    . . .       |         |         + Don't use 0 or 255!
+1 0 1 0 1 0 1 0 |   AA    |  170    |
+    . . .       |         |         |
+1 1 1 1 1 1 0 1 |   FD    |  253    |
+1 1 1 1 1 1 1 0 |   FE    |  254    |
+1 1 1 1 1 1 1 1 |   FF    |  255  <-'
+  
+
+*****************************************************************************
+
+** Tiara **
+(model unknown)
+-------------------------
+  - from Christoph Lameter <christoph@lameter.com>
+  
+
+Here is information about my card as far as I could figure it out:
+----------------------------------------------- tiara
+Tiara LanCard of Tiara Computer Systems.
+
++----------------------------------------------+
+!           ! Transmitter Unit !               !
+!           +------------------+             -------
+!          MEM                              Coax Connector
+!  ROM    7654321 <- I/O                     -------
+!  :  :   +--------+                           !
+!  :  :   ! 90C66LJ!                         +++
+!  :  :   !        !                         !D  Switch to set
+!  :  :   !        !                         !I  the Nodenumber
+!  :  :   +--------+                         !P
+!                                            !++
+!         234567 <- IRQ                      !
++------------!!!!!!!!!!!!!!!!!!!!!!!!--------+
+             !!!!!!!!!!!!!!!!!!!!!!!!
+
+0 = Jumper Installed
+1 = Open
+
+Top Jumper line Bit 7 = ROM Enable 654=Memory location 321=I/O
+
+Settings for Memory Location (Top Jumper Line)
+456     Address selected
+000     C0000
+001     C4000
+010     CC000
+011     D0000
+100     D4000
+101     D8000
+110     DC000     
+111     E0000
+
+Settings for I/O Address (Top Jumper Line)
+123     Port
+000     260
+001     290
+010     2E0
+011     2F0
+100     300
+101     350
+110     380
+111     3E0
+
+Settings for IRQ Selection (Lower Jumper Line)
+234567
+011111 IRQ 2
+101111 IRQ 3
+110111 IRQ 4
+111011 IRQ 5
+111110 IRQ 7
+
+*****************************************************************************
+
+
+Other Cards
+-----------
+
+I have no information on other models of ARCnet cards at the moment.  Please
+send any and all info to:
+        apenwarr@worldvisions.ca
+
+Thanks.
diff --git a/Documentation/networking/arcnet.txt b/Documentation/networking/arcnet.txt
new file mode 100644
index 00000000000..770fc41a78e
--- /dev/null
+++ b/Documentation/networking/arcnet.txt
@@ -0,0 +1,555 @@
+----------------------------------------------------------------------------
+NOTE:  See also arcnet-hardware.txt in this directory for jumper-setting
+and cabling information if you're like many of us and didn't happen to get a
+manual with your ARCnet card.
+----------------------------------------------------------------------------
+
+Since no one seems to listen to me otherwise, perhaps a poem will get your
+attention:
+                This driver's getting fat and beefy,
+                But my cat is still named Fifi.
+
+Hmm, I think I'm allowed to call that a poem, even though it's only two
+lines.  Hey, I'm in Computer Science, not English.  Give me a break.
+
+The point is:  I REALLY REALLY REALLY REALLY REALLY want to hear from you if
+you test this and get it working.  Or if you don't.  Or anything.
+
+ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this was
+nice, but after that even FEWER people started writing to me because they
+didn't even have to install the patch.  <sigh>
+
+Come on, be a sport!  Send me a success report!
+
+(hey, that was even better than my original poem... this is getting bad!)
+
+
+--------
+WARNING:
+--------
+
+If you don't e-mail me about your success/failure soon, I may be forced to
+start SINGING.  And we don't want that, do we?
+
+(You know, it might be argued that I'm pushing this point a little too much. 
+If you think so, why not flame me in a quick little e-mail?  Please also
+include the type of card(s) you're using, software, size of network, and
+whether it's working or not.)
+
+My e-mail address is: apenwarr@worldvisions.ca
+
+
+---------------------------------------------------------------------------
+
+                        
+These are the ARCnet drivers for Linux.
+
+
+This new release (2.91) has been put together by David Woodhouse 
+<dwmw2@cam.ac.uk>, in an attempt to tidy up the driver after adding support 
+for yet another chipset. Now the generic support has been separated from the
+individual chipset drivers, and the source files aren't quite so packed with
+#ifdefs! I've changed this file a bit, but kept it in the first person from
+Avery, because I didn't want to completely rewrite it.
+
+The previous release resulted from many months of on-and-off effort from me
+(Avery Pennarun), many bug reports/fixes and suggestions from others, and in
+particular a lot of input and coding from Tomasz Motylewski.  Starting with
+ARCnet 2.10 ALPHA, Tomasz's all-new-and-improved RFC1051 support has been
+included and seems to be working fine!
+
+
+Where do I discuss these drivers?
+---------------------------------
+
+Tomasz has been so kind as to set up a new and improved mailing list. 
+Subscribe by sending a message with the BODY "subscribe linux-arcnet YOUR
+REAL NAME" to listserv@tichy.ch.uj.edu.pl.  Then, to submit messages to the
+list, mail to linux-arcnet@tichy.ch.uj.edu.pl.
+
+There are archives of the mailing list at:
+        http://tichy.ch.uj.edu.pl/lists/linux-arcnet
+
+The people on linux-net@vger.kernel.org have also been known to be very
+helpful, especially when we're talking about ALPHA Linux kernels that may or
+may not work right in the first place.
+
+
+Other Drivers and Info
+----------------------
+
+You can try my ARCNET page on the World Wide Web at:
+        http://www.worldvisions.ca/~apenwarr/arcnet/
+
+Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you
+might be interested in, which includes several drivers for various cards
+including ARCnet.  Try:
+        http://www.smc.com/
+        
+Performance Technologies makes various network software that supports
+ARCnet:
+        http://www.perftech.com/ or ftp to ftp.perftech.com.
+        
+Novell makes a networking stack for DOS which includes ARCnet drivers.  Try
+FTPing to ftp.novell.com.
+
+You can get the Crynwr packet driver collection (including arcether.com, the
+one you'll want to use with ARCnet cards) from
+oak.oakland.edu:/simtel/msdos/pktdrvr. It won't work perfectly on a 386+
+without patches, though, and also doesn't like several cards.  Fixed
+versions are available on my WWW page, or via e-mail if you don't have WWW
+access. 
+
+
+Installing the Driver
+---------------------
+
+All you will need to do in order to install the driver is:
+        make config
+                (be sure to choose ARCnet in the network devices 
+                and at least one chipset driver.)
+        make clean
+        make zImage
+        
+If you obtained this ARCnet package as an upgrade to the ARCnet driver in
+your current kernel, you will need to first copy arcnet.c over the one in
+the linux/drivers/net directory.
+
+You will know the driver is installed properly if you get some ARCnet
+messages when you reboot into the new Linux kernel.
+
+There are four chipset options:
+
+ 1. Standard ARCnet COM90xx chipset.
+
+This is the normal ARCnet card, which you've probably got. This is the only
+chipset driver which will autoprobe if not told where the card is.
+It following options on the command line:
+ com90xx=[<io>[,<irq>[,<shmem>]]][,<name>] | <name>
+
+If you load the chipset support as a module, the options are:
+ io=<io> irq=<irq> shmem=<shmem> device=<name>
+
+To disable the autoprobe, just specify "com90xx=" on the kernel command line.
+To specify the name alone, but allow autoprobe, just put "com90xx=<name>"
+
+ 2. ARCnet COM20020 chipset.
+
+This is the new chipset from SMC with support for promiscuous mode (packet 
+sniffing), extra diagnostic information, etc. Unfortunately, there is no
+sensible method of autoprobing for these cards. You must specify the I/O
+address on the kernel command line.
+The command line options are:
+ com20020=<io>[,<irq>[,<node_ID>[,backplane[,CKP[,timeout]]]]][,name]
+
+If you load the chipset support as a module, the options are:
+ io=<io> irq=<irq> node=<node_ID> backplane=<backplane> clock=<CKP>
+ timeout=<timeout> device=<name>
+
+The COM20020 chipset allows you to set the node ID in software, overriding the
+default which is still set in DIP switches on the card. If you don't have the
+COM20020 data sheets, and you don't know what the other three options refer
+to, then they won't interest you - forget them.
+
+ 3. ARCnet COM90xx chipset in IO-mapped mode.
+
+This will also work with the normal ARCnet cards, but doesn't use the shared
+memory. It performs less well than the above driver, but is provided in case
+you have a card which doesn't support shared memory, or (strangely) in case
+you have so many ARCnet cards in your machine that you run out of shmem slots.
+If you don't give the IO address on the kernel command line, then the driver
+will not find the card.
+The command line options are:
+ com90io=<io>[,<irq>][,<name>] 
+
+If you load the chipset support as a module, the options are:
+ io=<io> irq=<irq> device=<name>
+
+ 4. ARCnet RIM I cards.
+
+These are COM90xx chips which are _completely_ memory mapped. The support for
+these is not tested. If you have one, please mail the author with a success 
+report. All options must be specified, except the device name.
+Command line options:
+ arcrimi=<shmem>,<irq>,<node_ID>[,<name>]
+
+If you load the chipset support as a module, the options are:
+ shmem=<shmem> irq=<irq> node=<node_ID> device=<name>
+
+
+Loadable Module Support
+-----------------------
+
+Configure and rebuild Linux.  When asked, answer 'm' to "Generic ARCnet 
+support" and to support for your ARCnet chipset if you want to use the
+loadable module. You can also say 'y' to "Generic ARCnet support" and 'm' 
+to the chipset support if you wish.
+
+        make config
+        make clean      
+        make zImage
+        make modules
+        
+If you're using a loadable module, you need to use insmod to load it, and
+you can specify various characteristics of your card on the command
+line.  (In recent versions of the driver, autoprobing is much more reliable
+and works as a module, so most of this is now unnecessary.)
+
+For example:
+        cd /usr/src/linux/modules
+        insmod arcnet.o
+        insmod com90xx.o
+        insmod com20020.o io=0x2e0 device=eth1
+        
+
+Using the Driver
+----------------
+
+If you build your kernel with ARCnet COM90xx support included, it should 
+probe for your card automatically when you boot. If you use a different
+chipset driver complied into the kernel, you must give the necessary options
+on the kernel command line, as detailed above.
+
+Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should be
+available where you picked up this driver.  Think of your ARCnet as a
+souped-up (or down, as the case may be) Ethernet card.
+
+By the way, be sure to change all references from "eth0" to "arc0" in the
+HOWTOs.  Remember that ARCnet isn't a "true" Ethernet, and the device name
+is DIFFERENT.
+
+
+Multiple Cards in One Computer
+------------------------------
+
+Linux has pretty good support for this now, but since I've been busy, the
+ARCnet driver has somewhat suffered in this respect. COM90xx support, if 
+compiled into the kernel, will (try to) autodetect all the installed cards. 
+
+If you have other cards, with support compiled into the kernel, then you can 
+just repeat the options on the kernel command line, e.g.:
+LILO: linux com20020=0x2e0 com20020=0x380 com90io=0x260
+
+If you have the chipset support built as a loadable module, then you need to 
+do something like this:
+        insmod -o arc0 com90xx
+        insmod -o arc1 com20020 io=0x2e0
+        insmod -o arc2 com90xx
+The ARCnet drivers will now sort out their names automatically.
+
+
+How do I get it to work with...?
+--------------------------------
+
+NFS: Should be fine linux->linux, just pretend you're using Ethernet cards. 
+        oak.oakland.edu:/simtel/msdos/nfs has some nice DOS clients.  There
+        is also a DOS-based NFS server called SOSS.  It doesn't multitask
+        quite the way Linux does (actually, it doesn't multitask AT ALL) but
+        you never know what you might need.
+        
+        With AmiTCP (and possibly others), you may need to set the following
+        options in your Amiga nfstab:  MD 1024 MR 1024 MW 1024
+        (Thanks to Christian Gottschling <ferksy@indigo.tng.oche.de>
+        for this.)
+        
+        Probably these refer to maximum NFS data/read/write block sizes.  I
+        don't know why the defaults on the Amiga didn't work; write to me if
+        you know more.
+
+DOS: If you're using the freeware arcether.com, you might want to install
+        the driver patch from my web page.  It helps with PC/TCP, and also
+        can get arcether to load if it timed out too quickly during
+        initialization.  In fact, if you use it on a 386+ you REALLY need
+        the patch, really.
+        
+Windows:  See DOS :)  Trumpet Winsock works fine with either the Novell or
+        Arcether client, assuming you remember to load winpkt of course.
+
+LAN Manager and Windows for Workgroups: These programs use protocols that
+        are incompatible with the Internet standard.  They try to pretend
+        the cards are Ethernet, and confuse everyone else on the network. 
+        
+        However, v2.00 and higher of the Linux ARCnet driver supports this
+        protocol via the 'arc0e' device.  See the section on "Multiprotocol
+        Support" for more information.
+
+        Using the freeware Samba server and clients for Linux, you can now
+        interface quite nicely with TCP/IP-based WfWg or Lan Manager
+        networks.
+        
+Windows 95: Tools are included with Win95 that let you use either the LANMAN
+        style network drivers (NDIS) or Novell drivers (ODI) to handle your
+        ARCnet packets.  If you use ODI, you'll need to use the 'arc0'
+        device with Linux.  If you use NDIS, then try the 'arc0e' device. 
+        See the "Multiprotocol Support" section below if you need arc0e,
+        you're completely insane, and/or you need to build some kind of
+        hybrid network that uses both encapsulation types.
+
+OS/2: I've been told it works under Warp Connect with an ARCnet driver from
+        SMC.  You need to use the 'arc0e' interface for this.  If you get
+        the SMC driver to work with the TCP/IP stuff included in the
+        "normal" Warp Bonus Pack, let me know.
+
+        ftp.microsoft.com also has a freeware "Lan Manager for OS/2" client
+        which should use the same protocol as WfWg does.  I had no luck
+        installing it under Warp, however.  Please mail me with any results.
+
+NetBSD/AmiTCP: These use an old version of the Internet standard ARCnet
+        protocol (RFC1051) which is compatible with the Linux driver v2.10
+        ALPHA and above using the arc0s device. (See "Multiprotocol ARCnet"
+        below.)  ** Newer versions of NetBSD apparently support RFC1201.
+
+
+Using Multiprotocol ARCnet
+--------------------------
+
+The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
+"virtual network device":
+
+        arc0  - RFC1201 protocol, the official Internet standard which just
+                happens to be 100% compatible with Novell's TRXNET driver. 
+                Version 1.00 of the ARCnet driver supported _only_ this
+                protocol.  arc0 is the fastest of the three protocols (for
+                whatever reason), and allows larger packets to be used
+                because it supports RFC1201 "packet splitting" operations. 
+                Unless you have a specific need to use a different protocol,
+                I strongly suggest that you stick with this one.
+                
+        arc0e - "Ethernet-Encapsulation" which sends packets over ARCnet
+                that are actually a lot like Ethernet packets, including the
+                6-byte hardware addresses.  This protocol is compatible with
+                Microsoft's NDIS ARCnet driver, like the one in WfWg and
+                LANMAN.  Because the MTU of 493 is actually smaller than the
+                one "required" by TCP/IP (576), there is a chance that some
+                network operations will not function properly.  The Linux
+                TCP/IP layer can compensate in most cases, however, by
+                automatically fragmenting the TCP/IP packets to make them
+                fit.  arc0e also works slightly more slowly than arc0, for
+                reasons yet to be determined.  (Probably it's the smaller
+                MTU that does it.)
+                
+        arc0s - The "[s]imple" RFC1051 protocol is the "previous" Internet
+                standard that is completely incompatible with the new
+                standard.  Some software today, however, continues to
+                support the old standard (and only the old standard)
+                including NetBSD and AmiTCP.  RFC1051 also does not support
+                RFC1201's packet splitting, and the MTU of 507 is still
+                smaller than the Internet "requirement," so it's quite
+                possible that you may run into problems.  It's also slower
+                than RFC1201 by about 25%, for the same reason as arc0e.
+                
+                The arc0s support was contributed by Tomasz Motylewski
+                and modified somewhat by me.  Bugs are probably my fault.
+
+You can choose not to compile arc0e and arc0s into the driver if you want -
+this will save you a bit of memory and avoid confusion when eg. trying to
+use the "NFS-root" stuff in recent Linux kernels.
+
+The arc0e and arc0s devices are created automatically when you first
+ifconfig the arc0 device.  To actually use them, though, you need to also
+ifconfig the other virtual devices you need.  There are a number of ways you
+can set up your network then:
+
+
+1. Single Protocol.
+
+   This is the simplest way to configure your network: use just one of the
+   two available protocols.  As mentioned above, it's a good idea to use
+   only arc0 unless you have a good reason (like some other software, ie.
+   WfWg, that only works with arc0e).
+   
+   If you need only arc0, then the following commands should get you going:
+        ifconfig arc0 MY.IP.ADD.RESS
+        route add MY.IP.ADD.RESS arc0
+        route add -net SUB.NET.ADD.RESS arc0
+        [add other local routes here]
+        
+   If you need arc0e (and only arc0e), it's a little different:
+        ifconfig arc0 MY.IP.ADD.RESS
+        ifconfig arc0e MY.IP.ADD.RESS
+        route add MY.IP.ADD.RESS arc0e
+        route add -net SUB.NET.ADD.RESS arc0e
+   
+   arc0s works much the same way as arc0e.
+
+
+2. More than one protocol on the same wire.
+
+   Now things start getting confusing.  To even try it, you may need to be
+   partly crazy.  Here's what *I* did. :) Note that I don't include arc0s in
+   my home network; I don't have any NetBSD or AmiTCP computers, so I only
+   use arc0s during limited testing.
+
+   I have three computers on my home network; two Linux boxes (which prefer
+   RFC1201 protocol, for reasons listed above), and one XT that can't run
+   Linux but runs the free Microsoft LANMAN Client instead.
+
+   Worse, one of the Linux computers (freedom) also has a modem and acts as
+   a router to my Internet provider.  The other Linux box (insight) also has
+   its own IP address and needs to use freedom as its default gateway.  The
+   XT (patience), however, does not have its own Internet IP address and so
+   I assigned it one on a "private subnet" (as defined by RFC1597).
+
+   To start with, take a simple network with just insight and freedom. 
+   Insight needs to:
+        - talk to freedom via RFC1201 (arc0) protocol, because I like it
+          more and it's faster.
+        - use freedom as its Internet gateway.
+        
+   That's pretty easy to do.  Set up insight like this:
+        ifconfig arc0 insight
+        route add insight arc0
+        route add freedom arc0  /* I would use the subnet here (like I said
+                                        to to in "single protocol" above),
+                                        but the rest of the subnet
+                                        unfortunately lies across the PPP
+                                        link on freedom, which confuses
+                                        things. */
+        route add default gw freedom
+        
+   And freedom gets configured like so:
+        ifconfig arc0 freedom
+        route add freedom arc0
+        route add insight arc0
+        /* and default gateway is configured by pppd */
+        
+   Great, now insight talks to freedom directly on arc0, and sends packets
+   to the Internet through freedom.  If you didn't know how to do the above,
+   you should probably stop reading this section now because it only gets
+   worse.
+
+   Now, how do I add patience into the network?  It will be using LANMAN
+   Client, which means I need the arc0e device.  It needs to be able to talk
+   to both insight and freedom, and also use freedom as a gateway to the
+   Internet.  (Recall that patience has a "private IP address" which won't
+   work on the Internet; that's okay, I configured Linux IP masquerading on
+   freedom for this subnet).
+   
+   So patience (necessarily; I don't have another IP number from my
+   provider) has an IP address on a different subnet than freedom and
+   insight, but needs to use freedom as an Internet gateway.  Worse, most
+   DOS networking programs, including LANMAN, have braindead networking
+   schemes that rely completely on the netmask and a 'default gateway' to
+   determine how to route packets.  This means that to get to freedom or
+   insight, patience WILL send through its default gateway, regardless of
+   the fact that both freedom and insight (courtesy of the arc0e device)
+   could understand a direct transmission.
+   
+   I compensate by giving freedom an extra IP address - aliased 'gatekeeper'
+   - that is on my private subnet, the same subnet that patience is on.  I
+   then define gatekeeper to be the default gateway for patience.
+   
+   To configure freedom (in addition to the commands above):
+        ifconfig arc0e gatekeeper
+        route add gatekeeper arc0e
+        route add patience arc0e
+   
+   This way, freedom will send all packets for patience through arc0e,
+   giving its IP address as gatekeeper (on the private subnet).  When it
+   talks to insight or the Internet, it will use its "freedom" Internet IP
+   address.
+   
+   You will notice that we haven't configured the arc0e device on insight. 
+   This would work, but is not really necessary, and would require me to
+   assign insight another special IP number from my private subnet.  Since
+   both insight and patience are using freedom as their default gateway, the
+   two can already talk to each other.
+   
+   It's quite fortunate that I set things up like this the first time (cough
+   cough) because it's really handy when I boot insight into DOS.  There, it
+   runs the Novell ODI protocol stack, which only works with RFC1201 ARCnet. 
+   In this mode it would be impossible for insight to communicate directly
+   with patience, since the Novell stack is incompatible with Microsoft's
+   Ethernet-Encap.  Without changing any settings on freedom or patience, I
+   simply set freedom as the default gateway for insight (now in DOS,
+   remember) and all the forwarding happens "automagically" between the two
+   hosts that would normally not be able to communicate at all.
+   
+   For those who like diagrams, I have created two "virtual subnets" on the
+   same physical ARCnet wire.  You can picture it like this:
+   
+                                                    
+          [RFC1201 NETWORK]                   [ETHER-ENCAP NETWORK]
+      (registered Internet subnet)           (RFC1597 private subnet)
+  
+                             (IP Masquerade)
+          /---------------\         *            /---------------\
+          |               |         *            |               |
+          |               +-Freedom-*-Gatekeeper-+               |
+          |               |    |    *            |               |
+          \-------+-------/    |    *            \-------+-------/
+                  |            |                         |
+               Insight         |                      Patience
+                           (Internet)
+
+
+
+It works: what now?
+-------------------
+
+Send mail describing your setup, preferably including driver version, kernel
+version, ARCnet card model, CPU type, number of systems on your network, and
+list of software in use to me at the following address:
+        apenwarr@worldvisions.ca
+
+I do send (sometimes automated) replies to all messages I receive.  My email
+can be weird (and also usually gets forwarded all over the place along the
+way to me), so if you don't get a reply within a reasonable time, please
+resend.
+
+
+It doesn't work: what now?
+--------------------------
+
+Do the same as above, but also include the output of the ifconfig and route
+commands, as well as any pertinent log entries (ie. anything that starts
+with "arcnet:" and has shown up since the last reboot) in your mail.
+
+If you want to try fixing it yourself (I strongly recommend that you mail me
+about the problem first, since it might already have been solved) you may
+want to try some of the debug levels available.  For heavy testing on
+D_DURING or more, it would be a REALLY good idea to kill your klogd daemon
+first!  D_DURING displays 4-5 lines for each packet sent or received.  D_TX,
+D_RX, and D_SKB actually DISPLAY each packet as it is sent or received,
+which is obviously quite big.
+
+Starting with v2.40 ALPHA, the autoprobe routines have changed
+significantly.  In particular, they won't tell you why the card was not
+found unless you turn on the D_INIT_REASONS debugging flag.
+
+Once the driver is running, you can run the arcdump shell script (available
+from me or in the full ARCnet package, if you have it) as root to list the
+contents of the arcnet buffers at any time.  To make any sense at all out of
+this, you should grab the pertinent RFCs. (some are listed near the top of
+arcnet.c).  arcdump assumes your card is at 0xD0000.  If it isn't, edit the
+script.
+
+Buffers 0 and 1 are used for receiving, and Buffers 2 and 3 are for sending. 
+Ping-pong buffers are implemented both ways.
+
+If your debug level includes D_DURING and you did NOT define SLOW_XMIT_COPY,
+the buffers are cleared to a constant value of 0x42 every time the card is
+reset (which should only happen when you do an ifconfig up, or when Linux
+decides that the driver is broken).  During a transmit, unused parts of the
+buffer will be cleared to 0x42 as well.  This is to make it easier to figure
+out which bytes are being used by a packet.
+
+You can change the debug level without recompiling the kernel by typing:
+        ifconfig arc0 down metric 1xxx
+        /etc/rc.d/rc.inet1
+where "xxx" is the debug level you want.  For example, "metric 1015" would put
+you at debug level 15.  Debug level 7 is currently the default.
+
+Note that the debug level is (starting with v1.90 ALPHA) a binary
+combination of different debug flags; so debug level 7 is really 1+2+4 or
+D_NORMAL+D_EXTRA+D_INIT.  To include D_DURING, you would add 16 to this,
+resulting in debug level 23.
+
+If you don't understand that, you probably don't want to know anyway. 
+E-mail me about your problem.
+
+
+I want to send money: what now?
+-------------------------------
+
+Go take a nap or something.  You'll feel better in the morning.
diff --git a/Documentation/networking/atm.txt b/Documentation/networking/atm.txt
new file mode 100644
index 00000000000..82921cee77f
--- /dev/null
+++ b/Documentation/networking/atm.txt
@@ -0,0 +1,8 @@
+In order to use anything but the most primitive functions of ATM,
+several user-mode programs are required to assist the kernel. These
+programs and related material can be found via the ATM on Linux Web
+page at http://linux-atm.sourceforge.net/
+
+If you encounter problems with ATM, please report them on the ATM
+on Linux mailing list. Subscription information, archives, etc.,
+can be found on http://linux-atm.sourceforge.net/
diff --git a/Documentation/networking/ax25.txt b/Documentation/networking/ax25.txt
new file mode 100644
index 00000000000..37c25b0925f
--- /dev/null
+++ b/Documentation/networking/ax25.txt
@@ -0,0 +1,16 @@
+To use the amateur radio protocols within Linux you will need to get a
+suitable copy of the AX.25 Utilities. More detailed information about these
+and associated programs can be found on http://zone.pspt.fi/~jsn/.
+
+For more information about the AX.25, NET/ROM and ROSE protocol stacks, see
+the AX25-HOWTO written by Terry Dawson <terry@perf.no.itg.telstra.com.au>
+who is also the AX.25 Utilities maintainer.
+
+There is an active mailing list for discussing Linux amateur radio matters
+called linux-hams. To subscribe to it, send a message to
+majordomo@vger.kernel.org with the words "subscribe linux-hams" in the body
+of the message, the subject field is ignored.
+
+Jonathan G4KLX
+
+g4klx@g4klx.demon.co.uk
diff --git a/Documentation/networking/baycom.txt b/Documentation/networking/baycom.txt
new file mode 100644
index 00000000000..4e68849d563
--- /dev/null
+++ b/Documentation/networking/baycom.txt
@@ -0,0 +1,158 @@
+                    LINUX DRIVERS FOR BAYCOM MODEMS
+
+       Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch>
+
+!!NEW!! (04/98) The drivers for the baycom modems have been split into
+separate drivers as they did not share any code, and the driver
+and device names have changed.
+
+This document describes the Linux Kernel Drivers for simple Baycom style
+amateur radio modems. 
+
+The following drivers are available:
+
+baycom_ser_fdx:
+  This driver supports the SER12 modems either full or half duplex.
+  Its baud rate may be changed via the `baud' module parameter,
+  therefore it supports just about every bit bang modem on a
+  serial port. Its devices are called bcsf0 through bcsf3.
+  This is the recommended driver for SER12 type modems,
+  however if you have a broken UART clone that does not have working
+  delta status bits, you may try baycom_ser_hdx. 
+
+baycom_ser_hdx: 
+  This is an alternative driver for SER12 type modems.
+  It only supports half duplex, and only 1200 baud. Its devices
+  are called bcsh0 through bcsh3. Use this driver only if baycom_ser_fdx
+  does not work with your UART.
+
+baycom_par:
+  This driver supports the par96 and picpar modems.
+  Its devices are called bcp0 through bcp3.
+
+baycom_epp:
+  This driver supports the EPP modem.
+  Its devices are called bce0 through bce3.
+  This driver is work-in-progress.
+
+The following modems are supported:
+
+ser12:  This is a very simple 1200 baud AFSK modem. The modem consists only
+        of a modulator/demodulator chip, usually a TI TCM3105. The computer
+        is responsible for regenerating the receiver bit clock, as well as
+        for handling the HDLC protocol. The modem connects to a serial port,
+        hence the name. Since the serial port is not used as an async serial
+        port, the kernel driver for serial ports cannot be used, and this
+        driver only supports standard serial hardware (8250, 16450, 16550)
+
+par96:  This is a modem for 9600 baud FSK compatible to the G3RUH standard.
+        The modem does all the filtering and regenerates the receiver clock.
+        Data is transferred from and to the PC via a shift register.
+        The shift register is filled with 16 bits and an interrupt is signalled.
+        The PC then empties the shift register in a burst. This modem connects
+        to the parallel port, hence the name. The modem leaves the 
+        implementation of the HDLC protocol and the scrambler polynomial to
+        the PC.
+
+picpar: This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem
+        is protocol compatible to par96, but uses only three low power ICs
+        and can therefore be fed from the parallel port and does not require
+        an additional power supply. Furthermore, it incorporates a carrier
+        detect circuitry.
+
+EPP:    This is a high-speed modem adaptor that connects to an enhanced parallel port.
+        Its target audience is users working over a high speed hub (76.8kbit/s).
+
+eppfpga: This is a redesign of the EPP adaptor.
+
+
+
+All of the above modems only support half duplex communications. However,
+the driver supports the KISS (see below) fullduplex command. It then simply
+starts to send as soon as there's a packet to transmit and does not care
+about DCD, i.e. it starts to send even if there's someone else on the channel.
+This command is required by some implementations of the DAMA channel 
+access protocol.
+
+
+The Interface of the drivers
+
+Unlike previous drivers, these drivers are no longer character devices,
+but they are now true kernel network interfaces. Installation is therefore
+simple. Once installed, four interfaces named bc{sf,sh,p,e}[0-3] are available.
+sethdlc from the ax25 utilities may be used to set driver states etc.
+Users of userland AX.25 stacks may use the net2kiss utility (also available
+in the ax25 utilities package) to convert packets of a network interface
+to a KISS stream on a pseudo tty. There's also a patch available from
+me for WAMPES which allows attaching a kernel network interface directly.
+
+
+Configuring the driver
+
+Every time a driver is inserted into the kernel, it has to know which
+modems it should access at which ports. This can be done with the setbaycom
+utility. If you are only using one modem, you can also configure the
+driver from the insmod command line (or by means of an option line in
+/etc/modprobe.conf).
+
+Examples:
+  modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4
+  sethdlc -i bcsf0 -p mode "ser12*" io 0x3f8 irq 4
+
+Both lines configure the first port to drive a ser12 modem at the first
+serial port (COM1 under DOS). The * in the mode parameter instructs the driver to use
+the software DCD algorithm (see below).
+
+  insmod baycom_par mode="picpar" iobase=0x378
+  sethdlc -i bcp0 -p mode "picpar" io 0x378
+
+Both lines configure the first port to drive a picpar modem at the
+first parallel port (LPT1 under DOS). (Note: picpar implies
+hardware DCD, par96 implies software DCD).
+
+The channel access parameters can be set with sethdlc -a or kissparms.
+Note that both utilities interpret the values slightly differently.
+
+
+Hardware DCD versus Software DCD
+
+To avoid collisions on the air, the driver must know when the channel is
+busy. This is the task of the DCD circuitry/software. The driver may either
+utilise a software DCD algorithm (options=1) or use a DCD signal from
+the hardware (options=0).
+
+ser12:  if software DCD is utilised, the radio's squelch should always be
+        open. It is highly recommended to use the software DCD algorithm,
+        as it is much faster than most hardware squelch circuitry. The
+        disadvantage is a slightly higher load on the system.
+
+par96:  the software DCD algorithm for this type of modem is rather poor.
+        The modem simply does not provide enough information to implement
+        a reasonable DCD algorithm in software. Therefore, if your radio
+        feeds the DCD input of the PAR96 modem, the use of the hardware
+        DCD circuitry is recommended.
+
+picpar: the picpar modem features a builtin DCD hardware, which is highly
+        recommended.
+
+
+
+Compatibility with the rest of the Linux kernel
+
+The serial driver and the baycom serial drivers compete
+for the same hardware resources. Of course only one driver can access a given
+interface at a time. The serial driver grabs all interfaces it can find at
+startup time. Therefore the baycom drivers subsequently won't be able to
+access a serial port. You might therefore find it necessary to release
+a port owned by the serial driver with 'setserial /dev/ttyS# uart none', where
+# is the number of the interface. The baycom drivers do not reserve any
+ports at startup, unless one is specified on the 'insmod' command line. Another
+method to solve the problem is to compile all drivers as modules and
+leave it to kmod to load the correct driver depending on the application.
+
+The parallel port drivers (baycom_par, baycom_epp) now use the parport subsystem
+to arbitrate the ports between different client drivers.
+
+vy 73s de
+Tom Sailer, sailer@ife.ee.ethz.ch
+hb9jnx @ hb9w.ampr.org
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
new file mode 100644
index 00000000000..0bc2ed136a3
--- /dev/null
+++ b/Documentation/networking/bonding.txt
@@ -0,0 +1,1618 @@
+
+                   Linux Ethernet Bonding Driver HOWTO
+
+Initial release : Thomas Davis <tadavis at lbl.gov>
+Corrections, HA extensions : 2000/10/03-15 :
+  - Willy Tarreau <willy at meta-x.org>
+  - Constantine Gavrilov <const-g at xpert.com>
+  - Chad N. Tindel <ctindel at ieee dot org>
+  - Janice Girouard <girouard at us dot ibm dot com>
+  - Jay Vosburgh <fubar at us dot ibm dot com>
+
+Reorganized and updated Feb 2005 by Jay Vosburgh
+
+Note :
+------
+        
+The bonding driver originally came from Donald Becker's beowulf patches for
+kernel 2.0. It has changed quite a bit since, and the original tools from
+extreme-linux and beowulf sites will not work with this version of the driver.
+
+For new versions of the driver, patches for older kernels and the updated
+userspace tools, please follow the links at the end of this file.
+
+Table of Contents
+=================
+
+1. Bonding Driver Installation
+
+2. Bonding Driver Options
+
+3. Configuring Bonding Devices
+3.1     Configuration with sysconfig support
+3.2     Configuration with initscripts support
+3.3     Configuring Bonding Manually
+3.4     Configuring Multiple Bonds
+
+5. Querying Bonding Configuration
+5.1     Bonding Configuration
+5.2     Network Configuration
+
+6. Switch Configuration
+
+7. 802.1q VLAN Support
+
+8. Link Monitoring
+8.1     ARP Monitor Operation
+8.2     Configuring Multiple ARP Targets
+8.3     MII Monitor Operation
+
+9. Potential Trouble Sources
+9.1     Adventures in Routing
+9.2     Ethernet Device Renaming
+9.3     Painfully Slow Or No Failed Link Detection By Miimon
+
+10. SNMP agents
+
+11. Promiscuous mode
+
+12. High Availability Information
+12.1    High Availability in a Single Switch Topology
+12.1.1          Bonding Mode Selection for Single Switch Topology
+12.1.2          Link Monitoring for Single Switch Topology
+12.2    High Availability in a Multiple Switch Topology
+12.2.1          Bonding Mode Selection for Multiple Switch Topology
+12.2.2          Link Monitoring for Multiple Switch Topology
+12.3    Switch Behavior Issues for High Availability
+
+13. Hardware Specific Considerations
+13.1    IBM BladeCenter
+
+14. Frequently Asked Questions
+
+15. Resources and Links
+
+
+1. Bonding Driver Installation
+==============================
+
+        Most popular distro kernels ship with the bonding driver
+already available as a module and the ifenslave user level control
+program installed and ready for use. If your distro does not, or you
+have need to compile bonding from source (e.g., configuring and
+installing a mainline kernel from kernel.org), you'll need to perform
+the following steps:
+
+1.1 Configure and build the kernel with bonding
+-----------------------------------------------
+
+        The latest version of the bonding driver is available in the
+drivers/net/bonding subdirectory of the most recent kernel source
+(which is available on http://kernel.org).
+
+        Prior to the 2.4.11 kernel, the bonding driver was maintained
+largely outside the kernel tree; patches for some earlier kernels are
+available on the bonding sourceforge site, although those patches are
+still several years out of date.  Most users will want to use either
+the most recent kernel from kernel.org or whatever kernel came with
+their distro.
+
+        Configure kernel with "make menuconfig" (or "make xconfig" or
+"make config"), then select "Bonding driver support" in the "Network
+device support" section.  It is recommended that you configure the
+driver as module since it is currently the only way to pass parameters
+to the driver or configure more than one bonding device.
+
+        Build and install the new kernel and modules, then proceed to
+step 2.
+
+1.2 Install ifenslave Control Utility
+-------------------------------------
+
+        The ifenslave user level control program is included in the
+kernel source tree, in the file Documentation/networking/ifenslave.c.
+It is generally recommended that you use the ifenslave that
+corresponds to the kernel that you are using (either from the same
+source tree or supplied with the distro), however, ifenslave
+executables from older kernels should function (but features newer
+than the ifenslave release are not supported).  Running an ifenslave
+that is newer than the kernel is not supported, and may or may not
+work.
+
+        To install ifenslave, do the following:
+
+# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave
+# cp ifenslave /sbin/ifenslave
+
+        If your kernel source is not in "/usr/src/linux," then replace
+"/usr/src/linux/include" in the above with the location of your kernel
+source include directory.
+
+        You may wish to back up any existing /sbin/ifenslave, or, for
+testing or informal use, tag the ifenslave to the kernel version
+(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10).
+
+IMPORTANT NOTE:
+
+        If you omit the "-I" or specify an incorrect directory, you
+may end up with an ifenslave that is incompatible with the kernel
+you're trying to build it for.  Some distros (e.g., Red Hat from 7.1
+onwards) do not have /usr/include/linux symbolically linked to the
+default kernel source include directory.
+
+
+2. Bonding Driver Options
+=========================
+
+        Options for the bonding driver are supplied as parameters to
+the bonding module at load time.  They may be given as command line
+arguments to the insmod or modprobe command, but are usually specified
+in either the /etc/modprobe.conf configuration file, or in a
+distro-specific configuration file (some of which are detailed in the
+next section).
+
+        The available bonding driver parameters are listed below. If a
+parameter is not specified the default value is used.  When initially
+configuring a bond, it is recommended "tail -f /var/log/messages" be
+run in a separate window to watch for bonding driver error messages.
+
+        It is critical that either the miimon or arp_interval and
+arp_ip_target parameters be specified, otherwise serious network
+degradation will occur during link failures.  Very few devices do not
+support at least miimon, so there is really no reason not to use it.
+
+        Options with textual values will accept either the text name
+        or, for backwards compatibility, the option value.  E.g.,
+        "mode=802.3ad" and "mode=4" set the same mode.
+
+        The parameters are as follows:
+
+arp_interval
+
+        Specifies the ARP monitoring frequency in milli-seconds. If
+        ARP monitoring is used in a load-balancing mode (mode 0 or 2),
+        the switch should be configured in a mode that evenly
+        distributes packets across all links - such as round-robin. If
+        the switch is configured to distribute the packets in an XOR
+        fashion, all replies from the ARP targets will be received on
+        the same link which could cause the other team members to
+        fail. ARP monitoring should not be used in conjunction with
+        miimon. A value of 0 disables ARP monitoring. The default
+        value is 0.
+
+arp_ip_target
+
+        Specifies the ip addresses to use when arp_interval is > 0.
+        These are the targets of the ARP request sent to determine the
+        health of the link to the targets.  Specify these values in
+        ddd.ddd.ddd.ddd format.  Multiple ip adresses must be
+        seperated by a comma.  At least one IP address must be given
+        for ARP monitoring to function.  The maximum number of targets
+        that can be specified is 16.  The default value is no IP
+        addresses.
+
+downdelay
+
+        Specifies the time, in milliseconds, to wait before disabling
+        a slave after a link failure has been detected.  This option
+        is only valid for the miimon link monitor.  The downdelay
+        value should be a multiple of the miimon value; if not, it
+        will be rounded down to the nearest multiple.  The default
+        value is 0.
+
+lacp_rate
+
+        Option specifying the rate in which we'll ask our link partner
+        to transmit LACPDU packets in 802.3ad mode.  Possible values
+        are:
+
+        slow or 0
+                Request partner to transmit LACPDUs every 30 seconds (default)
+
+        fast or 1
+                Request partner to transmit LACPDUs every 1 second
+
+max_bonds
+
+        Specifies the number of bonding devices to create for this
+        instance of the bonding driver.  E.g., if max_bonds is 3, and
+        the bonding driver is not already loaded, then bond0, bond1
+        and bond2 will be created.  The default value is 1.
+
+miimon
+
+        Specifies the frequency in milli-seconds that MII link
+        monitoring will occur.  A value of zero disables MII link
+        monitoring.  A value of 100 is a good starting point.  The
+        use_carrier option, below, affects how the link state is
+        determined.  See the High Availability section for additional
+        information.  The default value is 0.
+
+mode
+
+        Specifies one of the bonding policies. The default is
+        balance-rr (round robin).  Possible values are:
+
+        balance-rr or 0
+
+                Round-robin policy: Transmit packets in sequential
+                order from the first available slave through the
+                last.  This mode provides load balancing and fault
+                tolerance.
+
+        active-backup or 1
+
+                Active-backup policy: Only one slave in the bond is
+                active.  A different slave becomes active if, and only
+                if, the active slave fails.  The bond's MAC address is
+                externally visible on only one port (network adapter)
+                to avoid confusing the switch.  This mode provides
+                fault tolerance.  The primary option affects the
+                behavior of this mode.
+
+        balance-xor or 2
+
+                XOR policy: Transmit based on [(source MAC address
+                XOR'd with destination MAC address) modulo slave
+                count].  This selects the same slave for each
+                destination MAC address.  This mode provides load
+                balancing and fault tolerance.
+
+        broadcast or 3
+
+                Broadcast policy: transmits everything on all slave
+                interfaces.  This mode provides fault tolerance.
+
+        802.3ad or 4
+
+                IEEE 802.3ad Dynamic link aggregation.  Creates
+                aggregation groups that share the same speed and
+                duplex settings.  Utilizes all slaves in the active
+                aggregator according to the 802.3ad specification.
+
+                Pre-requisites:
+
+                1. Ethtool support in the base drivers for retrieving
+                the speed and duplex of each slave.
+
+                2. A switch that supports IEEE 802.3ad Dynamic link
+                aggregation.
+
+                Most switches will require some type of configuration
+                to enable 802.3ad mode.
+
+        balance-tlb or 5
+
+                Adaptive transmit load balancing: channel bonding that
+                does not require any special switch support.  The
+                outgoing traffic is distributed according to the
+                current load (computed relative to the speed) on each
+                slave.  Incoming traffic is received by the current
+                slave.  If the receiving slave fails, another slave
+                takes over the MAC address of the failed receiving
+                slave.
+
+                Prerequisite:
+
+                Ethtool support in the base drivers for retrieving the
+                speed of each slave.
+
+        balance-alb or 6
+
+                Adaptive load balancing: includes balance-tlb plus
+                receive load balancing (rlb) for IPV4 traffic, and
+                does not require any special switch support.  The
+                receive load balancing is achieved by ARP negotiation.
+                The bonding driver intercepts the ARP Replies sent by
+                the local system on their way out and overwrites the
+                source hardware address with the unique hardware
+                address of one of the slaves in the bond such that
+                different peers use different hardware addresses for
+                the server.
+
+                Receive traffic from connections created by the server
+                is also balanced.  When the local system sends an ARP
+                Request the bonding driver copies and saves the peer's
+                IP information from the ARP packet.  When the ARP
+                Reply arrives from the peer, its hardware address is
+                retrieved and the bonding driver initiates an ARP
+                reply to this peer assigning it to one of the slaves
+                in the bond.  A problematic outcome of using ARP
+                negotiation for balancing is that each time that an
+                ARP request is broadcast it uses the hardware address
+                of the bond.  Hence, peers learn the hardware address
+                of the bond and the balancing of receive traffic
+                collapses to the current slave.  This is handled by
+                sending updates (ARP Replies) to all the peers with
+                their individually assigned hardware address such that
+                the traffic is redistributed.  Receive traffic is also
+                redistributed when a new slave is added to the bond
+                and when an inactive slave is re-activated.  The
+                receive load is distributed sequentially (round robin)
+                among the group of highest speed slaves in the bond.
+
+                When a link is reconnected or a new slave joins the
+                bond the receive traffic is redistributed among all
+                active slaves in the bond by intiating ARP Replies
+                with the selected mac address to each of the
+                clients. The updelay parameter (detailed below) must
+                be set to a value equal or greater than the switch's
+                forwarding delay so that the ARP Replies sent to the
+                peers will not be blocked by the switch.
+
+                Prerequisites:
+
+                1. Ethtool support in the base drivers for retrieving
+                the speed of each slave.
+
+                2. Base driver support for setting the hardware
+                address of a device while it is open.  This is
+                required so that there will always be one slave in the
+                team using the bond hardware address (the
+                curr_active_slave) while having a unique hardware
+                address for each slave in the bond.  If the
+                curr_active_slave fails its hardware address is
+                swapped with the new curr_active_slave that was
+                chosen.
+
+primary
+
+        A string (eth0, eth2, etc) specifying which slave is the
+        primary device.  The specified device will always be the
+        active slave while it is available.  Only when the primary is
+        off-line will alternate devices be used.  This is useful when
+        one slave is preferred over another, e.g., when one slave has
+        higher throughput than another.
+
+        The primary option is only valid for active-backup mode.
+
+updelay
+
+        Specifies the time, in milliseconds, to wait before enabling a
+        slave after a link recovery has been detected.  This option is
+        only valid for the miimon link monitor.  The updelay value
+        should be a multiple of the miimon value; if not, it will be
+        rounded down to the nearest multiple.  The default value is 0.
+
+use_carrier
+
+        Specifies whether or not miimon should use MII or ETHTOOL
+        ioctls vs. netif_carrier_ok() to determine the link
+        status. The MII or ETHTOOL ioctls are less efficient and
+        utilize a deprecated calling sequence within the kernel.  The
+        netif_carrier_ok() relies on the device driver to maintain its
+        state with netif_carrier_on/off; at this writing, most, but
+        not all, device drivers support this facility.
+
+        If bonding insists that the link is up when it should not be,
+        it may be that your network device driver does not support
+        netif_carrier_on/off.  The default state for netif_carrier is
+        "carrier on," so if a driver does not support netif_carrier,
+        it will appear as if the link is always up.  In this case,
+        setting use_carrier to 0 will cause bonding to revert to the
+        MII / ETHTOOL ioctl method to determine the link state.
+
+        A value of 1 enables the use of netif_carrier_ok(), a value of
+        0 will use the deprecated MII / ETHTOOL ioctls.  The default
+        value is 1.
+
+
+
+3. Configuring Bonding Devices
+==============================
+
+        There are, essentially, two methods for configuring bonding:
+with support from the distro's network initialization scripts, and
+without.  Distros generally use one of two packages for the network
+initialization scripts: initscripts or sysconfig.  Recent versions of
+these packages have support for bonding, while older versions do not.
+
+        We will first describe the options for configuring bonding for
+distros using versions of initscripts and sysconfig with full or
+partial support for bonding, then provide information on enabling
+bonding without support from the network initialization scripts (i.e.,
+older versions of initscripts or sysconfig).
+
+        If you're unsure whether your distro uses sysconfig or
+initscripts, or don't know if it's new enough, have no fear.
+Determining this is fairly straightforward.
+
+        First, issue the command:
+
+$ rpm -qf /sbin/ifup
+
+        It will respond with a line of text starting with either
+"initscripts" or "sysconfig," followed by some numbers.  This is the
+package that provides your network initialization scripts.
+
+        Next, to determine if your installation supports bonding,
+issue the command:
+
+$ grep ifenslave /sbin/ifup
+
+        If this returns any matches, then your initscripts or
+sysconfig has support for bonding.
+
+3.1 Configuration with sysconfig support
+----------------------------------------
+
+        This section applies to distros using a version of sysconfig
+with bonding support, for example, SuSE Linux Enterprise Server 9.
+
+        SuSE SLES 9's networking configuration system does support
+bonding, however, at this writing, the YaST system configuration
+frontend does not provide any means to work with bonding devices.
+Bonding devices can be managed by hand, however, as follows.
+
+        First, if they have not already been configured, configure the
+slave devices.  On SLES 9, this is most easily done by running the
+yast2 sysconfig configuration utility.  The goal is for to create an
+ifcfg-id file for each slave device.  The simplest way to accomplish
+this is to configure the devices for DHCP.  The name of the
+configuration file for each device will be of the form:
+
+ifcfg-id-xx:xx:xx:xx:xx:xx
+
+        Where the "xx" portion will be replaced with the digits from
+the device's permanent MAC address.
+
+        Once the set of ifcfg-id-xx:xx:xx:xx:xx:xx files has been
+created, it is necessary to edit the configuration files for the slave
+devices (the MAC addresses correspond to those of the slave devices).
+Before editing, the file will contain muliple lines, and will look
+something like this:
+
+BOOTPROTO='dhcp'
+STARTMODE='on'
+USERCTL='no'
+UNIQUE='XNzu.WeZGOGF+4wE'
+_nm_name='bus-pci-0001:61:01.0'
+
+        Change the BOOTPROTO and STARTMODE lines to the following:
+
+BOOTPROTO='none'
+STARTMODE='off'
+
+        Do not alter the UNIQUE or _nm_name lines.  Remove any other
+lines (USERCTL, etc).
+
+        Once the ifcfg-id-xx:xx:xx:xx:xx:xx files have been modified,
+it's time to create the configuration file for the bonding device
+itself.  This file is named ifcfg-bondX, where X is the number of the
+bonding device to create, starting at 0.  The first such file is
+ifcfg-bond0, the second is ifcfg-bond1, and so on.  The sysconfig
+network configuration system will correctly start multiple instances
+of bonding.
+
+        The contents of the ifcfg-bondX file is as follows:
+
+BOOTPROTO="static"
+BROADCAST="10.0.2.255"
+IPADDR="10.0.2.10"
+NETMASK="255.255.0.0"
+NETWORK="10.0.2.0"
+REMOTE_IPADDR=""
+STARTMODE="onboot"
+BONDING_MASTER="yes"
+BONDING_MODULE_OPTS="mode=active-backup miimon=100"
+BONDING_SLAVE0="eth0"
+BONDING_SLAVE1="eth1"
+
+        Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK
+values with the appropriate values for your network.
+
+        Note that configuring the bonding device with BOOTPROTO='dhcp'
+does not work; the scripts attempt to obtain the device address from
+DHCP prior to adding any of the slave devices.  Without active slaves,
+the DHCP requests are not sent to the network.
+
+        The STARTMODE specifies when the device is brought online.
+The possible values are:
+
+        onboot:  The device is started at boot time.  If you're not
+                 sure, this is probably what you want.
+
+        manual:  The device is started only when ifup is called
+                 manually.  Bonding devices may be configured this
+                 way if you do not wish them to start automatically
+                 at boot for some reason.
+
+        hotplug: The device is started by a hotplug event.  This is not
+                 a valid choice for a bonding device.
+
+        off or ignore: The device configuration is ignored.
+
+        The line BONDING_MASTER='yes' indicates that the device is a
+bonding master device.  The only useful value is "yes."
+
+        The contents of BONDING_MODULE_OPTS are supplied to the
+instance of the bonding module for this device.  Specify the options
+for the bonding mode, link monitoring, and so on here.  Do not include
+the max_bonds bonding parameter; this will confuse the configuration
+system if you have multiple bonding devices.
+
+        Finally, supply one BONDING_SLAVEn="ethX" for each slave,
+where "n" is an increasing value, one for each slave, and "ethX" is
+the name of the slave device (eth0, eth1, etc).
+
+        When all configuration files have been modified or created,
+networking must be restarted for the configuration changes to take
+effect.  This can be accomplished via the following:
+
+# /etc/init.d/network restart
+
+        Note that the network control script (/sbin/ifdown) will
+remove the bonding module as part of the network shutdown processing,
+so it is not necessary to remove the module by hand if, e.g., the
+module paramters have changed.
+
+        Also, at this writing, YaST/YaST2 will not manage bonding
+devices (they do not show bonding interfaces on its list of network
+devices).  It is necessary to edit the configuration file by hand to
+change the bonding configuration.
+
+        Additional general options and details of the ifcfg file
+format can be found in an example ifcfg template file:
+
+/etc/sysconfig/network/ifcfg.template
+
+        Note that the template does not document the various BONDING_
+settings described above, but does describe many of the other options.
+
+3.2 Configuration with initscripts support
+------------------------------------------
+
+        This section applies to distros using a version of initscripts
+with bonding support, for example, Red Hat Linux 9 or Red Hat
+Enterprise Linux version 3.  On these systems, the network
+initialization scripts have some knowledge of bonding, and can be
+configured to control bonding devices.
+
+        These distros will not automatically load the network adapter
+driver unless the ethX device is configured with an IP address.
+Because of this constraint, users must manually configure a
+network-script file for all physical adapters that will be members of
+a bondX link.  Network script files are located in the directory:
+
+/etc/sysconfig/network-scripts
+
+        The file name must be prefixed with "ifcfg-eth" and suffixed
+with the adapter's physical adapter number.  For example, the script
+for eth0 would be named /etc/sysconfig/network-scripts/ifcfg-eth0.
+Place the following text in the file:
+
+DEVICE=eth0
+USERCTL=no
+ONBOOT=yes
+MASTER=bond0
+SLAVE=yes
+BOOTPROTO=none
+
+        The DEVICE= line will be different for every ethX device and
+must correspond with the name of the file, i.e., ifcfg-eth1 must have
+a device line of DEVICE=eth1.  The setting of the MASTER= line will
+also depend on the final bonding interface name chosen for your bond.
+As with other network devices, these typically start at 0, and go up
+one for each device, i.e., the first bonding instance is bond0, the
+second is bond1, and so on.
+
+        Next, create a bond network script.  The file name for this
+script will be /etc/sysconfig/network-scripts/ifcfg-bondX where X is
+the number of the bond.  For bond0 the file is named "ifcfg-bond0",
+for bond1 it is named "ifcfg-bond1", and so on.  Within that file,
+place the following text:
+
+DEVICE=bond0
+IPADDR=192.168.1.1
+NETMASK=255.255.255.0
+NETWORK=192.168.1.0
+BROADCAST=192.168.1.255
+ONBOOT=yes
+BOOTPROTO=none
+USERCTL=no
+
+        Be sure to change the networking specific lines (IPADDR,
+NETMASK, NETWORK and BROADCAST) to match your network configuration.
+
+        Finally, it is necessary to edit /etc/modules.conf to load the
+bonding module when the bond0 interface is brought up.  The following
+sample lines in /etc/modules.conf will load the bonding module, and
+select its options:
+
+alias bond0 bonding
+options bond0 mode=balance-alb miimon=100
+
+        Replace the sample parameters with the appropriate set of
+options for your configuration.
+
+        Finally run "/etc/rc.d/init.d/network restart" as root.  This
+will restart the networking subsystem and your bond link should be now
+up and running.
+
+
+3.3 Configuring Bonding Manually
+--------------------------------
+
+        This section applies to distros whose network initialization
+scripts (the sysconfig or initscripts package) do not have specific
+knowledge of bonding.  One such distro is SuSE Linux Enterprise Server
+version 8.
+
+        The general methodology for these systems is to place the
+bonding module parameters into /etc/modprobe.conf, then add modprobe
+and/or ifenslave commands to the system's global init script.  The
+name of the global init script differs; for sysconfig, it is
+/etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local.
+
+        For example, if you wanted to make a simple bond of two e100
+devices (presumed to be eth0 and eth1), and have it persist across
+reboots, edit the appropriate file (/etc/init.d/boot.local or
+/etc/rc.d/rc.local), and add the following:
+
+modprobe bonding -obond0 mode=balance-alb miimon=100
+modprobe e100
+ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
+ifenslave bond0 eth0
+ifenslave bond0 eth1
+
+        Replace the example bonding module parameters and bond0
+network configuration (IP address, netmask, etc) with the appropriate
+values for your configuration.  The above example loads the bonding
+module with the name "bond0," this simplifies the naming if multiple
+bonding modules are loaded (each successive instance of the module is
+given a different name, and the module instance names match the
+bonding interface names).
+
+        Unfortunately, this method will not provide support for the
+ifup and ifdown scripts on the bond devices.  To reload the bonding
+configuration, it is necessary to run the initialization script, e.g.,
+
+# /etc/init.d/boot.local
+
+        or
+
+# /etc/rc.d/rc.local
+
+        It may be desirable in such a case to create a separate script
+which only initializes the bonding configuration, then call that
+separate script from within boot.local.  This allows for bonding to be
+enabled without re-running the entire global init script.
+
+        To shut down the bonding devices, it is necessary to first
+mark the bonding device itself as being down, then remove the
+appropriate device driver modules.  For our example above, you can do
+the following:
+
+# ifconfig bond0 down
+# rmmod bond0
+# rmmod e100
+
+        Again, for convenience, it may be desirable to create a script
+with these commands.
+
+
+3.4 Configuring Multiple Bonds
+------------------------------
+
+        This section contains information on configuring multiple
+bonding devices with differing options.  If you require multiple
+bonding devices, but all with the same options, see the "max_bonds"
+module paramter, documented above.
+
+        To create multiple bonding devices with differing options, it
+is necessary to load the bonding driver multiple times.  Note that
+current versions of the sysconfig network initialization scripts
+handle this automatically; if your distro uses these scripts, no
+special action is needed.  See the section Configuring Bonding
+Devices, above, if you're not sure about your network initialization
+scripts.
+
+        To load multiple instances of the module, it is necessary to
+specify a different name for each instance (the module loading system
+requires that every loaded module, even multiple instances of the same
+module, have a unique name).  This is accomplished by supplying
+multiple sets of bonding options in /etc/modprobe.conf, for example:
+        
+alias bond0 bonding
+options bond0 -o bond0 mode=balance-rr miimon=100
+
+alias bond1 bonding
+options bond1 -o bond1 mode=balance-alb miimon=50
+
+        will load the bonding module two times.  The first instance is
+named "bond0" and creates the bond0 device in balance-rr mode with an
+miimon of 100.  The second instance is named "bond1" and creates the
+bond1 device in balance-alb mode with an miimon of 50.
+
+        This may be repeated any number of times, specifying a new and
+unique name in place of bond0 or bond1 for each instance.
+
+        When the appropriate module paramters are in place, then
+configure bonding according to the instructions for your distro.
+
+5. Querying Bonding Configuration 
+=================================
+
+5.1 Bonding Configuration
+-------------------------
+
+        Each bonding device has a read-only file residing in the
+/proc/net/bonding directory.  The file contents include information
+about the bonding configuration, options and state of each slave.
+
+        For example, the contents of /proc/net/bonding/bond0 after the
+driver is loaded with parameters of mode=0 and miimon=1000 is
+generally as follows:
+
+        Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004)
+        Bonding Mode: load balancing (round-robin)
+        Currently Active Slave: eth0
+        MII Status: up
+        MII Polling Interval (ms): 1000
+        Up Delay (ms): 0
+        Down Delay (ms): 0
+
+        Slave Interface: eth1
+        MII Status: up
+        Link Failure Count: 1
+
+        Slave Interface: eth0
+        MII Status: up
+        Link Failure Count: 1
+
+        The precise format and contents will change depending upon the
+bonding configuration, state, and version of the bonding driver.
+
+5.2 Network configuration
+-------------------------
+
+        The network configuration can be inspected using the ifconfig
+command.  Bonding devices will have the MASTER flag set; Bonding slave
+devices will have the SLAVE flag set.  The ifconfig output does not
+contain information on which slaves are associated with which masters.
+
+        In the example below, the bond0 interface is the master
+(MASTER) while eth0 and eth1 are slaves (SLAVE). Notice all slaves of
+bond0 have the same MAC address (HWaddr) as bond0 for all modes except
+TLB and ALB that require a unique MAC address for each slave.
+
+# /sbin/ifconfig
+bond0     Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
+          inet addr:XXX.XXX.XXX.YYY  Bcast:XXX.XXX.XXX.255  Mask:255.255.252.0
+          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
+          RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0
+          collisions:0 txqueuelen:0
+
+eth0      Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
+          inet addr:XXX.XXX.XXX.YYY  Bcast:XXX.XXX.XXX.255  Mask:255.255.252.0
+          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
+          RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0
+          collisions:0 txqueuelen:100
+          Interrupt:10 Base address:0x1080
+
+eth1      Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
+          inet addr:XXX.XXX.XXX.YYY  Bcast:XXX.XXX.XXX.255  Mask:255.255.252.0
+          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
+          RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:100
+          Interrupt:9 Base address:0x1400
+
+6. Switch Configuration
+=======================
+
+        For this section, "switch" refers to whatever system the
+bonded devices are directly connected to (i.e., where the other end of
+the cable plugs into).  This may be an actual dedicated switch device,
+or it may be another regular system (e.g., another computer running
+Linux),
+
+        The active-backup, balance-tlb and balance-alb modes do not
+require any specific configuration of the switch.
+
+        The 802.3ad mode requires that the switch have the appropriate
+ports configured as an 802.3ad aggregation.  The precise method used
+to configure this varies from switch to switch, but, for example, a
+Cisco 3550 series switch requires that the appropriate ports first be
+grouped together in a single etherchannel instance, then that
+etherchannel is set to mode "lacp" to enable 802.3ad (instead of
+standard EtherChannel).
+
+        The balance-rr, balance-xor and broadcast modes generally
+require that the switch have the appropriate ports grouped together.
+The nomenclature for such a group differs between switches, it may be
+called an "etherchannel" (as in the Cisco example, above), a "trunk
+group" or some other similar variation.  For these modes, each switch
+will also have its own configuration options for the switch's transmit
+policy to the bond.  Typical choices include XOR of either the MAC or
+IP addresses.  The transmit policy of the two peers does not need to
+match.  For these three modes, the bonding mode really selects a
+transmit policy for an EtherChannel group; all three will interoperate
+with another EtherChannel group.
+
+
+7. 802.1q VLAN Support
+======================
+
+        It is possible to configure VLAN devices over a bond interface
+using the 8021q driver.  However, only packets coming from the 8021q
+driver and passing through bonding will be tagged by default.  Self
+generated packets, for example, bonding's learning packets or ARP
+packets generated by either ALB mode or the ARP monitor mechanism, are
+tagged internally by bonding itself.  As a result, bonding must
+"learn" the VLAN IDs configured above it, and use those IDs to tag
+self generated packets.
+
+        For reasons of simplicity, and to support the use of adapters
+that can do VLAN hardware acceleration offloding, the bonding
+interface declares itself as fully hardware offloaing capable, it gets
+the add_vid/kill_vid notifications to gather the necessary
+information, and it propagates those actions to the slaves.  In case
+of mixed adapter types, hardware accelerated tagged packets that
+should go through an adapter that is not offloading capable are
+"un-accelerated" by the bonding driver so the VLAN tag sits in the
+regular location.
+
+        VLAN interfaces *must* be added on top of a bonding interface
+only after enslaving at least one slave.  The bonding interface has a
+hardware address of 00:00:00:00:00:00 until the first slave is added.
+If the VLAN interface is created prior to the first enslavement, it
+would pick up the all-zeroes hardware address.  Once the first slave
+is attached to the bond, the bond device itself will pick up the
+slave's hardware address, which is then available for the VLAN device.
+
+        Also, be aware that a similar problem can occur if all slaves
+are released from a bond that still has one or more VLAN interfaces on
+top of it.  When a new slave is added, the bonding interface will
+obtain its hardware address from the first slave, which might not
+match the hardware address of the VLAN interfaces (which was
+ultimately copied from an earlier slave).
+
+        There are two methods to insure that the VLAN device operates
+with the correct hardware address if all slaves are removed from a
+bond interface:
+
+        1. Remove all VLAN interfaces then recreate them
+
+        2. Set the bonding interface's hardware address so that it
+matches the hardware address of the VLAN interfaces.
+
+        Note that changing a VLAN interface's HW address would set the
+underlying device -- i.e. the bonding interface -- to promiscouos
+mode, which might not be what you want.
+
+
+8. Link Monitoring
+==================
+
+        The bonding driver at present supports two schemes for
+monitoring a slave device's link state: the ARP monitor and the MII
+monitor.
+
+        At the present time, due to implementation restrictions in the
+bonding driver itself, it is not possible to enable both ARP and MII
+monitoring simultaneously.
+
+8.1 ARP Monitor Operation
+-------------------------
+
+        The ARP monitor operates as its name suggests: it sends ARP
+queries to one or more designated peer systems on the network, and
+uses the response as an indication that the link is operating.  This
+gives some assurance that traffic is actually flowing to and from one
+or more peers on the local network.
+
+        The ARP monitor relies on the device driver itself to verify
+that traffic is flowing.  In particular, the driver must keep up to
+date the last receive time, dev->last_rx, and transmit start time,
+dev->trans_start.  If these are not updated by the driver, then the
+ARP monitor will immediately fail any slaves using that driver, and
+those slaves will stay down.  If networking monitoring (tcpdump, etc)
+shows the ARP requests and replies on the network, then it may be that
+your device driver is not updating last_rx and trans_start.
+
+8.2 Configuring Multiple ARP Targets
+------------------------------------
+
+        While ARP monitoring can be done with just one target, it can
+be useful in a High Availability setup to have several targets to
+monitor.  In the case of just one target, the target itself may go
+down or have a problem making it unresponsive to ARP requests.  Having
+an additional target (or several) increases the reliability of the ARP
+monitoring.
+
+        Multiple ARP targets must be seperated by commas as follows:
+
+# example options for ARP monitoring with three targets
+alias bond0 bonding
+options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9
+
+        For just a single target the options would resemble:
+
+# example options for ARP monitoring with one target
+alias bond0 bonding
+options bond0 arp_interval=60 arp_ip_target=192.168.0.100
+
+
+8.3 MII Monitor Operation
+-------------------------
+
+        The MII monitor monitors only the carrier state of the local
+network interface.  It accomplishes this in one of three ways: by
+depending upon the device driver to maintain its carrier state, by
+querying the device's MII registers, or by making an ethtool query to
+the device.
+
+        If the use_carrier module parameter is 1 (the default value),
+then the MII monitor will rely on the driver for carrier state
+information (via the netif_carrier subsystem).  As explained in the
+use_carrier parameter information, above, if the MII monitor fails to
+detect carrier loss on the device (e.g., when the cable is physically
+disconnected), it may be that the driver does not support
+netif_carrier.
+
+        If use_carrier is 0, then the MII monitor will first query the
+device's (via ioctl) MII registers and check the link state.  If that
+request fails (not just that it returns carrier down), then the MII
+monitor will make an ethtool ETHOOL_GLINK request to attempt to obtain
+the same information.  If both methods fail (i.e., the driver either
+does not support or had some error in processing both the MII register
+and ethtool requests), then the MII monitor will assume the link is
+up.
+
+9. Potential Sources of Trouble
+===============================
+
+9.1 Adventures in Routing
+-------------------------
+
+        When bonding is configured, it is important that the slave
+devices not have routes that supercede routes of the master (or,
+generally, not have routes at all).  For example, suppose the bonding
+device bond0 has two slaves, eth0 and eth1, and the routing table is
+as follows:
+
+Kernel IP routing table
+Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
+10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 eth0
+10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 eth1
+10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 bond0
+127.0.0.0       0.0.0.0         255.0.0.0       U        40 0          0 lo
+
+        This routing configuration will likely still update the
+receive/transmit times in the driver (needed by the ARP monitor), but
+may bypass the bonding driver (because outgoing traffic to, in this
+case, another host on network 10 would use eth0 or eth1 before bond0).
+
+        The ARP monitor (and ARP itself) may become confused by this
+configuration, because ARP requests (generated by the ARP monitor)
+will be sent on one interface (bond0), but the corresponding reply
+will arrive on a different interface (eth0).  This reply looks to ARP
+as an unsolicited ARP reply (because ARP matches replies on an
+interface basis), and is discarded.  The MII monitor is not affected
+by the state of the routing table.
+
+        The solution here is simply to insure that slaves do not have
+routes of their own, and if for some reason they must, those routes do
+not supercede routes of their master.  This should generally be the
+case, but unusual configurations or errant manual or automatic static
+route additions may cause trouble.
+
+9.2 Ethernet Device Renaming
+----------------------------
+
+        On systems with network configuration scripts that do not
+associate physical devices directly with network interface names (so
+that the same physical device always has the same "ethX" name), it may
+be necessary to add some special logic to either /etc/modules.conf or
+/etc/modprobe.conf (depending upon which is installed on the system).
+
+        For example, given a modules.conf containing the following:
+
+alias bond0 bonding
+options bond0 mode=some-mode miimon=50
+alias eth0 tg3
+alias eth1 tg3
+alias eth2 e1000
+alias eth3 e1000
+
+        If neither eth0 and eth1 are slaves to bond0, then when the
+bond0 interface comes up, the devices may end up reordered.  This
+happens because bonding is loaded first, then its slave device's
+drivers are loaded next.  Since no other drivers have been loaded,
+when the e1000 driver loads, it will receive eth0 and eth1 for its
+devices, but the bonding configuration tries to enslave eth2 and eth3
+(which may later be assigned to the tg3 devices).
+
+        Adding the following:
+
+add above bonding e1000 tg3
+
+        causes modprobe to load e1000 then tg3, in that order, when
+bonding is loaded.  This command is fully documented in the
+modules.conf manual page.
+
+        On systems utilizing modprobe.conf (or modprobe.conf.local),
+an equivalent problem can occur.  In this case, the following can be
+added to modprobe.conf (or modprobe.conf.local, as appropriate), as
+follows (all on one line; it has been split here for clarity):
+
+install bonding /sbin/modprobe tg3; /sbin/modprobe e1000;
+        /sbin/modprobe --ignore-install bonding
+
+        This will, when loading the bonding module, rather than
+performing the normal action, instead execute the provided command.
+This command loads the device drivers in the order needed, then calls
+modprobe with --ingore-install to cause the normal action to then take
+place.  Full documentation on this can be found in the modprobe.conf
+and modprobe manual pages.
+
+9.3. Painfully Slow Or No Failed Link Detection By Miimon
+---------------------------------------------------------
+
+        By default, bonding enables the use_carrier option, which
+instructs bonding to trust the driver to maintain carrier state.
+
+        As discussed in the options section, above, some drivers do
+not support the netif_carrier_on/_off link state tracking system.
+With use_carrier enabled, bonding will always see these links as up,
+regardless of their actual state.
+
+        Additionally, other drivers do support netif_carrier, but do
+not maintain it in real time, e.g., only polling the link state at
+some fixed interval.  In this case, miimon will detect failures, but
+only after some long period of time has expired.  If it appears that
+miimon is very slow in detecting link failures, try specifying
+use_carrier=0 to see if that improves the failure detection time.  If
+it does, then it may be that the driver checks the carrier state at a
+fixed interval, but does not cache the MII register values (so the
+use_carrier=0 method of querying the registers directly works).  If
+use_carrier=0 does not improve the failover, then the driver may cache
+the registers, or the problem may be elsewhere.
+
+        Also, remember that miimon only checks for the device's
+carrier state.  It has no way to determine the state of devices on or
+beyond other ports of a switch, or if a switch is refusing to pass
+traffic while still maintaining carrier on.
+
+10. SNMP agents
+===============
+
+        If running SNMP agents, the bonding driver should be loaded
+before any network drivers participating in a bond.  This requirement
+is due to the the interface index (ipAdEntIfIndex) being associated to
+the first interface found with a given IP address.  That is, there is
+only one ipAdEntIfIndex for each IP address.  For example, if eth0 and
+eth1 are slaves of bond0 and the driver for eth0 is loaded before the
+bonding driver, the interface for the IP address will be associated
+with the eth0 interface.  This configuration is shown below, the IP
+address 192.168.1.1 has an interface index of 2 which indexes to eth0
+in the ifDescr table (ifDescr.2).
+
+     interfaces.ifTable.ifEntry.ifDescr.1 = lo
+     interfaces.ifTable.ifEntry.ifDescr.2 = eth0
+     interfaces.ifTable.ifEntry.ifDescr.3 = eth1
+     interfaces.ifTable.ifEntry.ifDescr.4 = eth2
+     interfaces.ifTable.ifEntry.ifDescr.5 = eth3
+     interfaces.ifTable.ifEntry.ifDescr.6 = bond0
+     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5
+     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
+     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4
+     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1
+
+        This problem is avoided by loading the bonding driver before
+any network drivers participating in a bond.  Below is an example of
+loading the bonding driver first, the IP address 192.168.1.1 is
+correctly associated with ifDescr.2.
+
+     interfaces.ifTable.ifEntry.ifDescr.1 = lo
+     interfaces.ifTable.ifEntry.ifDescr.2 = bond0
+     interfaces.ifTable.ifEntry.ifDescr.3 = eth0
+     interfaces.ifTable.ifEntry.ifDescr.4 = eth1
+     interfaces.ifTable.ifEntry.ifDescr.5 = eth2
+     interfaces.ifTable.ifEntry.ifDescr.6 = eth3
+     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6
+     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
+     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5
+     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1
+
+        While some distributions may not report the interface name in
+ifDescr, the association between the IP address and IfIndex remains
+and SNMP functions such as Interface_Scan_Next will report that
+association.
+
+11. Promiscuous mode
+====================
+
+        When running network monitoring tools, e.g., tcpdump, it is
+common to enable promiscuous mode on the device, so that all traffic
+is seen (instead of seeing only traffic destined for the local host).
+The bonding driver handles promiscuous mode changes to the bonding
+master device (e.g., bond0), and propogates the setting to the slave
+devices.
+
+        For the balance-rr, balance-xor, broadcast, and 802.3ad modes,
+the promiscuous mode setting is propogated to all slaves.
+
+        For the active-backup, balance-tlb and balance-alb modes, the
+promiscuous mode setting is propogated only to the active slave.
+
+        For balance-tlb mode, the active slave is the slave currently
+receiving inbound traffic.
+
+        For balance-alb mode, the active slave is the slave used as a
+"primary."  This slave is used for mode-specific control traffic, for
+sending to peers that are unassigned or if the load is unbalanced.
+
+        For the active-backup, balance-tlb and balance-alb modes, when
+the active slave changes (e.g., due to a link failure), the
+promiscuous setting will be propogated to the new active slave.
+
+12. High Availability Information
+=================================
+
+        High Availability refers to configurations that provide
+maximum network availability by having redundant or backup devices,
+links and switches between the host and the rest of the world.
+
+        There are currently two basic methods for configuring to
+maximize availability. They are dependent on the network topology and
+the primary goal of the configuration, but in general, a configuration
+can be optimized for maximum available bandwidth, or for maximum
+network availability.
+
+12.1 High Availability in a Single Switch Topology
+--------------------------------------------------
+
+        If two hosts (or a host and a switch) are directly connected
+via multiple physical links, then there is no network availability
+penalty for optimizing for maximum bandwidth: there is only one switch
+(or peer), so if it fails, you have no alternative access to fail over
+to.
+
+Example 1 : host to switch (or other host)
+
+          +----------+                          +----------+
+          |          |eth0                  eth0|  switch  |
+          | Host A   +--------------------------+    or    |
+          |          +--------------------------+  other   |
+          |          |eth1                  eth1|  host    |
+          +----------+                          +----------+
+
+
+12.1.1 Bonding Mode Selection for single switch topology
+--------------------------------------------------------
+
+        This configuration is the easiest to set up and to understand,
+although you will have to decide which bonding mode best suits your
+needs.  The tradeoffs for each mode are detailed below:
+
+balance-rr: This mode is the only mode that will permit a single
+        TCP/IP connection to stripe traffic across multiple
+        interfaces. It is therefore the only mode that will allow a
+        single TCP/IP stream to utilize more than one interface's
+        worth of throughput.  This comes at a cost, however: the
+        striping often results in peer systems receiving packets out
+        of order, causing TCP/IP's congestion control system to kick
+        in, often by retransmitting segments.
+
+        It is possible to adjust TCP/IP's congestion limits by
+        altering the net.ipv4.tcp_reordering sysctl parameter.  The
+        usual default value is 3, and the maximum useful value is 127.
+        For a four interface balance-rr bond, expect that a single
+        TCP/IP stream will utilize no more than approximately 2.3
+        interface's worth of throughput, even after adjusting
+        tcp_reordering.
+
+        If you are utilizing protocols other than TCP/IP, UDP for
+        example, and your application can tolerate out of order
+        delivery, then this mode can allow for single stream datagram
+        performance that scales near linearly as interfaces are added
+        to the bond.
+
+        This mode requires the switch to have the appropriate ports
+        configured for "etherchannel" or "trunking."
+
+active-backup: There is not much advantage in this network topology to
+        the active-backup mode, as the inactive backup devices are all
+        connected to the same peer as the primary.  In this case, a
+        load balancing mode (with link monitoring) will provide the
+        same level of network availability, but with increased
+        available bandwidth.  On the plus side, it does not require
+        any configuration of the switch.
+
+balance-xor: This mode will limit traffic such that packets destined
+        for specific peers will always be sent over the same
+        interface.  Since the destination is determined by the MAC
+        addresses involved, this may be desirable if you have a large
+        network with many hosts.  It is likely to be suboptimal if all
+        your traffic is passed through a single router, however.  As
+        with balance-rr, the switch ports need to be configured for
+        "etherchannel" or "trunking."
+
+broadcast: Like active-backup, there is not much advantage to this
+        mode in this type of network topology.
+
+802.3ad: This mode can be a good choice for this type of network
+        topology.  The 802.3ad mode is an IEEE standard, so all peers
+        that implement 802.3ad should interoperate well.  The 802.3ad
+        protocol includes automatic configuration of the aggregates,
+        so minimal manual configuration of the switch is needed
+        (typically only to designate that some set of devices is
+        usable for 802.3ad).  The 802.3ad standard also mandates that
+        frames be delivered in order (within certain limits), so in
+        general single connections will not see misordering of
+        packets.  The 802.3ad mode does have some drawbacks: the
+        standard mandates that all devices in the aggregate operate at
+        the same speed and duplex.  Also, as with all bonding load
+        balance modes other than balance-rr, no single connection will
+        be able to utilize more than a single interface's worth of
+        bandwidth.  Additionally, the linux bonding 802.3ad
+        implementation distributes traffic by peer (using an XOR of
+        MAC addresses), so in general all traffic to a particular
+        destination will use the same interface.  Finally, the 802.3ad
+        mode mandates the use of the MII monitor, therefore, the ARP
+        monitor is not available in this mode.
+
+balance-tlb: This mode is also a good choice for this type of
+        topology.  It has no special switch configuration
+        requirements, and balances outgoing traffic by peer, in a
+        vaguely intelligent manner (not a simple XOR as in balance-xor
+        or 802.3ad mode), so that unlucky MAC addresses will not all
+        "bunch up" on a single interface.  Interfaces may be of
+        differing speeds.  On the down side, in this mode all incoming
+        traffic arrives over a single interface, this mode requires
+        certain ethtool support in the network device driver of the
+        slave interfaces, and the ARP monitor is not available.
+
+balance-alb: This mode is everything that balance-tlb is, and more. It
+        has all of the features (and restrictions) of balance-tlb, and
+        will also balance incoming traffic from peers (as described in
+        the Bonding Module Options section, above).  The only extra
+        down side to this mode is that the network device driver must
+        support changing the hardware address while the device is
+        open.
+
+12.1.2 Link Monitoring for Single Switch Topology
+-------------------------------------------------
+
+        The choice of link monitoring may largely depend upon which
+mode you choose to use.  The more advanced load balancing modes do not
+support the use of the ARP monitor, and are thus restricted to using
+the MII monitor (which does not provide as high a level of assurance
+as the ARP monitor).
+
+
+12.2 High Availability in a Multiple Switch Topology
+----------------------------------------------------
+
+        With multiple switches, the configuration of bonding and the
+network changes dramatically.  In multiple switch topologies, there is
+a tradeoff between network availability and usable bandwidth.
+
+        Below is a sample network, configured to maximize the
+availability of the network:
+
+                |                                     |
+                |port3                           port3|
+          +-----+----+                          +-----+----+
+          |          |port2       ISL      port2|          |
+          | switch A +--------------------------+ switch B |
+          |          |                          |          |
+          +-----+----+                          +-----++---+
+                |port1                           port1|
+                |             +-------+               |
+                +-------------+ host1 +---------------+
+                         eth0 +-------+ eth1
+
+        In this configuration, there is a link between the two
+switches (ISL, or inter switch link), and multiple ports connecting to
+the outside world ("port3" on each switch).  There is no technical
+reason that this could not be extended to a third switch.
+
+12.2.1 Bonding Mode Selection for Multiple Switch Topology
+----------------------------------------------------------
+
+        In a topology such as this, the active-backup and broadcast
+modes are the only useful bonding modes; the other modes require all
+links to terminate on the same peer for them to behave rationally.
+
+active-backup: This is generally the preferred mode, particularly if
+        the switches have an ISL and play together well.  If the
+        network configuration is such that one switch is specifically
+        a backup switch (e.g., has lower capacity, higher cost, etc),
+        then the primary option can be used to insure that the
+        preferred link is always used when it is available.
+
+broadcast: This mode is really a special purpose mode, and is suitable
+        only for very specific needs.  For example, if the two
+        switches are not connected (no ISL), and the networks beyond
+        them are totally independant.  In this case, if it is
+        necessary for some specific one-way traffic to reach both
+        independent networks, then the broadcast mode may be suitable.
+
+12.2.2 Link Monitoring Selection for Multiple Switch Topology
+-------------------------------------------------------------
+
+        The choice of link monitoring ultimately depends upon your
+switch.  If the switch can reliably fail ports in response to other
+failures, then either the MII or ARP monitors should work.  For
+example, in the above example, if the "port3" link fails at the remote
+end, the MII monitor has no direct means to detect this.  The ARP
+monitor could be configured with a target at the remote end of port3,
+thus detecting that failure without switch support.
+
+        In general, however, in a multiple switch topology, the ARP
+monitor can provide a higher level of reliability in detecting link
+failures.  Additionally, it should be configured with multiple targets
+(at least one for each switch in the network).  This will insure that,
+regardless of which switch is active, the ARP monitor has a suitable
+target to query.
+
+
+12.3 Switch Behavior Issues for High Availability
+-------------------------------------------------
+
+        You may encounter issues with the timing of link up and down
+reporting by the switch.
+
+        First, when a link comes up, some switches may indicate that
+the link is up (carrier available), but not pass traffic over the
+interface for some period of time.  This delay is typically due to
+some type of autonegotiation or routing protocol, but may also occur
+during switch initialization (e.g., during recovery after a switch
+failure).  If you find this to be a problem, specify an appropriate
+value to the updelay bonding module option to delay the use of the
+relevant interface(s).
+
+        Second, some switches may "bounce" the link state one or more
+times while a link is changing state.  This occurs most commonly while
+the switch is initializing.  Again, an appropriate updelay value may
+help, but note that if all links are down, then updelay is ignored
+when any link becomes active (the slave closest to completing its
+updelay is chosen).
+
+        Note that when a bonding interface has no active links, the
+driver will immediately reuse the first link that goes up, even if
+updelay parameter was specified.  If there are slave interfaces
+waiting for the updelay timeout to expire, the interface that first
+went into that state will be immediately reused.  This reduces down
+time of the network if the value of updelay has been overestimated.
+
+        In addition to the concerns about switch timings, if your
+switches take a long time to go into backup mode, it may be desirable
+to not activate a backup interface immediately after a link goes down.
+Failover may be delayed via the downdelay bonding module option.
+
+13. Hardware Specific Considerations
+====================================
+
+        This section contains additional information for configuring
+bonding on specific hardware platforms, or for interfacing bonding
+with particular switches or other devices.
+
+13.1 IBM BladeCenter
+--------------------
+
+        This applies to the JS20 and similar systems.
+
+        On the JS20 blades, the bonding driver supports only
+balance-rr, active-backup, balance-tlb and balance-alb modes.  This is
+largely due to the network topology inside the BladeCenter, detailed
+below.
+
+JS20 network adapter information
+--------------------------------
+
+        All JS20s come with two Broadcom Gigabit Ethernet ports
+integrated on the planar.  In the BladeCenter chassis, the eth0 port
+of all JS20 blades is hard wired to I/O Module #1; similarly, all eth1
+ports are wired to I/O Module #2.  An add-on Broadcom daughter card
+can be installed on a JS20 to provide two more Gigabit Ethernet ports.
+These ports, eth2 and eth3, are wired to I/O Modules 3 and 4,
+respectively.
+
+        Each I/O Module may contain either a switch or a passthrough
+module (which allows ports to be directly connected to an external
+switch).  Some bonding modes require a specific BladeCenter internal
+network topology in order to function; these are detailed below.
+
+        Additional BladeCenter-specific networking information can be
+found in two IBM Redbooks (www.ibm.com/redbooks):
+
+"IBM eServer BladeCenter Networking Options"
+"IBM eServer BladeCenter Layer 2-7 Network Switching"
+
+BladeCenter networking configuration
+------------------------------------
+
+        Because a BladeCenter can be configured in a very large number
+of ways, this discussion will be confined to describing basic
+configurations.
+
+        Normally, Ethernet Switch Modules (ESM) are used in I/O
+modules 1 and 2.  In this configuration, the eth0 and eth1 ports of a
+JS20 will be connected to different internal switches (in the
+respective I/O modules).
+
+        An optical passthru module (OPM) connects the I/O module
+directly to an external switch.  By using OPMs in I/O module #1 and
+#2, the eth0 and eth1 interfaces of a JS20 can be redirected to the
+outside world and connected to a common external switch.
+
+        Depending upon the mix of ESM and OPM modules, the network
+will appear to bonding as either a single switch topology (all OPM
+modules) or as a multiple switch topology (one or more ESM modules,
+zero or more OPM modules).  It is also possible to connect ESM modules
+together, resulting in a configuration much like the example in "High
+Availability in a multiple switch topology."
+
+Requirements for specifc modes
+------------------------------
+
+        The balance-rr mode requires the use of OPM modules for
+devices in the bond, all connected to an common external switch.  That
+switch must be configured for "etherchannel" or "trunking" on the
+appropriate ports, as is usual for balance-rr.
+
+        The balance-alb and balance-tlb modes will function with
+either switch modules or passthrough modules (or a mix).  The only
+specific requirement for these modes is that all network interfaces
+must be able to reach all destinations for traffic sent over the
+bonding device (i.e., the network must converge at some point outside
+the BladeCenter).
+
+        The active-backup mode has no additional requirements.
+
+Link monitoring issues
+----------------------
+
+        When an Ethernet Switch Module is in place, only the ARP
+monitor will reliably detect link loss to an external switch.  This is
+nothing unusual, but examination of the BladeCenter cabinet would
+suggest that the "external" network ports are the ethernet ports for
+the system, when it fact there is a switch between these "external"
+ports and the devices on the JS20 system itself.  The MII monitor is
+only able to detect link failures between the ESM and the JS20 system.
+
+        When a passthrough module is in place, the MII monitor does
+detect failures to the "external" port, which is then directly
+connected to the JS20 system.
+
+Other concerns
+--------------
+
+        The Serial Over LAN link is established over the primary
+ethernet (eth0) only, therefore, any loss of link to eth0 will result
+in losing your SoL connection.  It will not fail over with other
+network traffic.
+
+        It may be desirable to disable spanning tree on the switch
+(either the internal Ethernet Switch Module, or an external switch) to
+avoid fail-over delays issues when using bonding.
+
+        
+14. Frequently Asked Questions
+==============================
+
+1.  Is it SMP safe?
+
+        Yes. The old 2.0.xx channel bonding patch was not SMP safe.
+The new driver was designed to be SMP safe from the start.
+
+2.  What type of cards will work with it?
+
+        Any Ethernet type cards (you can even mix cards - a Intel
+EtherExpress PRO/100 and a 3com 3c905b, for example).  They need not
+be of the same speed.
+
+3.  How many bonding devices can I have?
+
+        There is no limit.
+
+4.  How many slaves can a bonding device have?
+
+        This is limited only by the number of network interfaces Linux
+supports and/or the number of network cards you can place in your
+system.
+
+5.  What happens when a slave link dies?
+
+        If link monitoring is enabled, then the failing device will be
+disabled.  The active-backup mode will fail over to a backup link, and
+other modes will ignore the failed link.  The link will continue to be
+monitored, and should it recover, it will rejoin the bond (in whatever
+manner is appropriate for the mode). See the section on High
+Availability for additional information.
+        
+        Link monitoring can be enabled via either the miimon or
+arp_interval paramters (described in the module paramters section,
+above).  In general, miimon monitors the carrier state as sensed by
+the underlying network device, and the arp monitor (arp_interval)
+monitors connectivity to another host on the local network.
+
+        If no link monitoring is configured, the bonding driver will
+be unable to detect link failures, and will assume that all links are
+always available.  This will likely result in lost packets, and a
+resulting degredation of performance.  The precise performance loss
+depends upon the bonding mode and network configuration.
+
+6.  Can bonding be used for High Availability?
+
+        Yes.  See the section on High Availability for details.
+
+7.  Which switches/systems does it work with?
+
+        The full answer to this depends upon the desired mode.
+
+        In the basic balance modes (balance-rr and balance-xor), it
+works with any system that supports etherchannel (also called
+trunking).  Most managed switches currently available have such
+support, and many unmananged switches as well.
+
+        The advanced balance modes (balance-tlb and balance-alb) do
+not have special switch requirements, but do need device drivers that
+support specific features (described in the appropriate section under
+module paramters, above).
+
+        In 802.3ad mode, it works with with systems that support IEEE
+802.3ad Dynamic Link Aggregation.  Most managed and many unmanaged
+switches currently available support 802.3ad.
+
+        The active-backup mode should work with any Layer-II switch.
+
+8.  Where does a bonding device get its MAC address from?
+
+        If not explicitly configured with ifconfig, the MAC address of
+the bonding device is taken from its first slave device. This MAC
+address is then passed to all following slaves and remains persistent
+(even if the the first slave is removed) until the bonding device is
+brought down or reconfigured.
+
+        If you wish to change the MAC address, you can set it with
+ifconfig:
+
+# ifconfig bond0 hw ether 00:11:22:33:44:55
+
+        The MAC address can be also changed by bringing down/up the
+device and then changing its slaves (or their order):
+
+# ifconfig bond0 down ; modprobe -r bonding
+# ifconfig bond0 .... up
+# ifenslave bond0 eth...
+
+        This method will automatically take the address from the next
+slave that is added.
+
+        To restore your slaves' MAC addresses, you need to detach them
+from the bond (`ifenslave -d bond0 eth0'). The bonding driver will
+then restore the MAC addresses that the slaves had before they were
+enslaved.
+
+15. Resources and Links
+=======================
+
+The latest version of the bonding driver can be found in the latest
+version of the linux kernel, found on http://kernel.org
+
+Discussions regarding the bonding driver take place primarily on the
+bonding-devel mailing list, hosted at sourceforge.net.  If you have
+questions or problems, post them to the list.
+
+bonding-devel@lists.sourceforge.net
+
+https://lists.sourceforge.net/lists/listinfo/bonding-devel
+
+There is also a project site on sourceforge.
+
+http://www.sourceforge.net/projects/bonding
+
+Donald Becker's Ethernet Drivers and diag programs may be found at :
+ - http://www.scyld.com/network/
+
+You will also find a lot of information regarding Ethernet, NWay, MII,
+etc. at www.scyld.com.
+
+-- END --
diff --git a/Documentation/networking/bridge.txt b/Documentation/networking/bridge.txt
new file mode 100644
index 00000000000..bdae2db4119
--- /dev/null
+++ b/Documentation/networking/bridge.txt
@@ -0,0 +1,8 @@
+In order to use the Ethernet bridging functionality, you'll need the
+userspace tools. These programs and documentation are available
+at http://bridge.sourceforge.net.  The download page is
+http://prdownloads.sourceforge.net/bridge.
+
+If you still have questions, don't hesitate to post to the mailing list 
+(more info http://lists.osdl.org/mailman/listinfo/bridge).
+
diff --git a/Documentation/networking/comx.txt b/Documentation/networking/comx.txt
new file mode 100644
index 00000000000..d1526eba264
--- /dev/null
+++ b/Documentation/networking/comx.txt
@@ -0,0 +1,248 @@
+
+                COMX drivers for the 2.2 kernel
+
+Originally written by: Tivadar Szemethy, <tiv@itc.hu>
+Currently maintained by: Gergely Madarasz <gorgo@itc.hu>
+
+Last change: 21/06/1999.
+
+INTRODUCTION
+
+This document describes the software drivers and their use for the 
+COMX line of synchronous serial adapters for Linux version 2.2.0 and
+above.
+The cards are produced and sold by ITC-Pro Ltd. Budapest, Hungary
+For further info contact <info@itc.hu> 
+or http://www.itc.hu (mostly in Hungarian).
+The firmware files and software are available from ftp://ftp.itc.hu
+
+Currently, the drivers support the following cards and protocols:
+
+COMX (2x64 kbps intelligent board)
+CMX (1x256 + 1x128 kbps intelligent board)
+HiCOMX (2x2Mbps intelligent board)
+LoCOMX (1x512 kbps passive board)
+MixCOM (1x512 or 2x512kbps passive board with a hardware watchdog an
+        optional BRI interface and optional flashROM (1-32M))
+SliceCOM        (1x2Mbps channelized E1 board)
+PciCOM  (X21)
+
+At the moment of writing this document, the (Cisco)-HDLC, LAPB, SyncPPP and
+Frame Relay (DTE, rfc1294 IP encapsulation with partially implemented Q933a 
+LMI) protocols are available as link-level protocol. 
+X.25 support is being worked on.
+
+USAGE
+
+Load the comx.o module and the hardware-specific and protocol-specific 
+modules you'll need into the running kernel using the insmod utility.
+This creates the /proc/comx directory.
+See the example scripts in the 'etc' directory.
+
+/proc INTERFACE INTRO
+
+The COMX driver set has a new type of user interface based on the /proc 
+filesystem which eliminates the need for external user-land software doing 
+IOCTL calls. 
+Each network interface or device (i.e. those ones you configure with 'ifconfig'
+and 'route' etc.) has a corresponding directory under /proc/comx. You can
+dynamically create a new interface by saying 'mkdir /proc/comx/comx0' (or you
+can name it whatever you want up to 8 characters long, comx[n] is just a 
+convention).
+Generally the files contained in these directories are text files, which can
+be viewed by 'cat filename' and you can write a string to such a file by
+saying 'echo _string_ >filename'. This is very similar to the sysctl interface.
+Don't use a text editor to edit these files, always use 'echo' (or 'cat'
+where appropriate).
+When you've created the comx[n] directory, two files are created automagically
+in it: 'boardtype' and 'protocol'. You have to fill in these files correctly
+for your board and protocol you intend to use (see the board and protocol 
+descriptions in this file below or the example scripts in the 'etc' directory).
+After filling in these files, other files will appear in the directory for 
+setting the various hardware- and protocol-related informations (for example
+irq and io addresses, keepalive values etc.) These files are set to default 
+values upon creation, so you don't necessarily have to change all of them.
+
+When you're ready with filling in the files in the comx[n] directory, you can
+configure the corresponding network interface with the standard network 
+configuration utilities. If you're unable to bring the interfaces up, look up
+the various kernel log files on your system, and consult the messages for
+a probable reason.
+
+EXAMPLE
+
+To create the interface 'comx0' which is the first channel of a COMX card:
+
+insmod comx 
+# insmod comx-hw-comx ; insmod comx-proto-ppp  (these are usually
+autoloaded if you use the kernel module loader)
+
+mkdir /proc/comx/comx0
+echo comx >/proc/comx/comx0/boardtype
+echo 0x360 >/proc/comx/comx0/io         <- jumper-selectable I/O port 
+echo 0x0a >/proc/comx/comx0/irq         <- jumper-selectable IRQ line
+echo 0xd000 >/proc/comx/comx0/memaddr   <- software-configurable memory
+                                           address. COMX uses 64 KB, and this
+                                           can be: 0xa000, 0xb000, 0xc000, 
+                                           0xd000, 0xe000. Avoid conflicts
+                                           with other hardware.
+cat </etc/siol1.rom >/proc/comx/comx0/firmware <- the firmware for the card
+echo HDLC >/proc/comx/comx0/protocol    <- the data-link protocol
+echo 10 >/proc/comx/comx0/keepalive     <- the keepalive for the protocol
+ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255 <-
+                                           finally configure it with ifconfig
+Check its status:
+cat /proc/comx/comx0/status
+
+If you want to use the second channel of this board:
+
+mkdir /proc/comx/comx1
+echo comx >/proc/comx/comx1/boardtype
+echo 0x360 >/proc/comx/comx1/io 
+echo 10 >/proc/comx/comx1/irq           
+echo 0xd000 >/proc/comx/comx1/memaddr
+echo 1 >/proc/comx/comx1/channel        <- channels are numbered 
+                                           as 0 (default) and 1
+
+Now, check if the driver recognized that you're going to use the other
+channel of the same adapter:
+
+cat /proc/comx/comx0/twin
+comx1
+cat /proc/comx/comx1/twin
+comx0
+
+You don't have to load the firmware twice, if you use both channels of
+an adapter, just write it into the channel 0's /proc firmware file.
+
+Default values: io 0x360 for COMX, 0x320 (HICOMX), irq 10, memaddr 0xd0000
+
+THE LOCOMX HARDWARE DRIVER
+
+The LoCOMX driver doesn't require firmware, and it doesn't use memory either,
+but it uses DMA channels 1 and 3. You can set the clock rate (if enabled by
+jumpers on the board) by writing the kbps value into the file named 'clock'.
+Set it to 'external' (it is the default) if you have external clock source.
+
+(Note: currently the LoCOMX driver does not support the internal clock)
+
+THE COMX, CMX AND HICOMX DRIVERS
+
+On the HICOMX, COMX and CMX, you have to load the firmware (it is different for
+the three cards!). All these adapters can share the same memory
+address (we usually use 0xd0000). On the CMX you can set the internal
+clock rate (if enabled by jumpers on the small adapter boards) by writing
+the kbps value into the 'clock' file. You have to do this before initializing
+the card. If you use both HICOMX and CMX/COMX cards, initialize the HICOMX
+first. The I/O address of the HICOMX board is not configurable by any
+method available to the user: it is hardwired to 0x320, and if you have to 
+change it, consult ITC-Pro Ltd.
+
+THE MIXCOM DRIVER
+
+The MixCOM board doesn't require firmware, the driver communicates with
+it through I/O ports. You can have three of these cards in one machine.
+
+THE SLICECOM DRIVER
+
+The SliceCOM board doesn't require firmware. You can have 4 of these cards
+in one machine. The driver doesn't (yet) support shared interrupts, so
+you will need a separate IRQ line for every board.
+Read Documentation/networking/slicecom.txt for help on configuring
+this adapter.
+
+THE HDLC/PPP LINE PROTOCOL DRIVER
+
+The HDLC/SyncPPP line protocol driver uses the kernel's built-in syncppp
+driver (syncppp.o). You don't have to manually select syncppp.o when building
+the kernel, the dependencies compile it in automatically.
+
+
+
+
+EXAMPLE
+(setting up hw parameters, see above)
+
+# using HDLC:
+echo hdlc >/proc/comx/comx0/protocol
+echo 10 >/proc/comx/comx0/keepalive     <- not necessary, 10 is the default
+ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
+
+(setting up hw parameters, see above)
+
+# using PPP:
+echo ppp >/proc/comx/comx0/protocol
+ifconfig comx0 up
+ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
+
+
+THE LAPB LINE PROTOCOL DRIVER
+
+For this, you'll need to configure LAPB support (See 'LAPB Data Link Driver' in
+'Network options' section) into your kernel (thanks to Jonathan Naylor for his 
+excellent implementation). 
+comx-proto-lapb.o provides the following files in the appropriate directory
+(the default values in parens): t1 (5), t2 (1), n2 (20), mode (DTE, STD) and
+window (7). Agree with the administrator of your peer router on these
+settings (most people use defaults, but you have to know if you are DTE or
+DCE).
+
+EXAMPLE
+
+(setting up hw parameters, see above)
+echo lapb >/proc/comx/comx0/protocol
+echo dce >/proc/comx/comx0/mode         <- DCE interface in this example
+ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
+
+
+THE FRAME RELAY PROTOCOL DRIVER
+
+You DON'T need any other frame relay related modules from the kernel to use
+COMX-Frame Relay. This protocol is a bit more complicated than the others, 
+because it allows to use 'subinterfaces' or DLCIs within one physical device.
+First you have to create the 'master' device (the actual physical interface)
+as you would do for other protocols. Specify 'frad' as protocol type.
+Now you can bring this interface up by saying 'ifconfig comx0 up' (or whatever
+you've named the interface). Do not assign any IP address to this interface
+and do not set any routes through it.
+Then, set up your DLCIs the following way: create a comx interface for each
+DLCI you intend to use (with mkdir), and write 'dlci' to the 'boardtype' file, 
+and 'ietf-ip' to the 'protocol' file. Currently, the only supported 
+encapsulation type is this (also called as RFC1294/1490 IP encapsulation).
+Write the DLCI number to the 'dlci' file, and write the name of the physical
+COMX device to the file called 'master'. 
+Now you can assign an IP address to this interface and set routes using it.
+See the example file for further info and example config script.
+Notes: this driver implements a DTE interface with partially implemented
+Q933a LMI.
+You can find an extensively commented example in the 'etc' directory.
+
+FURTHER /proc FILES
+
+boardtype:
+Type of the hardware. Valid values are:
+ 'comx', 'hicomx', 'locomx', 'cmx', 'slicecom'.
+
+protocol:
+Data-link protocol on this channel. Can be: HDLC, LAPB, PPP, FRAD
+
+status:
+You can read the channel's actual status from the 'status' file, for example
+'cat /proc/comx/comx3/status'.
+
+lineup_delay:
+Interpreted in seconds (default is 1). Used to avoid line jitter: the system
+will consider the line status 'UP' only if it is up for at least this number
+of seconds.
+
+debug: 
+You can set various debug options through this file. Valid options are:
+'comx_events', 'comx_tx', 'comx_rx', 'hw_events', 'hw_tx', 'hw_rx'.
+You can enable a debug options by writing its name prepended by a '+' into
+the debug file, for example 'echo +comx_rx >comx0/debug'. 
+Disabling an option happens similarly, use the '-' prefix 
+(e.g. 'echo -hw_rx >debug').
+Debug results can be read from the debug file, for example: 
+tail -f /proc/comx/comx2/debug
+
+
diff --git a/Documentation/networking/cops.txt b/Documentation/networking/cops.txt
new file mode 100644
index 00000000000..3e344b448e0
--- /dev/null
+++ b/Documentation/networking/cops.txt
@@ -0,0 +1,63 @@
+Text File for the COPS LocalTalk Linux driver (cops.c).
+        By Jay Schulist <jschlst@samba.org>
+
+This driver has two modes and they are: Dayna mode and Tangent mode.
+Each mode corresponds with the type of card. It has been found
+that there are 2 main types of cards and all other cards are
+the same and just have different names or only have minor differences
+such as more IO ports. As this driver is tested it will
+become more clear exactly what cards are supported. 
+
+Right now these cards are known to work with the COPS driver. The
+LT-200 cards work in a somewhat more limited capacity than the
+DL200 cards, which work very well and are in use by many people.
+
+TANGENT driver mode:
+        Tangent ATB-II, Novell NL-1000, Daystar Digital LT-200
+DAYNA driver mode:
+        Dayna DL2000/DaynaTalk PC (Half Length), COPS LT-95,
+        Farallon PhoneNET PC III, Farallon PhoneNET PC II
+Other cards possibly supported mode unknown though:
+        Dayna DL2000 (Full length)
+
+The COPS driver defaults to using Dayna mode. To change the driver's 
+mode if you built a driver with dual support use board_type=1 or
+board_type=2 for Dayna or Tangent with insmod.
+
+** Operation/loading of the driver.
+Use modprobe like this: /sbin/modprobe cops.o (IO #) (IRQ #)
+If you do not specify any options the driver will try and use the IO = 0x240,
+IRQ = 5. As of right now I would only use IRQ 5 for the card, if autoprobing.
+
+To load multiple COPS driver Localtalk cards you can do one of the following.
+
+insmod cops io=0x240 irq=5
+insmod -o cops2 cops io=0x260 irq=3
+
+Or in lilo.conf put something like this:
+        append="ether=5,0x240,lt0 ether=3,0x260,lt1"
+
+Then bring up the interface with ifconfig. It will look something like this:
+lt0       Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-F7-00-00-00-00-00-00-00-00
+          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
+          UP BROADCAST RUNNING NOARP MULTICAST  MTU:600  Metric:1
+          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0
+
+** Netatalk Configuration
+You will need to configure atalkd with something like the following to make
+it work with the cops.c driver.
+
+* For single LTalk card use.
+dummy -seed -phase 2 -net 2000 -addr 2000.10 -zone "1033"
+lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033"
+
+* For multiple cards, Ethernet and LocalTalk.
+eth0 -seed -phase 2 -net 3000 -addr 3000.20 -zone "1033"
+lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033"
+
+* For multiple LocalTalk cards, and an Ethernet card.
+* Order seems to matter here, Ethernet last.
+lt0 -seed -phase 1 -net 1000 -addr 1000.10 -zone "LocalTalk1"
+lt1 -seed -phase 1 -net 2000 -addr 2000.20 -zone "LocalTalk2"
+eth0 -seed -phase 2 -net 3000 -addr 3000.30 -zone "EtherTalk"
diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt
new file mode 100644
index 00000000000..188beb7d6a1
--- /dev/null
+++ b/Documentation/networking/cs89x0.txt
@@ -0,0 +1,703 @@
+
+NOTE
+----
+
+This document was contributed by Cirrus Logic for kernel 2.2.5.  This version
+has been updated for 2.3.48 by Andrew Morton <andrewm@uow.edu.au>
+
+Cirrus make a copy of this driver available at their website, as
+described below.  In general, you should use the driver version which
+comes with your Linux distribution.
+
+
+
+CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
+Linux Network Interface Driver ver. 2.00 <kernel 2.3.48>
+===============================================================================
+ 
+
+TABLE OF CONTENTS
+
+1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
+    1.1 Product Overview 
+    1.2 Driver Description
+        1.2.1 Driver Name
+        1.2.2 File in the Driver Package
+    1.3 System Requirements
+    1.4 Licensing Information
+
+2.0 ADAPTER INSTALLATION and CONFIGURATION
+    2.1 CS8900-based Adapter Configuration
+    2.2 CS8920-based Adapter Configuration 
+
+3.0 LOADING THE DRIVER AS A MODULE
+
+4.0 COMPILING THE DRIVER
+    4.1 Compiling the Driver as a Loadable Module
+    4.2 Compiling the driver to support memory mode
+    4.3 Compiling the driver to support Rx DMA 
+    4.4 Compiling the Driver into the Kernel
+
+5.0 TESTING AND TROUBLESHOOTING
+    5.1 Known Defects and Limitations
+    5.2 Testing the Adapter
+        5.2.1 Diagnostic Self-Test
+        5.2.2 Diagnostic Network Test
+    5.3 Using the Adapter's LEDs
+    5.4 Resolving I/O Conflicts
+
+6.0 TECHNICAL SUPPORT
+    6.1 Contacting Cirrus Logic's Technical Support
+    6.2 Information Required Before Contacting Technical Support
+    6.3 Obtaining the Latest Driver Version
+    6.4 Current maintainer
+    6.5 Kernel boot parameters
+
+
+1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
+===============================================================================
+
+
+1.1 PRODUCT OVERVIEW
+
+The CS8900-based ISA Ethernet Adapters from Cirrus Logic follow 
+IEEE 802.3 standards and support half or full-duplex operation in ISA bus 
+computers on 10 Mbps Ethernet networks.  The adapters are designed for operation 
+in 16-bit ISA or EISA bus expansion slots and are available in 
+10BaseT-only or 3-media configurations (10BaseT, 10Base2, and AUI for 10Base-5 
+or fiber networks).  
+
+CS8920-based adapters are similar to the CS8900-based adapter with additional 
+features for Plug and Play (PnP) support and Wakeup Frame recognition.  As 
+such, the configuration procedures differ somewhat between the two types of 
+adapters.  Refer to the "Adapter Configuration" section for details on 
+configuring both types of adapters.
+
+
+1.2 DRIVER DESCRIPTION
+
+The CS8900/CS8920 Ethernet Adapter driver for Linux supports the Linux
+v2.3.48 or greater kernel.  It can be compiled directly into the kernel
+or loaded at run-time as a device driver module.
+
+1.2.1 Driver Name: cs89x0
+
+1.2.2 Files in the Driver Archive:
+
+The files in the driver at Cirrus' website include:
+
+  readme.txt         - this file
+  build              - batch file to compile cs89x0.c.
+  cs89x0.c           - driver C code
+  cs89x0.h           - driver header file
+  cs89x0.o           - pre-compiled module (for v2.2.5 kernel)
+  config/Config.in   - sample file to include cs89x0 driver in the kernel.
+  config/Makefile    - sample file to include cs89x0 driver in the kernel.
+  config/Space.c     - sample file to include cs89x0 driver in the kernel.
+
+
+
+1.3 SYSTEM REQUIREMENTS
+
+The following hardware is required:
+
+   * Cirrus Logic LAN (CS8900/20-based) Ethernet ISA Adapter   
+
+   * IBM or IBM-compatible PC with:
+     * An 80386 or higher processor
+     * 16 bytes of contiguous IO space available between 210h - 370h
+     * One available IRQ (5,10,11,or 12 for the CS8900, 3-7,9-15 for CS8920).
+
+   * Appropriate cable (and connector for AUI, 10BASE-2) for your network
+     topology.
+
+The following software is required:
+
+* LINUX kernel version 2.3.48 or higher
+
+   * CS8900/20 Setup Utility (DOS-based)
+
+   * LINUX kernel sources for your kernel (if compiling into kernel)
+
+   * GNU Toolkit (gcc and make) v2.6 or above (if compiling into kernel 
+     or a module)   
+
+
+
+1.4 LICENSING INFORMATION
+
+This program is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free Software
+Foundation, version 1.
+
+This program is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for 
+more details.
+
+For a full copy of the GNU General Public License, write to the Free Software
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+
+
+2.0 ADAPTER INSTALLATION and CONFIGURATION
+===============================================================================
+
+Both the CS8900 and CS8920-based adapters can be configured using parameters 
+stored in an on-board EEPROM. You must use the DOS-based CS8900/20 Setup 
+Utility if you want to change the adapter's configuration in EEPROM.  
+
+When loading the driver as a module, you can specify many of the adapter's 
+configuration parameters on the command-line to override the EEPROM's settings 
+or for interface configuration when an EEPROM is not used. (CS8920-based 
+adapters must use an EEPROM.) See Section 3.0 LOADING THE DRIVER AS A MODULE.
+
+Since the CS8900/20 Setup Utility is a DOS-based application, you must install 
+and configure the adapter in a DOS-based system using the CS8900/20 Setup 
+Utility before installation in the target LINUX system.  (Not required if 
+installing a CS8900-based adapter and the default configuration is acceptable.)
+     
+
+2.1 CS8900-BASED ADAPTER CONFIGURATION
+
+CS8900-based adapters shipped from Cirrus Logic have been configured 
+with the following "default" settings:
+
+  Operation Mode:      Memory Mode
+  IRQ:                 10
+  Base I/O Address:    300
+  Memory Base Address: D0000
+  Optimization:        DOS Client
+  Transmission Mode:   Half-duplex
+  BootProm:            None
+  Media Type:          Autodetect (3-media cards) or 
+                       10BASE-T (10BASE-T only adapter)
+
+You should only change the default configuration settings if conflicts with 
+another adapter exists. To change the adapter's configuration, run the 
+CS8900/20 Setup Utility. 
+
+
+2.2 CS8920-BASED ADAPTER CONFIGURATION
+
+CS8920-based adapters are shipped from Cirrus Logic configured as Plug
+and Play (PnP) enabled.  However, since the cs89x0 driver does NOT
+support PnP, you must install the CS8920 adapter in a DOS-based PC and
+run the CS8900/20 Setup Utility to disable PnP and configure the
+adapter before installation in the target Linux system.  Failure to do
+this will leave the adapter inactive and the driver will be unable to
+communicate with the adapter.  
+
+
+        **************************************************************** 
+        *                    CS8920-BASED ADAPTERS:                    *
+        *                                                              * 
+        * CS8920-BASED ADAPTERS ARE PLUG and PLAY ENABLED BY DEFAULT.  * 
+        * THE CS89X0 DRIVER DOES NOT SUPPORT PnP. THEREFORE, YOU MUST  *
+        * RUN THE CS8900/20 SETUP UTILITY TO DISABLE PnP SUPPORT AND   *
+        * TO ACTIVATE THE ADAPTER.                                     *
+        ****************************************************************
+
+
+
+
+3.0 LOADING THE DRIVER AS A MODULE
+===============================================================================
+
+If the driver is compiled as a loadable module, you can load the driver module
+with the 'modprobe' command.  Many of the adapter's configuration parameters can 
+be specified as command-line arguments to the load command.  This facility 
+provides a means to override the EEPROM's settings or for interface 
+configuration when an EEPROM is not used.
+
+Example:
+
+    insmod cs89x0.o io=0x200 irq=0xA media=aui
+
+This example loads the module and configures the adapter to use an IO port base
+address of 200h, interrupt 10, and use the AUI media connection.  The following
+configuration options are available on the command line:
+
+* io=###               - specify IO address (200h-360h)
+* irq=##               - specify interrupt level
+* use_dma=1            - Enable DMA
+* dma=#                - specify dma channel (Driver is compiled to support
+                         Rx DMA only)
+* dmasize=# (16 or 64) - DMA size 16K or 64K.  Default value is set to 16.
+* media=rj45           - specify media type
+   or media=bnc
+   or media=aui
+   or medai=auto
+* duplex=full          - specify forced half/full/autonegotiate duplex
+   or duplex=half
+   or duplex=auto
+* debug=#              - debug level (only available if the driver was compiled
+                         for debugging)
+
+NOTES:
+
+a) If an EEPROM is present, any specified command-line parameter
+   will override the corresponding configuration value stored in
+   EEPROM.
+
+b) The "io" parameter must be specified on the command-line.  
+
+c) The driver's hardware probe routine is designed to avoid
+   writing to I/O space until it knows that there is a cs89x0
+   card at the written addresses.  This could cause problems
+   with device probing.  To avoid this behaviour, add one
+   to the `io=' module parameter.  This doesn't actually change
+   the I/O address, but it is a flag to tell the driver
+   topartially initialise the hardware before trying to
+   identify the card.  This could be dangerous if you are
+   not sure that there is a cs89x0 card at the provided address.
+
+   For example, to scan for an adapter located at IO base 0x300,
+   specify an IO address of 0x301.  
+
+d) The "duplex=auto" parameter is only supported for the CS8920.
+
+e) The minimum command-line configuration required if an EEPROM is
+   not present is:
+
+   io 
+   irq 
+   media type (no autodetect)
+
+f) The following additional parameters are CS89XX defaults (values
+   used with no EEPROM or command-line argument).
+
+   * DMA Burst = enabled
+   * IOCHRDY Enabled = enabled
+   * UseSA = enabled
+   * CS8900 defaults to half-duplex if not specified on command-line
+   * CS8920 defaults to autoneg if not specified on command-line
+   * Use reset defaults for other config parameters
+   * dma_mode = 0
+
+g) You can use ifconfig to set the adapter's Ethernet address.
+
+h) Many Linux distributions use the 'modprobe' command to load
+   modules.  This program uses the '/etc/conf.modules' file to
+   determine configuration information which is passed to a driver
+   module when it is loaded.  All the configuration options which are
+   described above may be placed within /etc/conf.modules.
+
+   For example:
+
+   > cat /etc/conf.modules
+   ...
+   alias eth0 cs89x0
+   options cs89x0 io=0x0200 dma=5 use_dma=1
+   ...
+
+   In this example we are telling the module system that the
+   ethernet driver for this machine should use the cs89x0 driver.  We
+   are asking 'modprobe' to pass the 'io', 'dma' and 'use_dma'
+   arguments to the driver when it is loaded.
+
+i) Cirrus recommend that the cs89x0 use the ISA DMA channels 5, 6 or
+   7.  You will probably find that other DMA channels will not work.
+
+j) The cs89x0 supports DMA for receiving only.  DMA mode is
+   significantly more efficient.  Flooding a 400 MHz Celeron machine
+   with large ping packets consumes 82% of its CPU capacity in non-DMA
+   mode.  With DMA this is reduced to 45%.
+
+k) If your Linux kernel was compiled with inbuilt plug-and-play
+   support you will be able to find information about the cs89x0 card
+   with the command
+
+   cat /proc/isapnp
+
+l) If during DMA operation you find erratic behavior or network data
+   corruption you should use your PC's BIOS to slow the EISA bus clock.
+
+m) If the cs89x0 driver is compiled directly into the kernel
+   (non-modular) then its I/O address is automatically determined by
+   ISA bus probing.  The IRQ number, media options, etc are determined
+   from the card's EEPROM.
+
+n) If the cs89x0 driver is compiled directly into the kernel, DMA
+   mode may be selected by providing the kernel with a boot option
+   'cs89x0_dma=N' where 'N' is the desired DMA channel number (5, 6 or 7).
+
+   Kernel boot options may be provided on the LILO command line:
+
+        LILO boot: linux cs89x0_dma=5
+
+   or they may be placed in /etc/lilo.conf:
+
+        image=/boot/bzImage-2.3.48
+          append="cs89x0_dma=5"
+          label=linux
+          root=/dev/hda5
+          read-only
+
+   The DMA Rx buffer size is hardwired to 16 kbytes in this mode.
+   (64k mode is not available).
+
+
+4.0 COMPILING THE DRIVER
+===============================================================================
+
+The cs89x0 driver can be compiled directly into the kernel or compiled into
+a loadable device driver module.
+
+
+4.1 COMPILING THE DRIVER AS A LOADABLE MODULE
+
+To compile the driver into a loadable module, use the following command 
+(single command line, without quotes):
+
+"gcc -D__KERNEL__ -I/usr/src/linux/include -I/usr/src/linux/net/inet -Wall 
+-Wstrict-prototypes -O2 -fomit-frame-pointer -DMODULE -DCONFIG_MODVERSIONS 
+-c cs89x0.c"
+
+4.2 COMPILING THE DRIVER TO SUPPORT MEMORY MODE
+
+Support for memory mode was not carried over into the 2.3 series kernels.
+
+4.3 COMPILING THE DRIVER TO SUPPORT Rx DMA
+
+The compile-time optionality for DMA was removed in the 2.3 kernel
+series.  DMA support is now unconditionally part of the driver.  It is
+enabled by the 'use_dma=1' module option.
+
+4.4 COMPILING THE DRIVER INTO THE KERNEL
+
+If your Linux distribution already has support for the cs89x0 driver
+then simply copy the source file to the /usr/src/linux/drivers/net
+directory to replace the original ones and run the make utility to
+rebuild the kernel.  See Step 3 for rebuilding the kernel.
+
+If your Linux does not include the cs89x0 driver, you need to edit three 
+configuration files, copy the source file to the /usr/src/linux/drivers/net
+directory, and then run the make utility to rebuild the kernel.
+
+1. Edit the following configuration files by adding the statements as
+indicated.  (When possible, try to locate the added text to the section of the
+file containing similar statements).
+
+
+a.) In /usr/src/linux/drivers/net/Config.in, add:
+
+tristate 'CS89x0 support' CONFIG_CS89x0
+
+Example:
+
+     if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+       tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
+     fi
+
+     tristate 'CS89x0 support' CONFIG_CS89x0
+
+     tristate 'NE2000/NE1000 support' CONFIG_NE2000
+     if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+       tristate 'NI5210 support' CONFIG_NI52
+
+
+b.) In /usr/src/linux/drivers/net/Makefile, add the following lines: 
+
+ifeq ($(CONFIG_CS89x0),y)
+L_OBJS += cs89x0.o
+else
+  ifeq ($(CONFIG_CS89x0),m)
+  M_OBJS += cs89x0.o
+  endif
+endif
+
+
+c.) In /linux/drivers/net/Space.c file, add the line:
+
+extern int cs89x0_probe(struct device *dev);
+
+
+Example:
+
+ extern int ultra_probe(struct device *dev);
+ extern int wd_probe(struct device *dev);
+ extern int el2_probe(struct device *dev);
+
+ extern int cs89x0_probe(struct device *dev);
+
+ extern int ne_probe(struct device *dev);
+ extern int hp_probe(struct device *dev);
+ extern int hp_plus_probe(struct device *dev);
+
+
+Also add:
+
+ #ifdef CONFIG_CS89x0
+        { cs89x0_probe,0 },
+ #endif
+
+
+2.) Copy the driver source files (cs89x0.c and cs89x0.h) 
+into the /usr/src/linux/drivers/net directory.
+
+
+3.) Go to /usr/src/linux directory and run 'make config' followed by 'make' 
+(or make bzImage) to rebuild the kernel. 
+
+4.) Use the DOS 'setup' utility to disable plug and play on the NIC.
+
+
+5.0 TESTING AND TROUBLESHOOTING
+===============================================================================
+
+5.1 KNOWN DEFECTS and LIMITATIONS
+
+Refer to the RELEASE.TXT file distributed as part of this archive for a list of 
+known defects, driver limitations, and work arounds.
+
+
+5.2 TESTING THE ADAPTER
+
+Once the adapter has been installed and configured, the diagnostic option of 
+the CS8900/20 Setup Utility can be used to test the functionality of the 
+adapter and its network connection.  Use the diagnostics 'Self Test' option to
+test the functionality of the adapter with the hardware configuration you have
+assigned. You can use the diagnostics 'Network Test' to test the ability of the
+adapter to communicate across the Ethernet with another PC equipped with a 
+CS8900/20-based adapter card (it must also be running the CS8900/20 Setup 
+Utility).
+
+         NOTE: The Setup Utility's diagnostics are designed to run in a
+         DOS-only operating system environment.  DO NOT run the diagnostics 
+         from a DOS or command prompt session under Windows 95, Windows NT, 
+         OS/2, or other operating system.
+
+To run the diagnostics tests on the CS8900/20 adapter:
+
+   1.) Boot DOS on the PC and start the CS8900/20 Setup Utility.
+
+   2.) The adapter's current configuration is displayed.  Hit the ENTER key to
+       get to the main menu.
+
+   4.) Select 'Diagnostics' (ALT-G) from the main menu.  
+       * Select 'Self-Test' to test the adapter's basic functionality.
+       * Select 'Network Test' to test the network connection and cabling.
+
+
+5.2.1 DIAGNOSTIC SELF-TEST
+
+The diagnostic self-test checks the adapter's basic functionality as well as 
+its ability to communicate across the ISA bus based on the system resources 
+assigned during hardware configuration.  The following tests are performed:
+
+   * IO Register Read/Write Test
+     The IO Register Read/Write test insures that the CS8900/20 can be 
+     accessed in IO mode, and that the IO base address is correct.
+
+   * Shared Memory Test
+     The Shared Memory test insures the CS8900/20 can be accessed in memory 
+     mode and that the range of memory addresses assigned does not conflict 
+     with other devices in the system.
+
+   * Interrupt Test
+     The Interrupt test insures there are no conflicts with the assigned IRQ
+     signal.
+
+   * EEPROM Test
+     The EEPROM test insures the EEPROM can be read.
+
+   * Chip RAM Test
+     The Chip RAM test insures the 4K of memory internal to the CS8900/20 is
+     working properly.
+
+   * Internal Loop-back Test
+     The Internal Loop Back test insures the adapter's transmitter and 
+     receiver are operating properly.  If this test fails, make sure the 
+     adapter's cable is connected to the network (check for LED activity for 
+     example).
+
+   * Boot PROM Test
+     The Boot PROM  test insures the Boot PROM is present, and can be read.
+     Failure indicates the Boot PROM  was not successfully read due to a
+     hardware problem or due to a conflicts on the Boot PROM address
+     assignment. (Test only applies if the adapter is configured to use the
+     Boot PROM option.)
+
+Failure of a test item indicates a possible system resource conflict with 
+another device on the ISA bus.  In this case, you should use the Manual Setup 
+option to reconfigure the adapter by selecting a different value for the system
+resource that failed.
+
+
+5.2.2 DIAGNOSTIC NETWORK TEST
+
+The Diagnostic Network Test verifies a working network connection by 
+transferring data between two CS8900/20 adapters installed in different PCs 
+on the same network. (Note: the diagnostic network test should not be run 
+between two nodes across a router.) 
+
+This test requires that each of the two PCs have a CS8900/20-based adapter
+installed and have the CS8900/20 Setup Utility running.  The first PC is 
+configured as a Responder and the other PC is configured as an Initiator.  
+Once the Initiator is started, it sends data frames to the Responder which 
+returns the frames to the Initiator.
+
+The total number of frames received and transmitted are displayed on the 
+Initiator's display, along with a count of the number of frames received and 
+transmitted OK or in error.  The test can be terminated anytime by the user at 
+either PC.
+
+To setup the Diagnostic Network Test:
+
+    1.) Select a PC with a CS8900/20-based adapter and a known working network
+        connection to act as the Responder.  Run the CS8900/20 Setup Utility 
+        and select 'Diagnostics -> Network Test -> Responder' from the main 
+        menu.  Hit ENTER to start the Responder.
+
+    2.) Return to the PC with the CS8900/20-based adapter you want to test and
+        start the CS8900/20 Setup Utility. 
+
+    3.) From the main menu, Select 'Diagnostic -> Network Test -> Initiator'.
+        Hit ENTER to start the test.
+ 
+You may stop the test on the Initiator at any time while allowing the Responder
+to continue running.  In this manner, you can move to additional PCs and test 
+them by starting the Initiator on another PC without having to stop/start the 
+Responder.
+ 
+
+
+5.3 USING THE ADAPTER'S LEDs
+
+The 2 and 3-media adapters have two LEDs visible on the back end of the board 
+located near the 10Base-T connector.  
+
+Link Integrity LED: A "steady" ON of the green LED indicates a valid 10Base-T 
+connection.  (Only applies to 10Base-T.  The green LED has no significance for
+a 10Base-2 or AUI connection.)
+
+TX/RX LED: The yellow LED lights briefly each time the adapter transmits or 
+receives data. (The yellow LED will appear to "flicker" on a typical network.)
+
+
+5.4 RESOLVING I/O CONFLICTS
+
+An IO conflict occurs when two or more adapter use the same ISA resource (IO 
+address, memory address or IRQ).  You can usually detect an IO conflict in one 
+of four ways after installing and or configuring the CS8900/20-based adapter:
+
+    1.) The system does not boot properly (or at all).
+
+    2.) The driver can not communicate with the adapter, reporting an "Adapter
+        not found" error message.
+
+    3.) You cannot connect to the network or the driver will not load.
+
+    4.) If you have configured the adapter to run in memory mode but the driver
+        reports it is using IO mode when loading, this is an indication of a
+        memory address conflict.
+
+If an IO conflict occurs, run the CS8900/20 Setup Utility and perform a 
+diagnostic self-test.  Normally, the ISA resource in conflict will fail the 
+self-test.  If so, reconfigure the adapter selecting another choice for the 
+resource in conflict.  Run the diagnostics again to check for further IO 
+conflicts.
+
+In some cases, such as when the PC will not boot, it may be necessary to remove
+the adapter and reconfigure it by installing it in another PC to run the 
+CS8900/20 Setup Utility.  Once reinstalled in the target system, run the 
+diagnostics self-test to ensure the new configuration is free of conflicts 
+before loading the driver again.
+
+When manually configuring the adapter, keep in mind the typical ISA system 
+resource usage as indicated in the tables below.
+
+I/O Address     Device                        IRQ      Device
+-----------     --------                      ---      --------
+ 200-20F        Game I/O adapter               3       COM2, Bus Mouse
+ 230-23F        Bus Mouse                      4       COM1
+ 270-27F        LPT3: third parallel port      5       LPT2
+ 2F0-2FF        COM2: second serial port       6       Floppy Disk controller
+ 320-32F        Fixed disk controller          7       LPT1
+                                               8       Real-time Clock
+                                                 9       EGA/VGA display adapter    
+                                                12       Mouse (PS/2)                              
+Memory Address  Device                          13       Math Coprocessor
+--------------  ---------------------           14       Hard Disk controller
+A000-BFFF       EGA Graphics Adpater
+A000-C7FF       VGA Graphics Adpater
+B000-BFFF       Mono Graphics Adapter
+B800-BFFF       Color Graphics Adapter
+E000-FFFF       AT BIOS
+
+
+
+
+6.0 TECHNICAL SUPPORT
+===============================================================================
+
+6.1 CONTACTING CIRRUS LOGIC'S TECHNICAL SUPPORT
+
+Cirrus Logic's CS89XX Technical Application Support can be reached at:
+
+Telephone  :(800) 888-5016 (from inside U.S. and Canada)
+           :(512) 442-7555 (from outside the U.S. and Canada)
+Fax        :(512) 912-3871
+Email      :ethernet@crystal.cirrus.com
+WWW        :http://www.cirrus.com
+
+
+6.2 INFORMATION REQUIRED BEFORE CONTACTING TECHNICAL SUPPORT
+
+Before contacting Cirrus Logic for technical support, be prepared to provide as 
+Much of the following information as possible. 
+
+1.) Adapter type (CRD8900, CDB8900, CDB8920, etc.)
+
+2.) Adapter configuration
+
+    * IO Base, Memory Base, IO or memory mode enabled, IRQ, DMA channel
+    * Plug and Play enabled/disabled (CS8920-based adapters only)
+    * Configured for media auto-detect or specific media type (which type).    
+
+3.) PC System's Configuration
+
+    * Plug and Play system (yes/no)
+    * BIOS (make and version)
+    * System make and model
+    * CPU (type and speed)
+    * System RAM
+    * SCSI Adapter
+
+4.) Software
+
+    * CS89XX driver and version
+    * Your network operating system and version
+    * Your system's OS version 
+    * Version of all protocol support files
+
+5.) Any Error Message displayed.
+
+
+
+6.3 OBTAINING THE LATEST DRIVER VERSION
+
+You can obtain the latest CS89XX drivers and support software from Cirrus Logic's 
+Web site.  You can also contact Cirrus Logic's Technical Support (email:
+ethernet@crystal.cirrus.com) and request that you be registered for automatic 
+software-update notification.
+
+Cirrus Logic maintains a web page at http://www.cirrus.com with the
+the latest drivers and technical publications.
+
+
+6.4 Current maintainer
+
+In February 2000 the maintenance of this driver was assumed by Andrew
+Morton <akpm@zip.com.au>
+
+6.5 Kernel module parameters
+
+For use in embedded environments with no cs89x0 EEPROM, the kernel boot
+parameter `cs89x0_media=' has been implemented.  Usage is:
+
+        cs89x0_media=rj45    or
+        cs89x0_media=aui     or
+        cs89x0_media=bnc
+
diff --git a/Documentation/networking/de4x5.txt b/Documentation/networking/de4x5.txt
new file mode 100644
index 00000000000..c8e4ca9b2c3
--- /dev/null
+++ b/Documentation/networking/de4x5.txt
@@ -0,0 +1,178 @@
+    Originally,   this  driver  was    written  for the  Digital   Equipment
+    Corporation series of EtherWORKS Ethernet cards:
+
+        DE425 TP/COAX EISA
+        DE434 TP PCI
+        DE435 TP/COAX/AUI PCI
+        DE450 TP/COAX/AUI PCI
+        DE500 10/100 PCI Fasternet
+
+    but it  will  now attempt  to  support all  cards which   conform to the
+    Digital Semiconductor   SROM   Specification.    The  driver   currently
+    recognises the following chips:
+
+        DC21040  (no SROM) 
+        DC21041[A]  
+        DC21140[A] 
+        DC21142 
+        DC21143 
+
+    So far the driver is known to work with the following cards:
+
+        KINGSTON
+        Linksys
+        ZNYX342
+        SMC8432
+        SMC9332 (w/new SROM)
+        ZNYX31[45]
+        ZNYX346 10/100 4 port (can act as a 10/100 bridge!) 
+
+    The driver has been tested on a relatively busy network using the DE425,
+    DE434, DE435 and DE500 cards and benchmarked with 'ttcp': it transferred
+    16M of data to a DECstation 5000/200 as follows:
+
+                TCP           UDP
+             TX     RX     TX     RX
+    DE425   1030k  997k   1170k  1128k
+    DE434   1063k  995k   1170k  1125k
+    DE435   1063k  995k   1170k  1125k
+    DE500   1063k  998k   1170k  1125k  in 10Mb/s mode
+
+    All  values are typical (in   kBytes/sec) from a  sample  of 4 for  each
+    measurement. Their error is +/-20k on a quiet (private) network and also
+    depend on what load the CPU has.
+
+    =========================================================================
+
+    The ability to load this  driver as a loadable  module has been included
+    and used extensively  during the driver development  (to save those long
+    reboot sequences).  Loadable module support  under PCI and EISA has been
+    achieved by letting the driver autoprobe as if it were compiled into the
+    kernel. Do make sure  you're not sharing  interrupts with anything  that
+    cannot accommodate  interrupt  sharing!
+
+    To utilise this ability, you have to do 8 things:
+
+    0) have a copy of the loadable modules code installed on your system.
+    1) copy de4x5.c from the  /linux/drivers/net directory to your favourite
+    temporary directory.
+    2) for fixed  autoprobes (not  recommended),  edit the source code  near
+    line 5594 to reflect the I/O address  you're using, or assign these when
+    loading by:
+
+                   insmod de4x5 io=0xghh           where g = bus number
+                                                        hh = device number   
+
+       NB: autoprobing for modules is now supported by default. You may just
+           use:
+
+                   insmod de4x5
+
+           to load all available boards. For a specific board, still use
+           the 'io=?' above.
+    3) compile  de4x5.c, but include -DMODULE in  the command line to ensure
+    that the correct bits are compiled (see end of source code).
+    4) if you are wanting to add a new  card, goto 5. Otherwise, recompile a
+    kernel with the de4x5 configuration turned off and reboot.
+    5) insmod de4x5 [io=0xghh]
+    6) run the net startup bits for your new eth?? interface(s) manually 
+    (usually /etc/rc.inet[12] at boot time). 
+    7) enjoy!
+
+    To unload a module, turn off the associated interface(s) 
+    'ifconfig eth?? down' then 'rmmod de4x5'.
+
+    Automedia detection is included so that in  principle you can disconnect
+    from, e.g.  TP, reconnect  to BNC  and  things will still work  (after a
+    pause whilst the   driver figures out   where its media went).  My tests
+    using ping showed that it appears to work....
+
+    By  default,  the driver will  now   autodetect any  DECchip based card.
+    Should you have a need to restrict the driver to DIGITAL only cards, you
+    can compile with a  DEC_ONLY define, or if  loading as a module, use the
+    'dec_only=1'  parameter. 
+
+    I've changed the timing routines to  use the kernel timer and scheduling
+    functions  so that the  hangs  and other assorted problems that occurred
+    while autosensing the  media  should be gone.  A  bonus  for the DC21040
+    auto  media sense algorithm is  that it can now  use one that is more in
+    line with the  rest (the DC21040  chip doesn't  have a hardware  timer).
+    The downside is the 1 'jiffies' (10ms) resolution.
+
+    IEEE 802.3u MII interface code has  been added in anticipation that some
+    products may use it in the future.
+
+    The SMC9332 card  has a non-compliant SROM  which needs fixing -  I have
+    patched this  driver to detect it  because the SROM format used complies
+    to a previous DEC-STD format.
+
+    I have removed the buffer copies needed for receive on Intels.  I cannot
+    remove them for   Alphas since  the  Tulip hardware   only does longword
+    aligned  DMA transfers  and  the  Alphas get   alignment traps with  non
+    longword aligned data copies (which makes them really slow). No comment.
+
+    I  have added SROM decoding  routines to make this  driver work with any
+    card that  supports the Digital  Semiconductor SROM spec. This will help
+    all  cards running the dc2114x  series chips in particular.  Cards using
+    the dc2104x  chips should run correctly with  the basic  driver.  I'm in
+    debt to <mjacob@feral.com> for the  testing and feedback that helped get
+    this feature working.  So far we have  tested KINGSTON, SMC8432, SMC9332
+    (with the latest SROM complying  with the SROM spec  V3: their first was
+    broken), ZNYX342  and  LinkSys. ZNYX314 (dual  21041  MAC) and  ZNYX 315
+    (quad 21041 MAC)  cards also  appear  to work despite their  incorrectly
+    wired IRQs.
+
+    I have added a temporary fix for interrupt problems when some SCSI cards
+    share the same interrupt as the DECchip based  cards. The problem occurs
+    because  the SCSI card wants to  grab the interrupt  as a fast interrupt
+    (runs the   service routine with interrupts turned   off) vs.  this card
+    which really needs to run the service routine with interrupts turned on.
+    This driver will  now   add the interrupt service   routine  as  a  fast
+    interrupt if it   is bounced from the   slow interrupt.  THIS IS NOT   A
+    RECOMMENDED WAY TO RUN THE DRIVER  and has been done  for a limited time
+    until  people   sort  out their  compatibility    issues and the  kernel
+    interrupt  service code  is  fixed.   YOU  SHOULD SEPARATE OUT  THE FAST
+    INTERRUPT CARDS FROM THE SLOW INTERRUPT CARDS to ensure that they do not
+    run on the same interrupt. PCMCIA/CardBus is another can of worms...
+
+    Finally, I think  I have really  fixed  the module  loading problem with
+    more than one DECchip based  card.  As a  side effect, I don't mess with
+    the  device structure any  more which means that  if more than 1 card in
+    2.0.x is    installed (4  in   2.1.x),  the  user   will have   to  edit
+    linux/drivers/net/Space.c  to make room for  them. Hence, module loading
+    is  the preferred way to use   this driver, since  it  doesn't have this
+    limitation.
+
+    Where SROM media  detection is used and  full duplex is specified in the
+    SROM,  the feature is  ignored unless  lp->params.fdx  is set at compile
+    time  OR during  a   module load  (insmod  de4x5   args='eth??:fdx' [see
+    below]).  This is because there  is no way  to automatically detect full
+    duplex   links  except through   autonegotiation.    When I  include the
+    autonegotiation feature in  the SROM autoconf  code, this detection will
+    occur automatically for that case.
+
+    Command line  arguments are  now allowed, similar to  passing  arguments
+    through LILO. This will allow a per adapter board set  up of full duplex
+    and media. The only lexical constraints are:  the board name (dev->name)
+    appears in  the list before its parameters.  The list of parameters ends
+    either at the end of the parameter list or with another board name.  The
+    following parameters are allowed:
+
+            fdx        for full duplex
+            autosense  to set the media/speed; with the following 
+                       sub-parameters:
+                       TP, TP_NW, BNC, AUI, BNC_AUI, 100Mb, 10Mb, AUTO
+
+    Case sensitivity is important  for  the sub-parameters. They *must*   be
+    upper case. Examples:
+
+        insmod de4x5 args='eth1:fdx autosense=BNC eth0:autosense=100Mb'.
+
+    For a compiled in driver, in linux/drivers/net/CONFIG, place e.g.
+        DE4X5_OPTS = -DDE4X5_PARM='"eth0:fdx autosense=AUI eth2:autosense=TP"' 
+
+    Yes,  I know full duplex  isn't permissible on BNC  or AUI; they're just
+    examples. By default, full duplex is turned  off and AUTO is the default
+    autosense setting. In  reality, I expect only the  full duplex option to
+    be used. Note the use of single quotes in the two examples above and the
+    lack of commas to separate items.
diff --git a/Documentation/networking/decnet.txt b/Documentation/networking/decnet.txt
new file mode 100644
index 00000000000..c6bd25f5d61
--- /dev/null
+++ b/Documentation/networking/decnet.txt
@@ -0,0 +1,234 @@
+                    Linux DECnet Networking Layer Information
+                   ===========================================
+
+1) Other documentation....
+
+   o Project Home Pages
+       http://www.chygwyn.com/DECnet/                      - Kernel info
+       http://linux-decnet.sourceforge.net/                - Userland tools
+       http://www.sourceforge.net/projects/linux-decnet/   - Status page
+
+2) Configuring the kernel
+
+Be sure to turn on the following options:
+
+    CONFIG_DECNET (obviously)
+    CONFIG_PROC_FS (to see what's going on)
+    CONFIG_SYSCTL (for easy configuration)
+
+if you want to try out router support (not properly debugged yet)
+you'll need the following options as well...
+
+    CONFIG_DECNET_ROUTER (to be able to add/delete routes)
+    CONFIG_NETFILTER (will be required for the DECnet routing daemon)
+
+    CONFIG_DECNET_ROUTE_FWMARK is optional
+
+Don't turn on SIOCGIFCONF support for DECnet unless you are really sure
+that you need it, in general you won't and it can cause ifconfig to
+malfunction.
+
+Run time configuration has changed slightly from the 2.4 system. If you
+want to configure an endnode, then the simplified procedure is as follows:
+
+ o Set the MAC address on your ethernet card before starting _any_ other
+   network protocols.
+
+As soon as your network card is brought into the UP state, DECnet should
+start working. If you need something more complicated or are unsure how
+to set the MAC address, see the next section. Also all configurations which
+worked with 2.4 will work under 2.5 with no change.
+
+3) Command line options
+
+You can set a DECnet address on the kernel command line for compatibility
+with the 2.4 configuration procedure, but in general it's not needed any more.
+If you do st a DECnet address on the command line, it has only one purpose
+which is that its added to the addresses on the loopback device.
+
+With 2.4 kernels, DECnet would only recognise addresses as local if they
+were added to the loopback device. In 2.5, any local interface address
+can be used to loop back to the local machine. Of course this does not
+prevent you adding further addresses to the loopback device if you
+want to.
+
+N.B. Since the address list of an interface determines the addresses for
+which "hello" messages are sent, if you don't set an address on the loopback
+interface then you won't see any entries in /proc/net/neigh for the local
+host until such time as you start a connection. This doesn't affect the
+operation of the local communications in any other way though.
+
+The kernel command line takes options looking like the following:
+
+    decnet=1,2
+
+the two numbers are the node address 1,2 = 1.2 For 2.2.xx kernels
+and early 2.3.xx kernels, you must use a comma when specifying the
+DECnet address like this. For more recent 2.3.xx kernels, you may
+use almost any character except space, although a `.` would be the most
+obvious choice :-)
+
+There used to be a third number specifying the node type. This option
+has gone away in favour of a per interface node type. This is now set
+using /proc/sys/net/decnet/conf/<dev>/forwarding. This file can be
+set with a single digit, 0=EndNode, 1=L1 Router and  2=L2 Router.
+
+There are also equivalent options for modules. The node address can
+also be set through the /proc/sys/net/decnet/ files, as can other system
+parameters.
+
+Currently the only supported devices are ethernet and ip_gre. The
+ethernet address of your ethernet card has to be set according to the DECnet
+address of the node in order for it to be autoconfigured (and then appear in
+/proc/net/decnet_dev). There is a utility available at the above
+FTP sites called dn2ethaddr which can compute the correct ethernet
+address to use. The address can be set by ifconfig either before at
+at the time the device is brought up. If you are using RedHat you can
+add the line:
+
+    MACADDR=AA:00:04:00:03:04
+
+or something similar, to /etc/sysconfig/network-scripts/ifcfg-eth0 or
+wherever your network card's configuration lives. Setting the MAC address
+of your ethernet card to an address starting with "hi-ord" will cause a
+DECnet address which matches to be added to the interface (which you can
+verify with iproute2).
+
+The default device for routing can be set through the /proc filesystem
+by setting /proc/sys/net/decnet/default_device to the
+device you want DECnet to route packets out of when no specific route
+is available. Usually this will be eth0, for example:
+
+    echo -n "eth0" >/proc/sys/net/decnet/default_device
+
+If you don't set the default device, then it will default to the first
+ethernet card which has been autoconfigured as described above. You can
+confirm that by looking in the default_device file of course.
+
+There is a list of what the other files under /proc/sys/net/decnet/ do
+on the kernel patch web site (shown above).
+
+4) Run time kernel configuration
+
+This is either done through the sysctl/proc interface (see the kernel web
+pages for details on what the various options do) or through the iproute2
+package in the same way as IPv4/6 configuration is performed.
+
+Documentation for iproute2 is included with the package, although there is
+as yet no specific section on DECnet, most of the features apply to both
+IP and DECnet, albeit with DECnet addresses instead of IP addresses and
+a reduced functionality.
+
+If you want to configure a DECnet router you'll need the iproute2 package
+since its the _only_ way to add and delete routes currently. Eventually
+there will be a routing daemon to send and receive routing messages for
+each interface and update the kernel routing tables accordingly. The
+routing daemon will use netfilter to listen to routing packets, and
+rtnetlink to update the kernels routing tables. 
+
+The DECnet raw socket layer has been removed since it was there purely
+for use by the routing daemon which will now use netfilter (a much cleaner
+and more generic solution) instead.
+
+5) How can I tell if its working ?
+
+Here is a quick guide of what to look for in order to know if your DECnet
+kernel subsystem is working.
+
+   - Is the node address set (see /proc/sys/net/decnet/node_address)
+   - Is the node of the correct type 
+                             (see /proc/sys/net/decnet/conf/<dev>/forwarding)
+   - Is the Ethernet MAC address of each Ethernet card set to match
+     the DECnet address. If in doubt use the dn2ethaddr utility available
+     at the ftp archive.
+   - If the previous two steps are satisfied, and the Ethernet card is up,
+     you should find that it is listed in /proc/net/decnet_dev and also
+     that it appears as a directory in /proc/sys/net/decnet/conf/. The
+     loopback device (lo) should also appear and is required to communicate
+     within a node.
+   - If you have any DECnet routers on your network, they should appear
+     in /proc/net/decnet_neigh, otherwise this file will only contain the
+     entry for the node itself (if it doesn't check to see if lo is up).
+   - If you want to send to any node which is not listed in the
+     /proc/net/decnet_neigh file, you'll need to set the default device
+     to point to an Ethernet card with connection to a router. This is
+     again done with the /proc/sys/net/decnet/default_device file.
+   - Try starting a simple server and client, like the dnping/dnmirror
+     over the loopback interface. With luck they should communicate.
+     For this step and those after, you'll need the DECnet library
+     which can be obtained from the above ftp sites as well as the
+     actual utilities themselves.
+   - If this seems to work, then try talking to a node on your local
+     network, and see if you can obtain the same results.
+   - At this point you are on your own... :-)
+
+6) How to send a bug report
+
+If you've found a bug and want to report it, then there are several things
+you can do to help me work out exactly what it is that is wrong. Useful
+information (_most_ of which _is_ _essential_) includes:
+
+ - What kernel version are you running ?
+ - What version of the patch are you running ?
+ - How far though the above set of tests can you get ?
+ - What is in the /proc/decnet* files and /proc/sys/net/decnet/* files ?
+ - Which services are you running ?
+ - Which client caused the problem ?
+ - How much data was being transferred ?
+ - Was the network congested ?
+ - If there was a kernel panic, please run the output through ksymoops
+   before sending it to me, otherwise its _useless_.
+ - How can the problem be reproduced ?
+ - Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of 
+   tcpdump don't understand how to dump DECnet properly, so including
+   the hex listing of the packet contents is _essential_, usually the -x flag.
+   You may also need to increase the length grabbed with the -s flag. The
+   -e flag also provides very useful information (ethernet MAC addresses))
+
+7) MAC FAQ
+
+A quick FAQ on ethernet MAC addresses to explain how Linux and DECnet
+interact and how to get the best performance from your hardware. 
+
+Ethernet cards are designed to normally only pass received network frames 
+to a host computer when they are addressed to it, or to the broadcast address.
+
+Linux has an interface which allows the setting of extra addresses for
+an ethernet card to listen to. If the ethernet card supports it, the
+filtering operation will be done in hardware, if not the extra unwanted packets
+received will be discarded by the host computer. In the latter case,
+significant processor time and bus bandwidth can be used up on a busy
+network (see the NAPI documentation for a longer explanation of these
+effects).
+
+DECnet makes use of this interface to allow running DECnet on an ethernet 
+card which has already been configured using TCP/IP (presumably using the 
+built in MAC address of the card, as usual) and/or to allow multiple DECnet
+addresses on each physical interface. If you do this, be aware that if your
+ethernet card doesn't support perfect hashing in its MAC address filter
+then your computer will be doing more work than required. Some cards
+will simply set themselves into promiscuous mode in order to receive
+packets from the DECnet specified addresses. So if you have one of these
+cards its better to set the MAC address of the card as described above
+to gain the best efficiency. Better still is to use a card which supports
+NAPI as well.
+
+
+8) Mailing list
+
+If you are keen to get involved in development, or want to ask questions
+about configuration, or even just report bugs, then there is a mailing
+list that you can join, details are at:
+
+http://sourceforge.net/mail/?group_id=4993
+
+9) Legal Info
+
+The Linux DECnet project team have placed their code under the GPL. The
+software is provided "as is" and without warranty express or implied.
+DECnet is a trademark of Compaq. This software is not a product of
+Compaq. We acknowledge the help of people at Compaq in providing extra
+documentation above and beyond what was previously publicly available.
+
+Steve Whitehouse <SteveW@ACM.org>
+
diff --git a/Documentation/networking/depca.txt b/Documentation/networking/depca.txt
new file mode 100644
index 00000000000..24c6b26e565
--- /dev/null
+++ b/Documentation/networking/depca.txt
@@ -0,0 +1,92 @@
+
+DE10x
+=====
+
+Memory Addresses:
+
+        SW1     SW2     SW3     SW4
+64K     on      on      on      on      d0000   dbfff
+        off     on      on      on      c0000   cbfff
+        off     off     on      on      e0000   ebfff
+
+32K     on      on      off     on      d8000   dbfff
+        off     on      off     on      c8000   cbfff
+        off     off     off     on      e8000   ebfff
+
+DBR ROM on      on                      dc000   dffff
+        off     on                      cc000   cffff
+        off     off                     ec000   effff
+
+Note  that the 2K  mode   is set  by   SW3/SW4  on/off or  off/off.  Address
+assignment is through the RBSA register.
+
+I/O Address:
+        SW5
+0x300   on
+0x200   off
+
+Remote Boot:
+        SW6
+Disable on
+Enable  off
+
+Remote Boot Timeout:
+        SW7
+2.5min  on
+30s     off
+
+IRQ:
+        SW8     SW9     SW10    SW11    SW12
+2       on      off     off     off     off
+3       off     on      off     off     off
+4       off     off     on      off     off
+5       off     off     off     on      off
+7       off     off     off     off     on
+
+DE20x
+=====
+
+Memory Size:
+
+        SW3     SW4
+64K     on      on
+32K     off     on
+2K      on      off
+2K      off     off
+
+Start Addresses:
+
+        SW1     SW2     SW3     SW4
+64K     on      on      on      on      c0000   cffff
+        on      off     on      on      d0000   dffff
+        off     on      on      on      e0000   effff
+
+32K     on      on      off     off     c8000   cffff
+        on      off     off     off     d8000   dffff
+        off     on      off     off     e8000   effff
+
+Illegal off     off      -       -        -       -
+
+I/O Address:
+        SW5
+0x300   on
+0x200   off
+
+Remote Boot:
+        SW6
+Disable on
+Enable  off
+
+Remote Boot Timeout:
+        SW7
+2.5min  on
+30s     off
+
+IRQ:
+        SW8     SW9     SW10    SW11    SW12
+5       on      off     off     off     off
+9       off     on      off     off     off
+10      off     off     on      off     off
+11      off     off     off     on      off
+15      off     off     off     off     on
+
diff --git a/Documentation/networking/dgrs.txt b/Documentation/networking/dgrs.txt
new file mode 100644
index 00000000000..1aa1bb3f94a
--- /dev/null
+++ b/Documentation/networking/dgrs.txt
@@ -0,0 +1,52 @@
+    The Digi International RightSwitch SE-X (dgrs) Device Driver
+
+This is a Linux driver for the Digi International RightSwitch SE-X
+EISA and PCI boards.  These are 4 (EISA) or 6 (PCI) port Ethernet
+switches and a NIC combined into a single board.  This driver can
+be compiled into the kernel statically or as a loadable module.
+
+There is also a companion management tool, called "xrightswitch".
+The management tool lets you watch the performance graphically,
+as well as set the SNMP agent IP and IPX addresses, IEEE Spanning
+Tree, and Aging time.  These can also be set from the command line
+when the driver is loaded.  The driver command line options are:
+
+        debug=NNN               Debug printing level
+        dma=0/1                 Disable/Enable DMA on PCI card
+        spantree=0/1            Disable/Enable IEEE spanning tree
+        hashexpire=NNN          Change address aging time (default 300 seconds)
+        ipaddr=A,B,C,D          Set SNMP agent IP address i.e. 199,86,8,221
+        iptrap=A,B,C,D          Set SNMP agent IP trap address i.e. 199,86,8,221
+        ipxnet=NNN              Set SNMP agent IPX network number
+        nicmode=0/1             Disable/Enable multiple NIC mode
+
+There is also a tool for setting up input and output packet filters
+on each port, called "dgrsfilt".
+
+Both the management tool and the filtering tool are available
+separately from the following FTP site:
+
+        ftp://ftp.dgii.com/drivers/rightswitch/linux/
+
+When nicmode=1, the board and driver operate as 4 or 6 individual
+NIC ports (eth0...eth5) instead of as a switch.  All switching
+functions are disabled.  In the future, the board firmware may include
+a routing cache when in this mode.
+
+Copyright 1995-1996 Digi International Inc.
+
+This software may be used and distributed according to the terms
+of the GNU General Public License, incorporated herein by reference.
+
+For information on purchasing a RightSwitch SE-4 or SE-6
+board, please contact Digi's sales department at 1-612-912-3444
+or 1-800-DIGIBRD.  Outside the U.S., please check our Web page at:
+
+        http://www.dgii.com
+
+for sales offices worldwide.  Tech support is also available through
+the channels listed on the Web site, although as long as I am
+employed on networking products at Digi I will be happy to provide
+any bug fixes that may be needed.
+
+-Rick Richardson, rick@dgii.com
diff --git a/Documentation/networking/dl2k.txt b/Documentation/networking/dl2k.txt
new file mode 100644
index 00000000000..d460492037e
--- /dev/null
+++ b/Documentation/networking/dl2k.txt
@@ -0,0 +1,281 @@
+
+    D-Link DL2000-based Gigabit Ethernet Adapter Installation
+    for Linux
+    May 23, 2002
+
+Contents
+========
+ - Compatibility List
+ - Quick Install
+ - Compiling the Driver
+ - Installing the Driver
+ - Option parameter
+ - Configuration Script Sample
+ - Troubleshooting
+
+
+Compatibility List
+=================
+Adapter Support:
+
+D-Link DGE-550T Gigabit Ethernet Adapter.
+D-Link DGE-550SX Gigabit Ethernet Adapter.
+D-Link DL2000-based Gigabit Ethernet Adapter.
+
+
+The driver support Linux kernel 2.4.7 later. We had tested it
+on the environments below.
+
+ . Red Hat v6.2 (update kernel to 2.4.7)
+ . Red Hat v7.0 (update kernel to 2.4.7)
+ . Red Hat v7.1 (kernel 2.4.7)
+ . Red Hat v7.2 (kernel 2.4.7-10)
+
+
+Quick Install
+=============
+Install linux driver as following command:
+
+1. make all
+2. insmod dl2k.ko
+3. ifconfig eth0 up 10.xxx.xxx.xxx netmask 255.0.0.0
+                    ^^^^^^^^^^^^^^^\        ^^^^^^^^\
+                                    IP               NETMASK
+Now eth0 should active, you can test it by "ping" or get more information by
+"ifconfig". If tested ok, continue the next step.
+
+4. cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net
+5. Add the following line to /etc/modprobe.conf:
+        alias eth0 dl2k
+6. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
+   located at /etc/sysconfig/network-scripts or create it manually.
+   [see - Configuration Script Sample]
+7. Driver will automatically load and configure at next boot time.
+
+Compiling the Driver
+====================
+  In Linux, NIC drivers are most commonly configured as loadable modules.
+The approach of building a monolithic kernel has become obsolete. The driver
+can be compiled as part of a monolithic kernel, but is strongly discouraged.
+The remainder of this section assumes the driver is built as a loadable module.
+In the Linux environment, it is a good idea to rebuild the driver from the
+source instead of relying on a precompiled version. This approach provides
+better reliability since a precompiled driver might depend on libraries or
+kernel features that are not present in a given Linux installation.
+
+The 3 files necessary to build Linux device driver are dl2k.c, dl2k.h and
+Makefile. To compile, the Linux installation must include the gcc compiler,
+the kernel source, and the kernel headers. The Linux driver supports Linux
+Kernels 2.4.7. Copy the files to a directory and enter the following command
+to compile and link the driver:
+
+CD-ROM drive
+------------
+
+[root@XXX /] mkdir cdrom
+[root@XXX /] mount -r -t iso9660 -o conv=auto /dev/cdrom /cdrom
+[root@XXX /] cd root
+[root@XXX /root] mkdir dl2k
+[root@XXX /root] cd dl2k
+[root@XXX dl2k] cp /cdrom/linux/dl2k.tgz /root/dl2k
+[root@XXX dl2k] tar xfvz dl2k.tgz
+[root@XXX dl2k] make all
+
+Floppy disc drive
+-----------------
+
+[root@XXX /] cd root
+[root@XXX /root] mkdir dl2k
+[root@XXX /root] cd dl2k
+[root@XXX dl2k] mcopy a:/linux/dl2k.tgz /root/dl2k
+[root@XXX dl2k] tar xfvz dl2k.tgz
+[root@XXX dl2k] make all
+
+Installing the Driver
+=====================
+
+  Manual Installation
+  -------------------
+  Once the driver has been compiled, it must be loaded, enabled, and bound
+  to a protocol stack in order to establish network connectivity. To load a
+  module enter the command:
+
+  insmod dl2k.o
+
+  or
+
+  insmod dl2k.o <optional parameter>    ; add parameter
+
+  ===============================================================
+   example: insmod dl2k.o media=100mbps_hd
+   or       insmod dl2k.o media=3
+   or       insmod dl2k.o media=3,2     ; for 2 cards
+  ===============================================================
+
+  Please reference the list of the command line parameters supported by
+  the Linux device driver below.
+
+  The insmod command only loads the driver and gives it a name of the form
+  eth0, eth1, etc. To bring the NIC into an operational state,
+  it is necessary to issue the following command:
+
+  ifconfig eth0 up
+
+  Finally, to bind the driver to the active protocol (e.g., TCP/IP with
+  Linux), enter the following command:
+
+  ifup eth0
+
+  Note that this is meaningful only if the system can find a configuration
+  script that contains the necessary network information. A sample will be
+  given in the next paragraph.
+
+  The commands to unload a driver are as follows:
+
+  ifdown eth0
+  ifconfig eth0 down
+  rmmod dl2k.o
+
+  The following are the commands to list the currently loaded modules and
+  to see the current network configuration.
+
+  lsmod
+  ifconfig
+
+
+  Automated Installation
+  ----------------------
+  This section describes how to install the driver such that it is
+  automatically loaded and configured at boot time. The following description
+  is based on a Red Hat 6.0/7.0 distribution, but it can easily be ported to
+  other distributions as well.
+
+  Red Hat v6.x/v7.x
+  -----------------
+  1. Copy dl2k.o to the network modules directory, typically
+     /lib/modules/2.x.x-xx/net or /lib/modules/2.x.x/kernel/drivers/net.
+  2. Locate the boot module configuration file, most commonly modprobe.conf
+     or modules.conf (for 2.4) in the /etc directory. Add the following lines:
+
+     alias ethx dl2k
+     options dl2k <optional parameters>
+
+     where ethx will be eth0 if the NIC is the only ethernet adapter, eth1 if
+     one other ethernet adapter is installed, etc. Refer to the table in the
+     previous section for the list of optional parameters.
+  3. Locate the network configuration scripts, normally the
+     /etc/sysconfig/network-scripts directory, and create a configuration
+     script named ifcfg-ethx that contains network information.
+  4. Note that for most Linux distributions, Red Hat included, a configuration
+     utility with a graphical user interface is provided to perform steps 2
+     and 3 above.
+
+
+Parameter Description
+=====================
+You can install this driver without any addtional parameter. However, if you
+are going to have extensive functions then it is necessary to set extra
+parameter. Below is a list of the command line parameters supported by the
+Linux device
+driver.
+
+mtu=packet_size                 - Specifies the maximum packet size. default
+                                  is 1500.
+
+media=media_type                - Specifies the media type the NIC operates at.
+                                  autosense     Autosensing active media.
+                                  10mbps_hd     10Mbps half duplex.
+                                  10mbps_fd     10Mbps full duplex.
+                                  100mbps_hd    100Mbps half duplex.
+                                  100mbps_fd    100Mbps full duplex.
+                                  1000mbps_fd   1000Mbps full duplex.
+                                  1000mbps_hd   1000Mbps half duplex.
+                                  0             Autosensing active media.
+                                  1             10Mbps half duplex.
+                                  2             10Mbps full duplex.
+                                  3             100Mbps half duplex.
+                                  4             100Mbps full duplex.
+                                  5             1000Mbps half duplex.
+                                  6             1000Mbps full duplex.
+
+                                  By default, the NIC operates at autosense.
+                                  1000mbps_fd and 1000mbps_hd types are only
+                                  available for fiber adapter.
+
+vlan=n                          - Specifies the VLAN ID. If vlan=0, the
+                                  Virtual Local Area Network (VLAN) function is
+                                  disable.
+
+jumbo=[0|1]                     - Specifies the jumbo frame support. If jumbo=1,
+                                  the NIC accept jumbo frames. By default, this
+                                  function is disabled.
+                                  Jumbo frame usually improve the performance
+                                  int gigabit.
+                                  This feature need jumbo frame compatible 
+                                  remote.
+                                  
+rx_coalesce=m                   - Number of rx frame handled each interrupt.
+rx_timeout=n                    - Rx DMA wait time for an interrupt. 
+                                  If set rx_coalesce > 0, hardware only assert 
+                                  an interrupt for m frames. Hardware won't 
+                                  assert rx interrupt until m frames received or
+                                  reach timeout of n * 640 nano seconds. 
+                                  Set proper rx_coalesce and rx_timeout can 
+                                  reduce congestion collapse and overload which
+                                  has been a bottlenect for high speed network.
+                                  
+                                  For example, rx_coalesce=10 rx_timeout=800.
+                                  that is, hardware assert only 1 interrupt 
+                                  for 10 frames received or timeout of 512 us. 
+
+tx_coalesce=n                   - Number of tx frame handled each interrupt.
+                                  Set n > 1 can reduce the interrupts 
+                                  congestion usually lower performance of
+                                  high speed network card. Default is 16.
+                                  
+tx_flow=[1|0]                   - Specifies the Tx flow control. If tx_flow=0, 
+                                  the Tx flow control disable else driver
+                                  autodetect.
+rx_flow=[1|0]                   - Specifies the Rx flow control. If rx_flow=0, 
+                                  the Rx flow control enable else driver
+                                  autodetect.
+
+
+Configuration Script Sample
+===========================
+Here is a sample of a simple configuration script:
+
+DEVICE=eth0
+USERCTL=no
+ONBOOT=yes
+POOTPROTO=none
+BROADCAST=207.200.5.255
+NETWORK=207.200.5.0
+NETMASK=255.255.255.0
+IPADDR=207.200.5.2
+
+
+Troubleshooting
+===============
+Q1. Source files contain ^ M behind every line.
+        Make sure all files are Unix file format (no LF). Try the following
+    shell command to convert files.
+
+        cat dl2k.c | col -b > dl2k.tmp
+        mv dl2k.tmp dl2k.c
+
+        OR
+
+        cat dl2k.c | tr -d "\r" > dl2k.tmp
+        mv dl2k.tmp dl2k.c
+
+Q2: Could not find header files (*.h) ?
+        To compile the driver, you need kernel header files. After
+    installing the kernel source, the header files are usually located in
+    /usr/src/linux/include, which is the default include directory configured
+    in Makefile. For some distributions, there is a copy of header files in
+    /usr/src/include/linux and /usr/src/include/asm, that you can change the
+    INCLUDEDIR in Makefile to /usr/include without installing kernel source.
+        Note that RH 7.0 didn't provide correct header files in /usr/include,
+    including those files will make a wrong version driver.
+
diff --git a/Documentation/networking/dmfe.txt b/Documentation/networking/dmfe.txt
new file mode 100644
index 00000000000..c0e8398674e
--- /dev/null
+++ b/Documentation/networking/dmfe.txt
@@ -0,0 +1,59 @@
+  dmfe.c: Version 1.28        01/18/2000
+
+        A Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux. 
+        Copyright (C) 1997  Sten Wang
+
+        This program is free software; you can redistribute it and/or
+        modify it under the terms of the GNU General Public License
+        as published by the Free Software Foundation; either version 2
+        of the License, or (at your option) any later version.
+
+        This program is distributed in the hope that it will be useful,
+        but WITHOUT ANY WARRANTY; without even the implied warranty of
+        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+        GNU General Public License for more details.
+
+
+  A. Compiler command:
+
+     A-1: For normal single or multiple processor kernel
+          "gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall 
+            -Wstrict-prototypes -O6 -c dmfe.c"
+
+     A-2: For single or multiple processor with kernel module version function
+          "gcc -DMODULE -DMODVERSIONS -D__KERNEL__ -I/usr/src/linux/net/inet 
+            -Wall -Wstrict-prototypes -O6 -c dmfe.c"
+
+
+  B. The following steps teach you how to activate a DM9102 board:
+
+        1. Used the upper compiler command to compile dmfe.c
+
+        2. Insert dmfe module into kernel
+           "insmod dmfe"        ;;Auto Detection Mode (Suggest)
+           "insmod dmfe mode=0" ;;Force 10M Half Duplex
+           "insmod dmfe mode=1" ;;Force 100M Half Duplex
+           "insmod dmfe mode=4" ;;Force 10M Full Duplex
+           "insmod dmfe mode=5" ;;Force 100M Full Duplex
+
+        3. Config a dm9102 network interface
+           "ifconfig eth0 172.22.3.18"
+                          ^^^^^^^^^^^ Your IP address
+
+        4. Activate the IP routing table. For some distributions, it is not
+           necessary. You can type "route" to check.
+
+           "route add default eth0"
+
+
+        5. Well done. Your DM9102 adapter is now activated.
+
+
+   C. Object files description:
+        1. dmfe_rh61.o:         For Redhat 6.1
+
+        If you can make sure your kernel version, you can rename
+        to dmfe.o and directly use it without re-compiling.
+
+
+  Author: Sten Wang, 886-3-5798797-8517, E-mail: sten_wang@davicom.com.tw
diff --git a/Documentation/networking/driver.txt b/Documentation/networking/driver.txt
new file mode 100644
index 00000000000..11fd0ef5ff5
--- /dev/null
+++ b/Documentation/networking/driver.txt
@@ -0,0 +1,94 @@
+Documents about softnet driver issues in general can be found
+at:
+
+        http://www.firstfloor.org/~andi/softnet/
+
+Transmit path guidelines:
+
+1) The hard_start_xmit method must never return '1' under any
+   normal circumstances.  It is considered a hard error unless
+   there is no way your device can tell ahead of time when it's
+   transmit function will become busy.
+
+   Instead it must maintain the queue properly.  For example,
+   for a driver implementing scatter-gather this means:
+
+        static int drv_hard_start_xmit(struct sk_buff *skb,
+                                       struct net_device *dev)
+        {
+                struct drv *dp = dev->priv;
+
+                lock_tx(dp);
+                ...
+                /* This is a hard error log it. */
+                if (TX_BUFFS_AVAIL(dp) <= (skb_shinfo(skb)->nr_frags + 1)) {
+                        netif_stop_queue(dev);
+                        unlock_tx(dp);
+                        printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
+                               dev->name);
+                        return 1;
+                }
+
+                ... queue packet to card ...
+                ... update tx consumer index ...
+
+                if (TX_BUFFS_AVAIL(dp) <= (MAX_SKB_FRAGS + 1))
+                        netif_stop_queue(dev);
+
+                ...
+                unlock_tx(dp);
+                ...
+        }
+
+   And then at the end of your TX reclaimation event handling:
+
+        if (netif_queue_stopped(dp->dev) &&
+            TX_BUFFS_AVAIL(dp) > (MAX_SKB_FRAGS + 1))
+                netif_wake_queue(dp->dev);
+
+   For a non-scatter-gather supporting card, the three tests simply become:
+
+                /* This is a hard error log it. */
+                if (TX_BUFFS_AVAIL(dp) <= 0)
+
+   and:
+
+                if (TX_BUFFS_AVAIL(dp) == 0)
+
+   and:
+
+        if (netif_queue_stopped(dp->dev) &&
+            TX_BUFFS_AVAIL(dp) > 0)
+                netif_wake_queue(dp->dev);
+
+2) Do not forget to update netdev->trans_start to jiffies after
+   each new tx packet is given to the hardware.
+
+3) Do not forget that once you return 0 from your hard_start_xmit
+   method, it is your driver's responsibility to free up the SKB
+   and in some finite amount of time.
+
+   For example, this means that it is not allowed for your TX
+   mitigation scheme to let TX packets "hang out" in the TX
+   ring unreclaimed forever if no new TX packets are sent.
+   This error can deadlock sockets waiting for send buffer room
+   to be freed up.
+
+   If you return 1 from the hard_start_xmit method, you must not keep
+   any reference to that SKB and you must not attempt to free it up.
+
+Probing guidelines:
+
+1) Any hardware layer address you obtain for your device should
+   be verified.  For example, for ethernet check it with
+   linux/etherdevice.h:is_valid_ether_addr()
+
+Close/stop guidelines:
+
+1) After the dev->stop routine has been called, the hardware must
+   not receive or transmit any data.  All in flight packets must
+   be aborted. If necessary, poll or wait for completion of 
+   any reset commands.
+
+2) The dev->stop routine will be called by unregister_netdevice
+   if device is still UP.
diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt
new file mode 100644
index 00000000000..4ef9f7cd5dc
--- /dev/null
+++ b/Documentation/networking/e100.txt
@@ -0,0 +1,170 @@
+Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
+==============================================================
+
+November 17, 2004
+
+
+Contents
+========
+
+- In This Release
+- Identifying Your Adapter
+- Driver Configuration Parameters
+- Additional Configurations
+- Support
+
+
+In This Release
+===============
+
+This file describes the Linux* Base Driver for the Intel(R) PRO/100 Family of
+Adapters, version 3.3.x.  This driver supports 2.4.x and 2.6.x kernels. 
+
+Identifying Your Adapter
+========================
+
+For more information on how to identify your adapter, go to the Adapter & 
+Driver ID Guide at:
+
+  http://support.intel.com/support/network/adapter/pro100/21397.htm
+
+For the latest Intel network drivers for Linux, refer to the following 
+website. In the search field, enter your adapter name or type, or use the 
+networking link on the left to search for your adapter:
+
+  http://downloadfinder.intel.com/scripts-df/support_intel.asp
+
+Driver Configuration Parameters
+===============================
+
+The default value for each parameter is generally the recommended setting,
+unless otherwise noted.
+
+Rx Descriptors: Number of receive descriptors. A receive descriptor is a data 
+   structure that describes a receive buffer and its attributes to the network 
+   controller. The data in the descriptor is used by the controller to write 
+   data from the controller to host memory. In the 3.0.x driver the valid
+   range for this parameter is 64-256. The default value is 64. This parameter 
+   can be changed using the command 
+ 
+   ethtool -G eth? rx n, where n is the number of desired rx descriptors.
+
+Tx Descriptors: Number of transmit descriptors. A transmit descriptor is a
+   data structure that describes a transmit buffer and its attributes to the
+   network controller. The data in the descriptor is used by the controller to 
+   read data from the host memory to the controller. In the 3.0.x driver the 
+   valid range for this parameter is 64-256. The default value is 64. This 
+   parameter can be changed using the command 
+
+   ethtool -G eth? tx n, where n is the number of desired tx descriptors.
+
+Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by 
+   default. Ethtool can be used as follows to force speed/duplex. 
+
+   ethtool -s eth?  autoneg off speed {10|100} duplex {full|half}
+
+   NOTE: setting the speed/duplex to incorrect values will cause the link to
+   fail.
+
+Event Log Message Level:  The driver uses the message level flag to log events 
+   to syslog. The message level can be set at driver load time. It can also be 
+   set using the command
+
+   ethtool -s eth? msglvl n
+
+Additional Configurations
+=========================
+
+  Configuring the Driver on Different Distributions
+  -------------------------------------------------
+
+  Configuring a network driver to load properly when the system is started is 
+  distribution dependent. Typically, the configuration process involves adding 
+  an alias line to /etc/modules.conf as well as editing other system startup 
+  scripts and/or configuration files.  Many popular Linux distributions ship 
+  with tools to make these changes for you. To learn the proper way to 
+  configure a network device for your system, refer to your distribution 
+  documentation. If during this process you are asked for the driver or module 
+  name, the name for the Linux Base Driver for the Intel PRO/100 Family of 
+  Adapters is e100.
+
+  As an example, if you install the e100 driver for two PRO/100 adapters 
+  (eth0 and eth1), add the following to modules.conf:
+
+       alias eth0 e100
+       alias eth1 e100
+
+  Viewing Link Messages
+  ---------------------
+  In order to see link messages and other Intel driver information on your 
+  console, you must set the dmesg level up to six. This can be done by 
+  entering the following on the command line before loading the e100 driver: 
+
+       dmesg -n 8
+
+  If you wish to see all messages issued by the driver, including debug 
+  messages, set the dmesg level to eight.
+
+  NOTE: This setting is not saved across reboots.
+
+  Ethtool
+  -------
+
+  The driver utilizes the ethtool interface for driver configuration and
+  diagnostics, as well as displaying statistical information.  Ethtool
+  version 1.6 or later is required for this functionality.
+
+  The latest release of ethtool can be found at:
+  http://sf.net/projects/gkernel.  
+
+  NOTE: This driver uses mii support from the kernel. As a result, when 
+  there is no link, ethtool will report speed/duplex to be 10/half.
+
+  NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support 
+  for a more complete ethtool feature set can be enabled by upgrading 
+  ethtool to ethtool-1.8.1. 
+
+  Enabling Wake on LAN* (WoL)
+  ---------------------------
+  WoL is provided through the Ethtool* utility. Ethtool is included with Red 
+  Hat* 8.0. For other Linux distributions, download and install Ethtool from 
+  the following website: http://sourceforge.net/projects/gkernel. 
+
+  For instructions on enabling WoL with Ethtool, refer to the Ethtool man
+  page.
+
+  WoL will be enabled on the system during the next shut down or reboot. For
+  this driver version, in order to enable WoL, the e100 driver must be 
+  loaded when shutting down or rebooting the system.
+
+  NAPI
+  ----
+
+  NAPI (Rx polling mode) is supported in the e100 driver.
+
+  See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
+
+Support
+=======
+
+For general information, go to the Intel support website at:
+
+    http://support.intel.com
+
+If an issue is identified with the released source code on the supported
+kernel with a supported adapter, email the specific information related to 
+the issue to linux.nics@intel.com.
+
+
+License
+=======
+
+This software program is released under the terms of a license agreement 
+between you ('Licensee') and Intel. Do not use or load this software or any 
+associated materials (collectively, the 'Software') until you have carefully 
+read the full terms and conditions of the LICENSE located in this software 
+package. By loading or using the Software, you agree to the terms of this 
+Agreement. If you do not agree with the terms of this Agreement, do not 
+install or use the Software.
+
+* Other names and brands may be claimed as the property of others.
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt
new file mode 100644
index 00000000000..2ebd4058d46
--- /dev/null
+++ b/Documentation/networking/e1000.txt
@@ -0,0 +1,401 @@
+Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
+===============================================================
+
+November 17, 2004
+
+
+Contents
+========
+
+- In This Release
+- Identifying Your Adapter
+- Command Line Parameters
+- Speed and Duplex Configuration
+- Additional Configurations
+- Known Issues
+- Support
+
+
+In This Release
+===============
+
+This file describes the Linux* Base Driver for the Intel(R) PRO/1000 Family
+of Adapters, version 5.x.x.  
+
+For questions related to hardware requirements, refer to the documentation 
+supplied with your Intel PRO/1000 adapter. All hardware requirements listed 
+apply to use with Linux.
+
+Native VLANs are now available with supported kernels.
+
+Identifying Your Adapter
+========================
+
+For more information on how to identify your adapter, go to the Adapter & 
+Driver ID Guide at:
+
+    http://support.intel.com/support/network/adapter/pro100/21397.htm
+
+For the latest Intel network drivers for Linux, refer to the following 
+website. In the search field, enter your adapter name or type, or use the 
+networking link on the left to search for your adapter:
+
+    http://downloadfinder.intel.com/scripts-df/support_intel.asp
+
+Command Line Parameters
+=======================
+
+If the driver is built as a module, the  following optional parameters are 
+used by entering them on the command line with the modprobe or insmod command
+using this syntax:
+
+     modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
+
+     insmod e1000 [<option>=<VAL1>,<VAL2>,...] 
+
+For example, with two PRO/1000 PCI adapters, entering:
+
+     insmod e1000 TxDescriptors=80,128
+
+loads the e1000 driver with 80 TX descriptors for the first adapter and 128 TX 
+descriptors for the second adapter.
+
+The default value for each parameter is generally the recommended setting,
+unless otherwise noted. Also, if the driver is statically built into the
+kernel, the driver is loaded with the default values for all the parameters.
+Ethtool can be used to change some of the parameters at runtime.
+
+    NOTES: For more information about the AutoNeg, Duplex, and Speed
+           parameters, see the "Speed and Duplex Configuration" section in 
+           this document.
+
+           For more information about the InterruptThrottleRate, RxIntDelay, 
+           TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay parameters, see the 
+           application note at:
+           http://www.intel.com/design/network/applnots/ap450.htm
+
+           A descriptor describes a data buffer and attributes related to the 
+           data buffer. This information is accessed by the hardware.
+
+AutoNeg (adapters using copper connections only)
+Valid Range: 0x01-0x0F, 0x20-0x2F
+Default Value: 0x2F
+    This parameter is a bit mask that specifies which speed and duplex
+    settings the board advertises. When this parameter is used, the Speed and
+    Duplex parameters must not be specified.
+    NOTE: Refer to the Speed and Duplex section of this readme for more 
+          information on the AutoNeg parameter.  
+
+Duplex (adapters using copper connections only)
+Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
+Default Value: 0
+    Defines the direction in which data is allowed to flow. Can be either one 
+    or two-directional. If both Duplex and the link partner are set to auto-
+    negotiate, the board auto-detects the correct duplex. If the link partner
+    is forced (either full or half), Duplex defaults to half-duplex.
+
+FlowControl
+Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
+Default: Read flow control settings from the EEPROM
+    This parameter controls the automatic generation(Tx) and response(Rx) to 
+    Ethernet PAUSE frames.
+
+InterruptThrottleRate
+Valid Range: 100-100000 (0=off, 1=dynamic)
+Default Value: 8000
+    This value represents the maximum number of interrupts per second the 
+    controller generates. InterruptThrottleRate is another setting used in 
+    interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust 
+    InterruptThrottleRate based on the current traffic load.
+Un-supported Adapters: InterruptThrottleRate is NOT supported by 82542, 82543
+    or 82544-based adapters.
+
+    NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and 
+          RxAbsIntDelay parameters. In other words, minimizing the receive 
+          and/or transmit absolute delays does not force the controller to 
+          generate more interrupts than what the Interrupt Throttle Rate 
+          allows.
+    CAUTION: If you are using the Intel PRO/1000 CT Network Connection 
+             (controller 82547), setting InterruptThrottleRate to a value 
+             greater than 75,000, may hang (stop transmitting) adapters under 
+             certain network conditions. If this occurs a NETDEV WATCHDOG 
+             message is logged in the system event log. In addition, the 
+             controller is automatically reset, restoring the network 
+             connection. To eliminate the potential for the hang, ensure 
+             that InterruptThrottleRate is set no greater than 75,000 and is 
+             not set to 0.
+    NOTE: When e1000 is loaded with default settings and multiple adapters are 
+          in use simultaneously, the CPU utilization may increase non-linearly. 
+          In order to limit the CPU utilization without impacting the overall 
+          throughput, we recommend that you load the driver as follows:
+
+              insmod e1000.o InterruptThrottleRate=3000,3000,3000
+
+          This sets the InterruptThrottleRate to 3000 interrupts/sec for the 
+          first, second, and third instances of the driver. The range of 2000 to 
+          3000 interrupts per second works on a majority of systems and is a 
+          good starting point, but the optimal value will be platform-specific. 
+          If CPU utilization is not a concern, use RX_POLLING (NAPI) and default 
+          driver settings.
+
+RxDescriptors
+Valid Range: 80-256 for 82542 and 82543-based adapters
+             80-4096 for all other supported adapters
+Default Value: 256
+    This value is the number of receive descriptors allocated by the driver. 
+    Increasing this value allows the driver to buffer more incoming packets. 
+    Each descriptor is 16 bytes.  A receive buffer is allocated for each
+    descriptor and can either be 2048 or 4096 bytes long, depending on the MTU 
+
+    setting. An incoming packet can span one or more receive descriptors. 
+    The maximum MTU size is 16110.
+
+    NOTE: MTU designates the frame size. It only needs to be set for Jumbo 
+          Frames.
+    NOTE: Depending on the available system resources, the request for a
+    higher number of receive descriptors may be denied.  In this case,
+    use a lower number.
+
+RxIntDelay
+Valid Range: 0-65535 (0=off)
+Default Value: 0
+    This value delays the generation of receive interrupts in units of 1.024 
+    microseconds.  Receive interrupt reduction can improve CPU efficiency if 
+    properly tuned for specific network traffic. Increasing this value adds 
+    extra latency to frame reception and can end up decreasing the throughput 
+    of TCP traffic. If the system is reporting dropped receives, this value 
+    may be set too high, causing the driver to run out of available receive 
+    descriptors.
+
+    CAUTION: When setting RxIntDelay to a value other than 0, adapters may 
+             hang (stop transmitting) under certain network conditions. If 
+             this occurs a NETDEV WATCHDOG message is logged in the system
+             event log. In addition, the controller is automatically reset, 
+             restoring the network connection. To eliminate the potential for
+             the hang ensure that RxIntDelay is set to 0.
+
+RxAbsIntDelay (82540, 82545 and later adapters only)
+Valid Range: 0-65535 (0=off)
+Default Value: 128
+    This value, in units of 1.024 microseconds, limits the delay in which a 
+    receive interrupt is generated. Useful only if RxIntDelay is non-zero, 
+    this value ensures that an interrupt is generated after the initial 
+    packet is received within the set amount of time.  Proper tuning,
+    along with RxIntDelay, may improve traffic throughput in specific network
+    conditions.
+
+Speed (adapters using copper connections only)
+Valid Settings: 0, 10, 100, 1000
+Default Value: 0 (auto-negotiate at all supported speeds)
+    Speed forces the line speed to the specified value in megabits per second
+    (Mbps). If this parameter is not specified or is set to 0 and the link 
+    partner is set to auto-negotiate, the board will auto-detect the correct 
+    speed. Duplex should also be set when Speed is set to either 10 or 100.
+
+TxDescriptors
+Valid Range: 80-256 for 82542 and 82543-based adapters
+             80-4096 for all other supported adapters
+Default Value: 256
+    This value is the number of transmit descriptors allocated by the driver.
+    Increasing this value allows the driver to queue more transmits. Each 
+    descriptor is 16 bytes.
+
+    NOTE: Depending on the available system resources, the request for a
+    higher number of transmit descriptors may be denied.  In this case,
+    use a lower number.
+
+TxIntDelay
+Valid Range: 0-65535 (0=off)
+Default Value: 64
+    This value delays the generation of transmit interrupts in units of 
+    1.024 microseconds. Transmit interrupt reduction can improve CPU
+    efficiency if properly tuned for specific network traffic. If the
+    system is reporting dropped transmits, this value may be set too high
+    causing the driver to run out of available transmit descriptors.
+
+TxAbsIntDelay (82540, 82545 and later adapters only)
+Valid Range: 0-65535 (0=off)
+Default Value: 64
+    This value, in units of 1.024 microseconds, limits the delay in which a 
+    transmit interrupt is generated. Useful only if TxIntDelay is non-zero, 
+    this value ensures that an interrupt is generated after the initial 
+    packet is sent on the wire within the set amount of time.  Proper tuning,
+    along with TxIntDelay, may improve traffic throughput in specific 
+    network conditions.
+
+XsumRX (not available on the 82542-based adapter)
+Valid Range: 0-1
+Default Value: 1
+    A value of '1' indicates that the driver should enable IP checksum
+    offload for received packets (both UDP and TCP) to the adapter hardware.
+
+Speed and Duplex Configuration
+==============================
+
+Three keywords are used to control the speed and duplex configuration. These 
+keywords are Speed, Duplex, and AutoNeg.
+
+If the board uses a fiber interface, these keywords are ignored, and the 
+fiber interface board only links at 1000 Mbps full-duplex.
+
+For copper-based boards, the keywords interact as follows:
+
+  The default operation is auto-negotiate. The board advertises all supported
+  speed and duplex combinations, and it links at the highest common speed and
+  duplex mode IF the link partner is set to auto-negotiate.
+
+  If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps is
+  advertised (The 1000BaseT spec requires auto-negotiation.)
+
+  If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
+  negotiation is disabled, and the AutoNeg parameter is ignored. Partner SHOULD
+  also be forced.
+
+The AutoNeg parameter is used when more control is required over the auto-
+negotiation process. When this parameter is used, Speed and Duplex parameters 
+must not be specified. The following table describes supported values for the 
+AutoNeg parameter:
+
+Speed (Mbps)             1000      100    100    10     10
+Duplex                   Full      Full   Half   Full   Half
+Value (in base 16)       0x20      0x08   0x04   0x02   0x01
+
+Example: insmod e1000 AutoNeg=0x03, loads e1000 and specifies (10 full duplex, 
+10 half duplex) for negotiation with the peer.
+
+Note that setting AutoNeg does not guarantee that the board will link at the 
+highest specified speed or duplex mode, but the board will link at the 
+highest possible speed/duplex of the link partner IF the link partner is also
+set to auto-negotiate. If the link partner is forced speed/duplex, the 
+adapter MUST be forced to the same speed/duplex.
+
+
+Additional Configurations
+=========================
+
+  Configuring the Driver on Different Distributions
+  -------------------------------------------------
+
+  Configuring a network driver to load properly when the system is started is
+  distribution dependent. Typically, the configuration process involves adding
+  an alias line to /etc/modules.conf as well as editing other system startup 
+  scripts and/or configuration files. Many popular Linux distributions ship 
+  with tools to make these changes for you. To learn the proper way to 
+  configure a network device for your system, refer to your distribution 
+  documentation. If during this process you are asked for the driver or module 
+  name, the name for the Linux Base Driver for the Intel PRO/1000 Family of 
+  Adapters is e1000.
+
+  As an example, if you install the e1000 driver for two PRO/1000 adapters 
+  (eth0 and eth1) and set the speed and duplex to 10full and 100half, add the 
+  following to modules.conf:
+
+       alias eth0 e1000
+       alias eth1 e1000
+       options e1000 Speed=10,100 Duplex=2,1
+
+  Viewing Link Messages
+  ---------------------
+
+  Link messages will not be displayed to the console if the distribution is 
+  restricting system messages. In order to see network driver link messages on 
+  your console, set dmesg to eight by entering the following:
+
+       dmesg -n 8
+
+  NOTE: This setting is not saved across reboots.
+
+  Jumbo Frames
+  ------------
+
+  The driver supports Jumbo Frames for all adapters except 82542-based 
+  adapters. Jumbo Frames support is enabled by changing the MTU to a value 
+  larger than the default of 1500. Use the ifconfig command to increase the 
+  MTU size. For example:
+
+        ifconfig ethx mtu 9000 up
+
+  The maximum MTU setting for Jumbo Frames is 16110. This value coincides 
+  with the maximum Jumbo Frames size of 16128.
+
+  NOTE: Jumbo Frames are supported at 1000 Mbps only. Using Jumbo Frames at 
+  10 or 100 Mbps may result in poor performance or loss of link.
+
+
+  NOTE: MTU designates the frame size. To enable Jumbo Frames, increase the
+  MTU size on the interface beyond 1500.
+
+  Ethtool
+  -------
+
+  The driver utilizes the ethtool interface for driver configuration and
+  diagnostics, as well as displaying statistical information.  Ethtool
+  version 1.6 or later is required for this functionality.
+
+  The latest release of ethtool can be found from
+  http://sf.net/projects/gkernel.  
+
+  NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support 
+  for a more complete ethtool feature set can be enabled by upgrading 
+  ethtool to ethtool-1.8.1. 
+
+  Enabling Wake on LAN* (WoL)
+  ---------------------------
+
+  WoL is configured through the Ethtool* utility. Ethtool is included with
+  all versions of Red Hat after Red Hat 7.2. For other Linux distributions, 
+  download and install Ethtool from the following website: 
+  http://sourceforge.net/projects/gkernel.
+
+  For instructions on enabling WoL with Ethtool, refer to the website listed 
+  above.
+
+  WoL will be enabled on the system during the next shut down or reboot. 
+  For this driver version, in order to enable WoL, the e1000 driver must be 
+  loaded when shutting down or rebooting the system.
+
+  NAPI
+  ----
+
+  NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
+  or disabled based on the configuration of the kernel. 
+
+  See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
+
+
+Known Issues
+============
+
+  Jumbo Frames System Requirement
+  -------------------------------
+
+  Memory allocation failures have been observed on Linux systems with 64 MB 
+  of RAM or less that are running Jumbo Frames. If you are using Jumbo Frames,
+  your system may require more than the advertised minimum requirement of 64 MB
+  of system memory.
+
+
+Support
+=======
+
+For general information, go to the Intel support website at:
+
+    http://support.intel.com
+
+If an issue is identified with the released source code on the supported
+kernel with a supported adapter, email the specific information related to 
+the issue to linux.nics@intel.com.
+
+
+License
+=======
+
+This software program is released under the terms of a license agreement 
+between you ('Licensee') and Intel. Do not use or load this software or any 
+associated materials (collectively, the 'Software') until you have carefully 
+read the full terms and conditions of the LICENSE located in this software 
+package. By loading or using the Software, you agree to the terms of this 
+Agreement. If you do not agree with the terms of this Agreement, do not 
+install or use the Software.
+
+* Other names and brands may be claimed as the property of others.
diff --git a/Documentation/networking/eql.txt b/Documentation/networking/eql.txt
new file mode 100644
index 00000000000..0f1550150f0
--- /dev/null
+++ b/Documentation/networking/eql.txt
@@ -0,0 +1,528 @@
+  EQL Driver: Serial IP Load Balancing HOWTO
+  Simon "Guru Aleph-Null" Janes, simon@ncm.com
+  v1.1, February 27, 1995
+
+  This is the manual for the EQL device driver. EQL is a software device
+  that lets you load-balance IP serial links (SLIP or uncompressed PPP)
+  to increase your bandwidth. It will not reduce your latency (i.e. ping
+  times) except in the case where you already have lots of traffic on
+  your link, in which it will help them out. This driver has been tested
+  with the 1.1.75 kernel, and is known to have patched cleanly with
+  1.1.86.  Some testing with 1.1.92 has been done with the v1.1 patch
+  which was only created to patch cleanly in the very latest kernel
+  source trees. (Yes, it worked fine.)
+
+  1.  Introduction
+
+  Which is worse? A huge fee for a 56K leased line or two phone lines?
+  It's probably the former.  If you find yourself craving more bandwidth,
+  and have a ISP that is flexible, it is now possible to bind modems
+  together to work as one point-to-point link to increase your
+  bandwidth.  All without having to have a special black box on either
+  side.
+
+
+  The eql driver has only been tested with the Livingston PortMaster-2e
+  terminal server. I do not know if other terminal servers support load-
+  balancing, but I do know that the PortMaster does it, and does it
+  almost as well as the eql driver seems to do it (-- Unfortunately, in
+  my testing so far, the Livingston PortMaster 2e's load-balancing is a
+  good 1 to 2 KB/s slower than the test machine working with a 28.8 Kbps
+  and 14.4 Kbps connection.  However, I am not sure that it really is
+  the PortMaster, or if it's Linux's TCP drivers. I'm told that Linux's
+  TCP implementation is pretty fast though.--)
+
+
+  I suggest to ISPs out there that it would probably be fair to charge
+  a load-balancing client 75% of the cost of the second line and 50% of
+  the cost of the third line etc...
+
+
+  Hey, we can all dream you know...
+
+
+  2.  Kernel Configuration
+
+  Here I describe the general steps of getting a kernel up and working
+  with the eql driver.  From patching, building, to installing.
+
+
+  2.1.  Patching The Kernel
+
+  If you do not have or cannot get a copy of the kernel with the eql
+  driver folded into it, get your copy of the driver from
+  ftp://slaughter.ncm.com/pub/Linux/LOAD_BALANCING/eql-1.1.tar.gz.
+  Unpack this archive someplace obvious like /usr/local/src/.  It will
+  create the following files:
+
+
+
+       ______________________________________________________________________
+       -rw-r--r-- guru/ncm      198 Jan 19 18:53 1995 eql-1.1/NO-WARRANTY
+       -rw-r--r-- guru/ncm      30620 Feb 27 21:40 1995 eql-1.1/eql-1.1.patch
+       -rwxr-xr-x guru/ncm      16111 Jan 12 22:29 1995 eql-1.1/eql_enslave
+       -rw-r--r-- guru/ncm      2195 Jan 10 21:48 1995 eql-1.1/eql_enslave.c
+       ______________________________________________________________________
+
+  Unpack a recent kernel (something after 1.1.92) someplace convenient
+  like say /usr/src/linux-1.1.92.eql. Use symbolic links to point
+  /usr/src/linux to this development directory.
+
+
+  Apply the patch by running the commands:
+
+
+       ______________________________________________________________________
+       cd /usr/src
+       patch </usr/local/src/eql-1.1/eql-1.1.patch
+       ______________________________________________________________________
+
+
+
+
+
+  2.2.  Building The Kernel
+
+  After patching the kernel, run make config and configure the kernel
+  for your hardware.
+
+
+  After configuration, make and install according to your habit.
+
+
+  3.  Network Configuration
+
+  So far, I have only used the eql device with the DSLIP SLIP connection
+  manager by Matt Dillon (-- "The man who sold his soul to code so much
+  so quickly."--) .  How you configure it for other "connection"
+  managers is up to you.  Most other connection managers that I've seen
+  don't do a very good job when it comes to handling more than one
+  connection.
+
+
+  3.1.  /etc/rc.d/rc.inet1
+
+  In rc.inet1, ifconfig the eql device to the IP address you usually use
+  for your machine, and the MTU you prefer for your SLIP lines. One
+  could argue that MTU should be roughly half the usual size for two
+  modems, one-third for three, one-fourth for four, etc...  But going
+  too far below 296 is probably overkill. Here is an example ifconfig
+  command that sets up the eql device:
+
+
+
+       ______________________________________________________________________
+       ifconfig eql 198.67.33.239 mtu 1006
+       ______________________________________________________________________
+
+
+
+
+
+  Once the eql device is up and running, add a static default route to
+  it in the routing table using the cool new route syntax that makes
+  life so much easier:
+
+
+
+       ______________________________________________________________________
+       route add default eql
+       ______________________________________________________________________
+
+
+  3.2.  Enslaving Devices By Hand
+
+  Enslaving devices by hand requires two utility programs: eql_enslave
+  and eql_emancipate (-- eql_emancipate hasn't been written because when
+  an enslaved device "dies", it is automatically taken out of the queue.
+  I haven't found a good reason to write it yet... other than for
+  completeness, but that isn't a good motivator is it?--)
+
+
+  The syntax for enslaving a device is "eql_enslave <master-name>
+  <slave-name> <estimated-bps>".  Here are some example enslavings:
+
+
+
+       ______________________________________________________________________
+       eql_enslave eql sl0 28800
+       eql_enslave eql ppp0 14400
+       eql_enslave eql sl1 57600
+       ______________________________________________________________________
+
+
+
+
+
+  When you want to free a device from its life of slavery, you can
+  either down the device with ifconfig (eql will automatically bury the
+  dead slave and remove it from its queue) or use eql_emancipate to free
+  it. (-- Or just ifconfig it down, and the eql driver will take it out
+  for you.--)
+
+
+
+       ______________________________________________________________________
+       eql_emancipate eql sl0
+       eql_emancipate eql ppp0
+       eql_emancipate eql sl1
+       ______________________________________________________________________
+
+
+
+
+
+  3.3.  DSLIP Configuration for the eql Device
+
+  The general idea is to bring up and keep up as many SLIP connections
+  as you need, automatically.
+
+
+  3.3.1.  /etc/slip/runslip.conf
+
+  Here is an example runslip.conf:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  ______________________________________________________________________
+  name          sl-line-1
+  enabled
+  baud          38400
+  mtu           576
+  ducmd         -e /etc/slip/dialout/cua2-288.xp -t 9
+  command        eql_enslave eql $interface 28800
+  address        198.67.33.239
+  line          /dev/cua2
+
+  name          sl-line-2
+  enabled
+  baud          38400
+  mtu           576
+  ducmd         -e /etc/slip/dialout/cua3-288.xp -t 9
+  command        eql_enslave eql $interface 28800
+  address        198.67.33.239
+  line          /dev/cua3
+  ______________________________________________________________________
+
+
+
+
+
+  3.4.  Using PPP and the eql Device
+
+  I have not yet done any load-balancing testing for PPP devices, mainly
+  because I don't have a PPP-connection manager like SLIP has with
+  DSLIP. I did find a good tip from LinuxNET:Billy for PPP performance:
+  make sure you have asyncmap set to something so that control
+  characters are not escaped.
+
+
+  I tried to fix up a PPP script/system for redialing lost PPP
+  connections for use with the eql driver the weekend of Feb 25-26 '95
+  (Hereafter known as the 8-hour PPP Hate Festival).  Perhaps later this
+  year.
+
+
+  4.  About the Slave Scheduler Algorithm
+
+  The slave scheduler probably could be replaced with a dozen other
+  things and push traffic much faster.  The formula in the current set
+  up of the driver was tuned to handle slaves with wildly different
+  bits-per-second "priorities".
+
+
+  All testing I have done was with two 28.8 V.FC modems, one connecting
+  at 28800 bps or slower, and the other connecting at 14400 bps all the
+  time.
+
+
+  One version of the scheduler was able to push 5.3 K/s through the
+  28800 and 14400 connections, but when the priorities on the links were
+  very wide apart (57600 vs. 14400) the "faster" modem received all
+  traffic and the "slower" modem starved.
+
+
+  5.  Testers' Reports
+
+  Some people have experimented with the eql device with newer
+  kernels (than 1.1.75).  I have since updated the driver to patch
+  cleanly in newer kernels because of the removal of the old "slave-
+  balancing" driver config option.
+
+
+  o  icee from LinuxNET patched 1.1.86 without any rejects and was able
+     to boot the kernel and enslave a couple of ISDN PPP links.
+
+  5.1.  Randolph Bentson's Test Report
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  From bentson@grieg.seaslug.org Wed Feb  8 19:08:09 1995
+  Date: Tue, 7 Feb 95 22:57 PST
+  From: Randolph Bentson <bentson@grieg.seaslug.org>
+  To: guru@ncm.com
+  Subject: EQL driver tests
+
+
+  I have been checking out your eql driver.  (Nice work, that!)
+  Although you may already done this performance testing, here
+  are some data I've discovered.
+
+  Randolph Bentson
+  bentson@grieg.seaslug.org
+
+  ---------------------------------------------------------
+
+
+  A pseudo-device driver, EQL, written by Simon Janes, can be used
+  to bundle multiple SLIP connections into what appears to be a
+  single connection.  This allows one to improve dial-up network
+  connectivity gradually, without having to buy expensive DSU/CSU
+  hardware and services.
+
+  I have done some testing of this software, with two goals in
+  mind: first, to ensure it actually works as described and
+  second, as a method of exercising my device driver.
+
+  The following performance measurements were derived from a set
+  of SLIP connections run between two Linux systems (1.1.84) using
+  a 486DX2/66 with a Cyclom-8Ys and a 486SLC/40 with a Cyclom-16Y.
+  (Ports 0,1,2,3 were used.  A later configuration will distribute
+  port selection across the different Cirrus chips on the boards.)
+  Once a link was established, I timed a binary ftp transfer of
+  289284 bytes of data. If there were no overhead (packet headers,
+  inter-character and inter-packet delays, etc.) the transfers
+  would take the following times:
+
+      bits/sec  seconds
+      345600    8.3
+      234600    12.3
+      172800    16.7
+      153600    18.8
+      76800     37.6
+      57600     50.2
+      38400     75.3
+      28800     100.4
+      19200     150.6
+      9600      301.3
+
+  A single line running at the lower speeds and with large packets
+  comes to within 2% of this.  Performance is limited for the higher
+  speeds (as predicted by the Cirrus databook) to an aggregate of
+  about 160 kbits/sec.  The next round of testing will distribute
+  the load across two or more Cirrus chips.
+
+  The good news is that one gets nearly the full advantage of the
+  second, third, and fourth line's bandwidth.  (The bad news is
+  that the connection establishment seemed fragile for the higher
+  speeds.  Once established, the connection seemed robust enough.)
+
+  #lines  speed mtu  seconds    theory  actual  %of
+         kbit/sec      duration speed   speed   max
+  3     115200  900     _       345600
+  3     115200  400     18.1    345600  159825  46
+  2     115200  900     _       230400
+  2     115200  600     18.1    230400  159825  69
+  2     115200  400     19.3    230400  149888  65
+  4     57600   900     _       234600
+  4     57600   600     _       234600
+  4     57600   400     _       234600
+  3     57600   600     20.9    172800  138413  80
+  3     57600   900     21.2    172800  136455  78
+  3     115200  600     21.7    345600  133311  38
+  3     57600   400     22.5    172800  128571  74
+  4     38400   900     25.2    153600  114795  74
+  4     38400   600     26.4    153600  109577  71
+  4     38400   400     27.3    153600  105965  68
+  2     57600   900     29.1    115200  99410.3 86
+  1     115200  900     30.7    115200  94229.3 81
+  2     57600   600     30.2    115200  95789.4 83
+  3     38400   900     30.3    115200  95473.3 82
+  3     38400   600     31.2    115200  92719.2 80
+  1     115200  600     31.3    115200  92423   80
+  2     57600   400     32.3    115200  89561.6 77
+  1     115200  400     32.8    115200  88196.3 76
+  3     38400   400     33.5    115200  86353.4 74
+  2     38400   900     43.7    76800   66197.7 86
+  2     38400   600     44      76800   65746.4 85
+  2     38400   400     47.2    76800   61289   79
+  4     19200   900     50.8    76800   56945.7 74
+  4     19200   400     53.2    76800   54376.7 70
+  4     19200   600     53.7    76800   53870.4 70
+  1     57600   900     54.6    57600   52982.4 91
+  1     57600   600     56.2    57600   51474   89
+  3     19200   900     60.5    57600   47815.5 83
+  1     57600   400     60.2    57600   48053.8 83
+  3     19200   600     62      57600   46658.7 81
+  3     19200   400     64.7    57600   44711.6 77
+  1     38400   900     79.4    38400   36433.8 94
+  1     38400   600     82.4    38400   35107.3 91
+  2     19200   900     84.4    38400   34275.4 89
+  1     38400   400     86.8    38400   33327.6 86
+  2     19200   600     87.6    38400   33023.3 85
+  2     19200   400     91.2    38400   31719.7 82
+  4     9600    900     94.7    38400   30547.4 79
+  4     9600    400     106     38400   27290.9 71
+  4     9600    600     110     38400   26298.5 68
+  3     9600    900     118     28800   24515.6 85
+  3     9600    600     120     28800   24107   83
+  3     9600    400     131     28800   22082.7 76
+  1     19200   900     155     19200   18663.5 97
+  1     19200   600     161     19200   17968   93
+  1     19200   400     170     19200   17016.7 88
+  2     9600    600     176     19200   16436.6 85
+  2     9600    900     180     19200   16071.3 83
+  2     9600    400     181     19200   15982.5 83
+  1     9600    900     305     9600    9484.72 98
+  1     9600    600     314     9600    9212.87 95
+  1     9600    400     332     9600    8713.37 90
+
+
+
+
+
+  5.2.  Anthony Healy's Report
+
+
+
+
+
+
+
+  Date: Mon, 13 Feb 1995 16:17:29 +1100 (EST)
+  From: Antony Healey <ahealey@st.nepean.uws.edu.au>
+  To: Simon Janes <guru@ncm.com>
+  Subject: Re: Load Balancing
+
+  Hi Simon,
+          I've installed your patch and it works great. I have trialed
+          it over twin SL/IP lines, just over null modems, but I was
+          able to data at over 48Kb/s [ISDN link -Simon]. I managed a
+          transfer of up to 7.5 Kbyte/s on one go, but averaged around
+          6.4 Kbyte/s, which I think is pretty cool.  :)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/Documentation/networking/ewrk3.txt b/Documentation/networking/ewrk3.txt
new file mode 100644
index 00000000000..90e9e5f16e6
--- /dev/null
+++ b/Documentation/networking/ewrk3.txt
@@ -0,0 +1,46 @@
+The EtherWORKS 3  driver in this distribution is  designed to  work with all
+kernels   >  1.1.33   (approx)  and  includes  tools   in  the  'ewrk3tools'
+subdirectory   to  allow  set   up of   the   card,  similar  to  the  MSDOS
+'NICSETUP.EXE' tools provided on  the DOS drivers  disk (type 'make' in that
+subdirectory to make the tools).
+
+The supported  cards are DE203,  DE204 and DE205.  All   other cards are NOT
+supported - refer to 'depca.c' for running the LANCE based network cards and
+'de4x5.c'  for the  DIGITAL   Semiconductor PCI  chip  based  adapters  from
+Digital.
+
+The ability to load  this driver as a  loadable module has been included and
+used extensively  during the driver  development (to save those  long reboot
+sequences). To utilise this ability, you have to do 8 things:
+
+    0) have a copy of the loadable modules code installed on your system.
+    1) copy ewrk3.c from the  /linux/drivers/net directory to your favourite
+    temporary directory.
+    2) edit the  source code near  line 1898 to reflect  the I/O address and
+    IRQ you're using.
+    3) compile  ewrk3.c, but include -DMODULE in  the command line to ensure
+    that the correct bits are compiled (see end of source code).
+    4) if you are wanting to add a new  card, goto 5. Otherwise, recompile a
+    kernel with the ewrk3 configuration turned off and reboot.
+    5) insmod ewrk3.o
+          [Alan Cox: Changed this so you can insmod ewrk3.o irq=x io=y]
+          [Adam Kropelin: Multiple cards now supported by irq=x1,x2 io=y1,y2]
+    6) run the net startup bits for your new eth?? interface manually 
+    (usually /etc/rc.inet[12] at boot time). 
+    7) enjoy!
+
+    Note that autoprobing is not allowed in loadable modules - the system is
+    already up and running and you're messing with interrupts.
+
+    To unload a module, turn off the associated interface 
+    'ifconfig eth?? down' then 'rmmod ewrk3'.
+
+The performance we've  achieved so far  has been measured through the 'ttcp'
+tool   at 975kB/s.  This  measures  the  total  TCP  stack performance which
+includes the   card,  so don't  expect   to get   much nearer  the  1.25MB/s
+theoretical Ethernet rate.
+
+
+Enjoy!
+
+Dave
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
new file mode 100644
index 00000000000..bbf2005270b
--- /dev/null
+++ b/Documentation/networking/filter.txt
@@ -0,0 +1,42 @@
+filter.txt: Linux Socket Filtering
+Written by: Jay Schulist <jschlst@samba.org>
+
+Introduction
+============
+
+        Linux Socket Filtering is derived from the Berkeley
+Packet Filter. There are some distinct differences between
+the BSD and Linux Kernel Filtering.
+
+Linux Socket Filtering (LSF) allows a user-space program to
+attach a filter onto any socket and allow or disallow certain
+types of data to come through the socket. LSF follows exactly
+the same filter code structure as the BSD Berkeley Packet Filter
+(BPF), so referring to the BSD bpf.4 manpage is very helpful in
+creating filters.
+
+LSF is much simpler than BPF. One does not have to worry about
+devices or anything like that. You simply create your filter
+code, send it to the kernel via the SO_ATTACH_FILTER ioctl and
+if your filter code passes the kernel check on it, you then
+immediately begin filtering data on that socket.
+
+You can also detach filters from your socket via the
+SO_DETACH_FILTER ioctl. This will probably not be used much
+since when you close a socket that has a filter on it the
+filter is automagically removed. The other less common case
+may be adding a different filter on the same socket where you had another
+filter that is still running: the kernel takes care of removing
+the old one and placing your new one in its place, assuming your
+filter has passed the checks, otherwise if it fails the old filter
+will remain on that socket.
+
+Examples
+========
+
+Ioctls-
+setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter));
+setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value));
+
+See the BSD bpf.4 manpage and the BSD Packet Filter paper written by
+Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory.
diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt
new file mode 100644
index 00000000000..b1f337f0f4c
--- /dev/null
+++ b/Documentation/networking/fore200e.txt
@@ -0,0 +1,66 @@
+
+FORE Systems PCA-200E/SBA-200E ATM NIC driver
+---------------------------------------------
+
+This driver adds support for the FORE Systems 200E-series ATM adapters
+to the Linux operating system. It is based on the earlier PCA-200E driver
+written by Uwe Dannowski.
+
+The driver simultaneously supports PCA-200E and SBA-200E adapters on
+i386, alpha (untested), powerpc, sparc and sparc64 archs.
+
+The intent is to enable the use of different models of FORE adapters at the
+same time, by hosts that have several bus interfaces (such as PCI+SBUS,
+PCI+MCA or PCI+EISA).
+
+Only PCI and SBUS devices are currently supported by the driver, but support
+for other bus interfaces such as EISA should not be too hard to add (this may
+be more tricky for the MCA bus, though, as FORE made some MCA-specific
+modifications to the adapter's AALI interface).
+
+
+Firmware Copyright Notice
+-------------------------
+
+Please read the fore200e_firmware_copyright file present
+in the linux/drivers/atm directory for details and restrictions.
+
+
+Firmware Updates
+----------------
+
+The FORE Systems 200E-series driver is shipped with firmware data being 
+uploaded to the ATM adapters at system boot time or at module loading time. 
+The supplied firmware images should work with all adapters.
+
+However, if you encounter problems (the firmware doesn't start or the driver
+is unable to read the PROM data), you may consider trying another firmware
+version. Alternative binary firmware images can be found somewhere on the
+ForeThought CD-ROM supplied with your adapter by FORE Systems.
+
+You can also get the latest firmware images from FORE Systems at
+http://www.fore.com. Register TACTics Online and go to
+the 'software updates' pages. The firmware binaries are part of
+the various ForeThought software distributions.
+
+Notice that different versions of the PCA-200E firmware exist, depending
+on the endianess of the host architecture. The driver is shipped with
+both little and big endian PCA firmware images.
+
+Name and location of the new firmware images can be set at kernel
+configuration time:
+
+1. Copy the new firmware binary files (with .bin, .bin1 or .bin2 suffix)
+   to some directory, such as linux/drivers/atm.
+
+2. Reconfigure your kernel to set the new firmware name and location.
+   Expected pathnames are absolute or relative to the drivers/atm directory.
+
+3. Rebuild and re-install your kernel or your module.
+
+
+Feedback
+--------
+
+Feedback is welcome. Please send success stories/bug reports/
+patches/improvement/comments/flames to <lizzi@cnam.fr>.
diff --git a/Documentation/networking/framerelay.txt b/Documentation/networking/framerelay.txt
new file mode 100644
index 00000000000..1a0b720440d
--- /dev/null
+++ b/Documentation/networking/framerelay.txt
@@ -0,0 +1,39 @@
+Frame Relay (FR) support for linux is built into a two tiered system of device 
+drivers.  The upper layer implements RFC1490 FR specification, and uses the
+Data Link Connection Identifier (DLCI) as its hardware address.  Usually these
+are assigned by your network supplier, they give you the number/numbers of
+the Virtual Connections (VC) assigned to you.
+
+Each DLCI is a point-to-point link between your machine and a remote one.
+As such, a separate device is needed to accommodate the routing.  Within the
+net-tools archives is 'dlcicfg'.  This program will communicate with the
+base "DLCI" device, and create new net devices named 'dlci00', 'dlci01'... 
+The configuration script will ask you how many DLCIs you need, as well as
+how many DLCIs you want to assign to each Frame Relay Access Device (FRAD).
+
+The DLCI uses a number of function calls to communicate with the FRAD, all
+of which are stored in the FRAD's private data area.  assoc/deassoc, 
+activate/deactivate and dlci_config.  The DLCI supplies a receive function
+to the FRAD to accept incoming packets.
+
+With this initial offering, only 1 FRAD driver is available.  With many thanks
+to Sangoma Technologies, David Mandelstam & Gene Kozin, the S502A, S502E & 
+S508 are supported.  This driver is currently set up for only FR, but as 
+Sangoma makes more firmware modules available, it can be updated to provide
+them as well.
+
+Configuration of the FRAD makes use of another net-tools program, 'fradcfg'.
+This program makes use of a configuration file (which dlcicfg can also read)
+to specify the types of boards to be configured as FRADs, as well as perform
+any board specific configuration.  The Sangoma module of fradcfg loads the
+FR firmware into the card, sets the irq/port/memory information, and provides
+an initial configuration.
+
+Additional FRAD device drivers can be added as hardware is available.
+
+At this time, the dlcicfg and fradcfg programs have not been incorporated into
+the net-tools distribution.  They can be found at ftp.invlogic.com, in 
+/pub/linux.  Note that with OS/2 FTPD, you end up in /pub by default, so just
+use 'cd linux'.  v0.10 is for use on pre-2.0.3 and earlier, v0.15 is for 
+pre-2.0.4 and later.
+
diff --git a/Documentation/networking/gen_stats.txt b/Documentation/networking/gen_stats.txt
new file mode 100644
index 00000000000..c3297f79c13
--- /dev/null
+++ b/Documentation/networking/gen_stats.txt
@@ -0,0 +1,117 @@
+Generic networking statistics for netlink users
+======================================================================
+
+Statistic counters are grouped into structs:
+
+Struct               TLV type              Description
+----------------------------------------------------------------------
+gnet_stats_basic     TCA_STATS_BASIC       Basic statistics
+gnet_stats_rate_est  TCA_STATS_RATE_EST    Rate estimator
+gnet_stats_queue     TCA_STATS_QUEUE       Queue statistics
+none                 TCA_STATS_APP         Application specific
+
+
+Collecting:
+-----------
+
+Declare the statistic structs you need:
+struct mystruct {
+        struct gnet_stats_basic bstats;
+        struct gnet_stats_queue qstats;
+        ...
+};
+
+Update statistics:
+mystruct->tstats.packet++;
+mystruct->qstats.backlog += skb->pkt_len;
+
+
+Export to userspace (Dump):
+---------------------------
+
+my_dumping_routine(struct sk_buff *skb, ...)
+{
+        struct gnet_dump dump;
+
+        if (gnet_stats_start_copy(skb, TCA_STATS2, &mystruct->lock, &dump) < 0)
+                goto rtattr_failure;
+
+        if (gnet_stats_copy_basic(&dump, &mystruct->bstats) < 0 ||
+            gnet_stats_copy_queue(&dump, &mystruct->qstats) < 0 ||
+                gnet_stats_copy_app(&dump, &xstats, sizeof(xstats)) < 0)
+                goto rtattr_failure;
+
+        if (gnet_stats_finish_copy(&dump) < 0)
+                goto rtattr_failure;
+        ...
+}
+
+TCA_STATS/TCA_XSTATS backward compatibility:
+--------------------------------------------
+
+Prior users of struct tc_stats and xstats can maintain backward
+compatibility by calling the compat wrappers to keep providing the
+existing TLV types.
+
+my_dumping_routine(struct sk_buff *skb, ...)
+{
+    if (gnet_stats_start_copy_compat(skb, TCA_STATS2, TCA_STATS,
+                TCA_XSTATS, &mystruct->lock, &dump) < 0)
+                goto rtattr_failure;
+        ...
+}
+
+A struct tc_stats will be filled out during gnet_stats_copy_* calls
+and appended to the skb. TCA_XSTATS is provided if gnet_stats_copy_app
+was called.
+
+
+Locking:
+--------
+
+Locks are taken before writing and released once all statistics have
+been written. Locks are always released in case of an error. You
+are responsible for making sure that the lock is initialized.
+
+
+Rate Estimator:
+--------------
+
+0) Prepare an estimator attribute. Most likely this would be in user
+   space. The value of this TLV should contain a tc_estimator structure.
+   As usual, such a TLV nees to be 32 bit aligned and therefore the
+   length needs to be appropriately set etc. The estimator interval
+   and ewma log need to be converted to the appropriate values.
+   tc_estimator.c::tc_setup_estimator() is advisable to be used as the
+   conversion routine. It does a few clever things. It takes a time
+   interval in microsecs, a time constant also in microsecs and a struct
+   tc_estimator to  be populated. The returned tc_estimator can be
+   transported to the kernel.  Transfer such a structure in a TLV of type
+   TCA_RATE to your code in the kernel.
+
+In the kernel when setting up:
+1) make sure you have basic stats and rate stats setup first.
+2) make sure you have initialized stats lock that is used to setup such
+   stats.
+3) Now initialize a new estimator:
+
+   int ret = gen_new_estimator(my_basicstats,my_rate_est_stats,
+       mystats_lock, attr_with_tcestimator_struct);
+
+   if ret == 0
+       success
+   else
+       failed
+
+From now on, everytime you dump my_rate_est_stats it will contain
+uptodate info.
+
+Once you are done, call gen_kill_estimator(my_basicstats,
+my_rate_est_stats) Make sure that my_basicstats and my_rate_est_stats
+are still valid (i.e still exist) at the time of making this call.
+
+
+Authors:
+--------
+Thomas Graf <tgraf@suug.ch>
+Jamal Hadi Salim <hadi@cyberus.ca>
diff --git a/Documentation/networking/generic-hdlc.txt b/Documentation/networking/generic-hdlc.txt
new file mode 100644
index 00000000000..7d1dc6b884f
--- /dev/null
+++ b/Documentation/networking/generic-hdlc.txt
@@ -0,0 +1,131 @@
+Generic HDLC layer
+Krzysztof Halasa <khc@pm.waw.pl>
+January, 2003
+
+
+Generic HDLC layer currently supports:
+- Frame Relay (ANSI, CCITT and no LMI), with ARP support (no InARP).
+  Normal (routed) and Ethernet-bridged (Ethernet device emulation)
+  interfaces can share a single PVC.
+- raw HDLC - either IP (IPv4) interface or Ethernet device emulation.
+- Cisco HDLC,
+- PPP (uses syncppp.c),
+- X.25 (uses X.25 routines).
+
+There are hardware drivers for the following cards:
+- C101 by Moxa Technologies Co., Ltd.
+- RISCom/N2 by SDL Communications Inc.
+- and others, some not in the official kernel.
+
+Ethernet device emulation (using HDLC or Frame-Relay PVC) is compatible
+with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging).
+
+
+Make sure the hdlc.o and the hardware driver are loaded. It should
+create a number of "hdlc" (hdlc0 etc) network devices, one for each
+WAN port. You'll need the "sethdlc" utility, get it from:
+        http://hq.pm.waw.pl/hdlc/
+
+Compile sethdlc.c utility:
+        gcc -O2 -Wall -o sethdlc sethdlc.c
+Make sure you're using a correct version of sethdlc for your kernel.
+
+Use sethdlc to set physical interface, clock rate, HDLC mode used,
+and add any required PVCs if using Frame Relay.
+Usually you want something like:
+
+        sethdlc hdlc0 clock int rate 128000
+        sethdlc hdlc0 cisco interval 10 timeout 25
+or
+        sethdlc hdlc0 rs232 clock ext
+        sethdlc hdlc0 fr lmi ansi
+        sethdlc hdlc0 create 99
+        ifconfig hdlc0 up
+        ifconfig pvc0 localIP pointopoint remoteIP
+
+In Frame Relay mode, ifconfig master hdlc device up (without assigning
+any IP address to it) before using pvc devices.
+
+
+Setting interface:
+
+* v35 | rs232 | x21 | t1 | e1 - sets physical interface for a given port
+                                if the card has software-selectable interfaces
+  loopback - activate hardware loopback (for testing only)
+* clock ext - external clock (uses DTE RX and TX clock)
+* clock int - internal clock (provides clock signal on DCE clock output)
+* clock txint - TX internal, RX external (provides TX clock on DCE output)
+* clock txfromrx - TX clock derived from RX clock (TX clock on DCE output)
+* rate - sets clock rate in bps (not required for external clock or
+                                 for txfromrx)
+
+Setting protocol:
+
+* hdlc - sets raw HDLC (IP-only) mode
+  nrz / nrzi / fm-mark / fm-space / manchester - sets transmission code
+  no-parity / crc16 / crc16-pr0 (CRC16 with preset zeros) / crc32-itu
+  crc16-itu (CRC16 with ITU-T polynomial) / crc16-itu-pr0 - sets parity
+
+* hdlc-eth - Ethernet device emulation using HDLC. Parity and encoding
+  as above.
+
+* cisco - sets Cisco HDLC mode (IP, IPv6 and IPX supported)
+  interval - time in seconds between keepalive packets
+  timeout - time in seconds after last received keepalive packet before
+            we assume the link is down
+
+* ppp - sets synchronous PPP mode
+
+* x25 - sets X.25 mode
+
+* fr - Frame Relay mode
+  lmi ansi / ccitt / none - LMI (link management) type
+  dce - Frame Relay DCE (network) side LMI instead of default DTE (user).
+  It has nothing to do with clocks!
+  t391 - link integrity verification polling timer (in seconds) - user
+  t392 - polling verification timer (in seconds) - network
+  n391 - full status polling counter - user
+  n392 - error threshold - both user and network
+  n393 - monitored events count - both user and network
+
+Frame-Relay only:
+* create n | delete n - adds / deletes PVC interface with DLCI #n.
+  Newly created interface will be named pvc0, pvc1 etc.
+
+* create ether n | delete ether n - adds a device for Ethernet-bridged
+  frames. The device will be named pvceth0, pvceth1 etc.
+
+
+
+
+Board-specific issues
+---------------------
+
+n2.o and c101.o need parameters to work:
+
+        insmod n2 hw=io,irq,ram,ports[:io,irq,...]
+example:
+        insmod n2 hw=0x300,10,0xD0000,01
+
+or
+        insmod c101 hw=irq,ram[:irq,...]
+example:
+        insmod c101 hw=9,0xdc000
+
+If built into the kernel, these drivers need kernel (command line) parameters:
+        n2.hw=io,irq,ram,ports:...
+or
+        c101.hw=irq,ram:...
+
+
+
+If you have a problem with N2 or C101 card, you can issue the "private"
+command to see port's packet descriptor rings (in kernel logs):
+
+        sethdlc hdlc0 private
+
+The hardware driver has to be build with CONFIG_HDLC_DEBUG_RINGS.
+Attaching this info to bug reports would be helpful. Anyway, let me know
+if you have problems using this.
+
+For patches and other info look at http://hq.pm.waw.pl/hdlc/
diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c
new file mode 100644
index 00000000000..f315d20d386
--- /dev/null
+++ b/Documentation/networking/ifenslave.c
@@ -0,0 +1,1110 @@
+/* Mode: C;
+ * ifenslave.c: Configure network interfaces for parallel routing.
+ *
+ *      This program controls the Linux implementation of running multiple
+ *      network interfaces in parallel.
+ *
+ * Author:      Donald Becker <becker@cesdis.gsfc.nasa.gov>
+ *              Copyright 1994-1996 Donald Becker
+ *
+ *              This program is free software; you can redistribute it
+ *              and/or modify it under the terms of the GNU General Public
+ *              License as published by the Free Software Foundation.
+ *
+ *      The author may be reached as becker@CESDIS.gsfc.nasa.gov, or C/O
+ *      Center of Excellence in Space Data and Information Sciences
+ *         Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771
+ *
+ *  Changes :
+ *    - 2000/10/02 Willy Tarreau <willy at meta-x.org> :
+ *       - few fixes. Master's MAC address is now correctly taken from
+ *         the first device when not previously set ;
+ *       - detach support : call BOND_RELEASE to detach an enslaved interface.
+ *       - give a mini-howto from command-line help : # ifenslave -h
+ *
+ *    - 2001/02/16 Chad N. Tindel <ctindel at ieee dot org> :
+ *       - Master is now brought down before setting the MAC address.  In
+ *         the 2.4 kernel you can't change the MAC address while the device is
+ *         up because you get EBUSY.
+ *
+ *    - 2001/09/13 Takao Indoh <indou dot takao at jp dot fujitsu dot com>
+ *       - Added the ability to change the active interface on a mode 1 bond
+ *         at runtime.
+ *
+ *    - 2001/10/23 Chad N. Tindel <ctindel at ieee dot org> :
+ *       - No longer set the MAC address of the master.  The bond device will
+ *         take care of this itself
+ *       - Try the SIOC*** versions of the bonding ioctls before using the
+ *         old versions
+ *    - 2002/02/18 Erik Habbinga <erik_habbinga @ hp dot com> :
+ *       - ifr2.ifr_flags was not initialized in the hwaddr_notset case,
+ *         SIOCGIFFLAGS now called before hwaddr_notset test
+ *
+ *    - 2002/10/31 Tony Cureington <tony.cureington * hp_com> :
+ *       - If the master does not have a hardware address when the first slave
+ *         is enslaved, the master is assigned the hardware address of that
+ *         slave - there is a comment in bonding.c stating "ifenslave takes
+ *         care of this now." This corrects the problem of slaves having
+ *         different hardware addresses in active-backup mode when
+ *         multiple interfaces are specified on a single ifenslave command
+ *         (ifenslave bond0 eth0 eth1).
+ *
+ *    - 2003/03/18 - Tsippy Mendelson <tsippy.mendelson at intel dot com> and
+ *                   Shmulik Hen <shmulik.hen at intel dot com>
+ *       - Moved setting the slave's mac address and openning it, from
+ *         the application to the driver. This enables support of modes
+ *         that need to use the unique mac address of each slave.
+ *         The driver also takes care of closing the slave and restoring its
+ *         original mac address upon release.
+ *         In addition, block possibility of enslaving before the master is up.
+ *         This prevents putting the system in an undefined state.
+ *
+ *    - 2003/05/01 - Amir Noam <amir.noam at intel dot com>
+ *       - Added ABI version control to restore compatibility between
+ *         new/old ifenslave and new/old bonding.
+ *       - Prevent adding an adapter that is already a slave.
+ *         Fixes the problem of stalling the transmission and leaving
+ *         the slave in a down state.
+ *
+ *    - 2003/05/01 - Shmulik Hen <shmulik.hen at intel dot com>
+ *       - Prevent enslaving if the bond device is down.
+ *         Fixes the problem of leaving the system in unstable state and
+ *         halting when trying to remove the module.
+ *       - Close socket on all abnormal exists.
+ *       - Add versioning scheme that follows that of the bonding driver.
+ *         current version is 1.0.0 as a base line.
+ *
+ *    - 2003/05/22 - Jay Vosburgh <fubar at us dot ibm dot com>
+ *       - ifenslave -c was broken; it's now fixed
+ *       - Fixed problem with routes vanishing from master during enslave
+ *         processing.
+ *
+ *    - 2003/05/27 - Amir Noam <amir.noam at intel dot com>
+ *       - Fix backward compatibility issues:
+ *         For drivers not using ABI versions, slave was set down while
+ *         it should be left up before enslaving.
+ *         Also, master was not set down and the default set_mac_address()
+ *         would fail and generate an error message in the system log.
+ *       - For opt_c: slave should not be set to the master's setting
+ *         while it is running. It was already set during enslave. To
+ *         simplify things, it is now handeled separately.
+ *
+ *    - 2003/12/01 - Shmulik Hen <shmulik.hen at intel dot com>
+ *       - Code cleanup and style changes
+ *         set version to 1.1.0
+ */
+
+#define APP_VERSION     "1.1.0"
+#define APP_RELDATE     "December 1, 2003"
+#define APP_NAME        "ifenslave"
+
+static char *version =
+APP_NAME ".c:v" APP_VERSION " (" APP_RELDATE ")\n"
+"o Donald Becker (becker@cesdis.gsfc.nasa.gov).\n"
+"o Detach support added on 2000/10/02 by Willy Tarreau (willy at meta-x.org).\n"
+"o 2.4 kernel support added on 2001/02/16 by Chad N. Tindel\n"
+"  (ctindel at ieee dot org).\n";
+
+static const char *usage_msg =
+"Usage: ifenslave [-f] <master-if> <slave-if> [<slave-if>...]\n"
+"       ifenslave -d   <master-if> <slave-if> [<slave-if>...]\n"
+"       ifenslave -c   <master-if> <slave-if>\n"
+"       ifenslave --help\n";
+
+static const char *help_msg =
+"\n"
+"       To create a bond device, simply follow these three steps :\n"
+"       - ensure that the required drivers are properly loaded :\n"
+"         # modprobe bonding ; modprobe <3c59x|eepro100|pcnet32|tulip|...>\n"
+"       - assign an IP address to the bond device :\n"
+"         # ifconfig bond0 <addr> netmask <mask> broadcast <bcast>\n"
+"       - attach all the interfaces you need to the bond device :\n"
+"         # ifenslave [{-f|--force}] bond0 eth0 [eth1 [eth2]...]\n"
+"         If bond0 didn't have a MAC address, it will take eth0's. Then, all\n"
+"         interfaces attached AFTER this assignment will get the same MAC addr.\n"
+"         (except for ALB/TLB modes)\n"
+"\n"
+"       To set the bond device down and automatically release all the slaves :\n"
+"         # ifconfig bond0 down\n"
+"\n"
+"       To detach a dead interface without setting the bond device down :\n"
+"         # ifenslave {-d|--detach} bond0 eth0 [eth1 [eth2]...]\n"
+"\n"
+"       To change active slave :\n"
+"         # ifenslave {-c|--change-active} bond0 eth0\n"
+"\n"
+"       To show master interface info\n"
+"         # ifenslave bond0\n"
+"\n"
+"       To show all interfaces info\n"
+"       # ifenslave {-a|--all-interfaces}\n"
+"\n"
+"       To be more verbose\n"
+"       # ifenslave {-v|--verbose} ...\n"
+"\n"
+"       # ifenslave {-u|--usage}   Show usage\n"
+"       # ifenslave {-V|--version} Show version\n"
+"       # ifenslave {-h|--help}    This message\n"
+"\n";
+
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <ctype.h>
+#include <string.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <getopt.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <sys/ioctl.h>
+#include <linux/if.h>
+#include <net/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/if_bonding.h>
+#include <linux/sockios.h>
+
+typedef unsigned long long u64; /* hack, so we may include kernel's ethtool.h */
+typedef __uint32_t u32;         /* ditto */
+typedef __uint16_t u16;         /* ditto */
+typedef __uint8_t u8;           /* ditto */
+#include <linux/ethtool.h>
+
+struct option longopts[] = {
+        /* { name  has_arg  *flag  val } */
+        {"all-interfaces",      0, 0, 'a'},     /* Show all interfaces. */
+        {"change-active",       0, 0, 'c'},     /* Change the active slave.  */
+        {"detach",              0, 0, 'd'},     /* Detach a slave interface. */
+        {"force",               0, 0, 'f'},     /* Force the operation. */
+        {"help",                0, 0, 'h'},     /* Give help */
+        {"usage",               0, 0, 'u'},     /* Give usage */
+        {"verbose",             0, 0, 'v'},     /* Report each action taken. */
+        {"version",             0, 0, 'V'},     /* Emit version information. */
+        { 0, 0, 0, 0}
+};
+
+/* Command-line flags. */
+unsigned int
+opt_a = 0,      /* Show-all-interfaces flag. */
+opt_c = 0,      /* Change-active-slave flag. */
+opt_d = 0,      /* Detach a slave interface. */
+opt_f = 0,      /* Force the operation. */
+opt_h = 0,      /* Help */
+opt_u = 0,      /* Usage */
+opt_v = 0,      /* Verbose flag. */
+opt_V = 0;      /* Version */
+
+int skfd = -1;          /* AF_INET socket for ioctl() calls.*/
+int abi_ver = 0;        /* userland - kernel ABI version */
+int hwaddr_set = 0;     /* Master's hwaddr is set */
+int saved_errno;
+
+struct ifreq master_mtu, master_flags, master_hwaddr;
+struct ifreq slave_mtu, slave_flags, slave_hwaddr;
+
+struct dev_ifr {
+        struct ifreq *req_ifr;
+        char *req_name;
+        int req_type;
+};
+
+struct dev_ifr master_ifra[] = {
+        {&master_mtu,     "SIOCGIFMTU",     SIOCGIFMTU},
+        {&master_flags,   "SIOCGIFFLAGS",   SIOCGIFFLAGS},
+        {&master_hwaddr,  "SIOCGIFHWADDR",  SIOCGIFHWADDR},
+        {NULL, "", 0}
+};
+
+struct dev_ifr slave_ifra[] = {
+        {&slave_mtu,     "SIOCGIFMTU",     SIOCGIFMTU},
+        {&slave_flags,   "SIOCGIFFLAGS",   SIOCGIFFLAGS},
+        {&slave_hwaddr,  "SIOCGIFHWADDR",  SIOCGIFHWADDR},
+        {NULL, "", 0}
+};
+
+static void if_print(char *ifname);
+static int get_drv_info(char *master_ifname);
+static int get_if_settings(char *ifname, struct dev_ifr ifra[]);
+static int get_slave_flags(char *slave_ifname);
+static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr);
+static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr);
+static int set_slave_mtu(char *slave_ifname, int mtu);
+static int set_if_flags(char *ifname, short flags);
+static int set_if_up(char *ifname, short flags);
+static int set_if_down(char *ifname, short flags);
+static int clear_if_addr(char *ifname);
+static int set_if_addr(char *master_ifname, char *slave_ifname);
+static int change_active(char *master_ifname, char *slave_ifname);
+static int enslave(char *master_ifname, char *slave_ifname);
+static int release(char *master_ifname, char *slave_ifname);
+#define v_print(fmt, args...)   \
+        if (opt_v)              \
+                fprintf(stderr, fmt, ## args )
+
+int main(int argc, char *argv[])
+{
+        char **spp, *master_ifname, *slave_ifname;
+        int c, i, rv;
+        int res = 0;
+        int exclusive = 0;
+
+        while ((c = getopt_long(argc, argv, "acdfhuvV", longopts, 0)) != EOF) {
+                switch (c) {
+                case 'a': opt_a++; exclusive++; break;
+                case 'c': opt_c++; exclusive++; break;
+                case 'd': opt_d++; exclusive++; break;
+                case 'f': opt_f++; exclusive++; break;
+                case 'h': opt_h++; exclusive++; break;
+                case 'u': opt_u++; exclusive++; break;
+                case 'v': opt_v++; break;
+                case 'V': opt_V++; exclusive++; break;
+
+                case '?':
+                        fprintf(stderr, usage_msg);
+                        res = 2;
+                        goto out;
+                }
+        }
+
+        /* options check */
+        if (exclusive > 1) {
+                fprintf(stderr, usage_msg);
+                res = 2;
+                goto out;
+        }
+
+        if (opt_v || opt_V) {
+                printf(version);
+                if (opt_V) {
+                        res = 0;
+                        goto out;
+                }
+        }
+
+        if (opt_u) {
+                printf(usage_msg);
+                res = 0;
+                goto out;
+        }
+
+        if (opt_h) {
+                printf(usage_msg);
+                printf(help_msg);
+                res = 0;
+                goto out;
+        }
+
+        /* Open a basic socket */
+        if ((skfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
+                perror("socket");
+                res = 1;
+                goto out;
+        }
+
+        if (opt_a) {
+                if (optind == argc) {
+                        /* No remaining args */
+                        /* show all interfaces */
+                        if_print((char *)NULL);
+                        goto out;
+                } else {
+                        /* Just show usage */
+                        fprintf(stderr, usage_msg);
+                        res = 2;
+                        goto out;
+                }
+        }
+
+        /* Copy the interface name */
+        spp = argv + optind;
+        master_ifname = *spp++;
+
+        if (master_ifname == NULL) {
+                fprintf(stderr, usage_msg);
+                res = 2;
+                goto out;
+        }
+
+        /* exchange abi version with bonding module */
+        res = get_drv_info(master_ifname);
+        if (res) {
+                fprintf(stderr,
+                        "Master '%s': Error: handshake with driver failed. "
+                        "Aborting\n",
+                        master_ifname);
+                goto out;
+        }
+
+        slave_ifname = *spp++;
+
+        if (slave_ifname == NULL) {
+                if (opt_d || opt_c) {
+                        fprintf(stderr, usage_msg);
+                        res = 2;
+                        goto out;
+                }
+
+                /* A single arg means show the
+                 * configuration for this interface
+                 */
+                if_print(master_ifname);
+                goto out;
+        }
+
+        res = get_if_settings(master_ifname, master_ifra);
+        if (res) {
+                /* Probably a good reason not to go on */
+                fprintf(stderr,
+                        "Master '%s': Error: get settings failed: %s. "
+                        "Aborting\n",
+                        master_ifname, strerror(res));
+                goto out;
+        }
+
+        /* check if master is indeed a master;
+         * if not then fail any operation
+         */
+        if (!(master_flags.ifr_flags & IFF_MASTER)) {
+                fprintf(stderr,
+                        "Illegal operation; the specified interface '%s' "
+                        "is not a master. Aborting\n",
+                        master_ifname);
+                res = 1;
+                goto out;
+        }
+
+        /* check if master is up; if not then fail any operation */
+        if (!(master_flags.ifr_flags & IFF_UP)) {
+                fprintf(stderr,
+                        "Illegal operation; the specified master interface "
+                        "'%s' is not up.\n",
+                        master_ifname);
+                res = 1;
+                goto out;
+        }
+
+        /* Only for enslaving */
+        if (!opt_c && !opt_d) {
+                sa_family_t master_family = master_hwaddr.ifr_hwaddr.sa_family;
+                unsigned char *hwaddr =
+                        (unsigned char *)master_hwaddr.ifr_hwaddr.sa_data;
+
+                /* The family '1' is ARPHRD_ETHER for ethernet. */
+                if (master_family != 1 && !opt_f) {
+                        fprintf(stderr,
+                                "Illegal operation: The specified master "
+                                "interface '%s' is not ethernet-like.\n "
+                                "This program is designed to work with "
+                                "ethernet-like network interfaces.\n "
+                                "Use the '-f' option to force the "
+                                "operation.\n",
+                                master_ifname);
+                        res = 1;
+                        goto out;
+                }
+
+                /* Check master's hw addr */
+                for (i = 0; i < 6; i++) {
+                        if (hwaddr[i] != 0) {
+                                hwaddr_set = 1;
+                                break;
+                        }
+                }
+
+                if (hwaddr_set) {
+                        v_print("current hardware address of master '%s' "
+                                "is %2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, "
+                                "type %d\n",
+                                master_ifname,
+                                hwaddr[0], hwaddr[1],
+                                hwaddr[2], hwaddr[3],
+                                hwaddr[4], hwaddr[5],
+                                master_family);
+                }
+        }
+
+        /* Accepts only one slave */
+        if (opt_c) {
+                /* change active slave */
+                res = get_slave_flags(slave_ifname);
+                if (res) {
+                        fprintf(stderr,
+                                "Slave '%s': Error: get flags failed. "
+                                "Aborting\n",
+                                slave_ifname);
+                        goto out;
+                }
+                res = change_active(master_ifname, slave_ifname);
+                if (res) {
+                        fprintf(stderr,
+                                "Master '%s', Slave '%s': Error: "
+                                "Change active failed\n",
+                                master_ifname, slave_ifname);
+                }
+        } else {
+                /* Accept multiple slaves */
+                do {
+                        if (opt_d) {
+                                /* detach a slave interface from the master */
+                                rv = get_slave_flags(slave_ifname);
+                                if (rv) {
+                                        /* Can't work with this slave. */
+                                        /* remember the error and skip it*/
+                                        fprintf(stderr,
+                                                "Slave '%s': Error: get flags "
+                                                "failed. Skipping\n",
+                                                slave_ifname);
+                                        res = rv;
+                                        continue;
+                                }
+                                rv = release(master_ifname, slave_ifname);
+                                if (rv) {
+                                        fprintf(stderr,
+                                                "Master '%s', Slave '%s': Error: "
+                                                "Release failed\n",
+                                                master_ifname, slave_ifname);
+                                        res = rv;
+                                }
+                        } else {
+                                /* attach a slave interface to the master */
+                                rv = get_if_settings(slave_ifname, slave_ifra);
+                                if (rv) {
+                                        /* Can't work with this slave. */
+                                        /* remember the error and skip it*/
+                                        fprintf(stderr,
+                                                "Slave '%s': Error: get "
+                                                "settings failed: %s. "
+                                                "Skipping\n",
+                                                slave_ifname, strerror(rv));
+                                        res = rv;
+                                        continue;
+                                }
+                                rv = enslave(master_ifname, slave_ifname);
+                                if (rv) {
+                                        fprintf(stderr,
+                                                "Master '%s', Slave '%s': Error: "
+                                                "Enslave failed\n",
+                                                master_ifname, slave_ifname);
+                                        res = rv;
+                                }
+                        }
+                } while ((slave_ifname = *spp++) != NULL);
+        }
+
+out:
+        if (skfd >= 0) {
+                close(skfd);
+        }
+
+        return res;
+}
+
+static short mif_flags;
+
+/* Get the inteface configuration from the kernel. */
+static int if_getconfig(char *ifname)
+{
+        struct ifreq ifr;
+        int metric, mtu;        /* Parameters of the master interface. */
+        struct sockaddr dstaddr, broadaddr, netmask;
+        unsigned char *hwaddr;
+
+        strcpy(ifr.ifr_name, ifname);
+        if (ioctl(skfd, SIOCGIFFLAGS, &ifr) < 0)
+                return -1;
+        mif_flags = ifr.ifr_flags;
+        printf("The result of SIOCGIFFLAGS on %s is %x.\n",
+               ifname, ifr.ifr_flags);
+
+        strcpy(ifr.ifr_name, ifname);
+        if (ioctl(skfd, SIOCGIFADDR, &ifr) < 0)
+                return -1;
+        printf("The result of SIOCGIFADDR is %2.2x.%2.2x.%2.2x.%2.2x.\n",
+               ifr.ifr_addr.sa_data[0], ifr.ifr_addr.sa_data[1],
+               ifr.ifr_addr.sa_data[2], ifr.ifr_addr.sa_data[3]);
+
+        strcpy(ifr.ifr_name, ifname);
+        if (ioctl(skfd, SIOCGIFHWADDR, &ifr) < 0)
+                return -1;
+
+        /* Gotta convert from 'char' to unsigned for printf(). */
+        hwaddr = (unsigned char *)ifr.ifr_hwaddr.sa_data;
+        printf("The result of SIOCGIFHWADDR is type %d  "
+               "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
+               ifr.ifr_hwaddr.sa_family, hwaddr[0], hwaddr[1],
+               hwaddr[2], hwaddr[3], hwaddr[4], hwaddr[5]);
+
+        strcpy(ifr.ifr_name, ifname);
+        if (ioctl(skfd, SIOCGIFMETRIC, &ifr) < 0) {
+                metric = 0;
+        } else
+                metric = ifr.ifr_metric;
+
+        strcpy(ifr.ifr_name, ifname);
+        if (ioctl(skfd, SIOCGIFMTU, &ifr) < 0)
+                mtu = 0;
+        else
+                mtu = ifr.ifr_mtu;
+
+        strcpy(ifr.ifr_name, ifname);
+        if (ioctl(skfd, SIOCGIFDSTADDR, &ifr) < 0) {
+                memset(&dstaddr, 0, sizeof(struct sockaddr));
+        } else
+                dstaddr = ifr.ifr_dstaddr;
+
+        strcpy(ifr.ifr_name, ifname);
+        if (ioctl(skfd, SIOCGIFBRDADDR, &ifr) < 0) {
+                memset(&broadaddr, 0, sizeof(struct sockaddr));
+        } else
+                broadaddr = ifr.ifr_broadaddr;
+
+        strcpy(ifr.ifr_name, ifname);
+        if (ioctl(skfd, SIOCGIFNETMASK, &ifr) < 0) {
+                memset(&netmask, 0, sizeof(struct sockaddr));
+        } else
+                netmask = ifr.ifr_netmask;
+
+        return 0;
+}
+
+static void if_print(char *ifname)
+{
+        char buff[1024];
+        struct ifconf ifc;
+        struct ifreq *ifr;
+        int i;
+
+        if (ifname == (char *)NULL) {
+                ifc.ifc_len = sizeof(buff);
+                ifc.ifc_buf = buff;
+                if (ioctl(skfd, SIOCGIFCONF, &ifc) < 0) {
+                        perror("SIOCGIFCONF failed");
+                        return;
+                }
+
+                ifr = ifc.ifc_req;
+                for (i = ifc.ifc_len / sizeof(struct ifreq); --i >= 0; ifr++) {
+                        if (if_getconfig(ifr->ifr_name) < 0) {
+                                fprintf(stderr,
+                                        "%s: unknown interface.\n",
+                                        ifr->ifr_name);
+                                continue;
+                        }
+
+                        if (((mif_flags & IFF_UP) == 0) && !opt_a) continue;
+                        /*ife_print(&ife);*/
+                }
+        } else {
+                if (if_getconfig(ifname) < 0) {
+                        fprintf(stderr,
+                                "%s: unknown interface.\n", ifname);
+                }
+        }
+}
+
+static int get_drv_info(char *master_ifname)
+{
+        struct ifreq ifr;
+        struct ethtool_drvinfo info;
+        char *endptr;
+
+        memset(&ifr, 0, sizeof(ifr));
+        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
+        ifr.ifr_data = (caddr_t)&info;
+
+        info.cmd = ETHTOOL_GDRVINFO;
+        strncpy(info.driver, "ifenslave", 32);
+        snprintf(info.fw_version, 32, "%d", BOND_ABI_VERSION);
+
+        if (ioctl(skfd, SIOCETHTOOL, &ifr) < 0) {
+                if (errno == EOPNOTSUPP) {
+                        goto out;
+                }
+
+                saved_errno = errno;
+                v_print("Master '%s': Error: get bonding info failed %s\n",
+                        master_ifname, strerror(saved_errno));
+                return 1;
+        }
+
+        abi_ver = strtoul(info.fw_version, &endptr, 0);
+        if (*endptr) {
+                v_print("Master '%s': Error: got invalid string as an ABI "
+                        "version from the bonding module\n",
+                        master_ifname);
+                return 1;
+        }
+
+out:
+        v_print("ABI ver is %d\n", abi_ver);
+
+        return 0;
+}
+
+static int change_active(char *master_ifname, char *slave_ifname)
+{
+        struct ifreq ifr;
+        int res = 0;
+
+        if (!(slave_flags.ifr_flags & IFF_SLAVE)) {
+                fprintf(stderr,
+                        "Illegal operation: The specified slave interface "
+                        "'%s' is not a slave\n",
+                        slave_ifname);
+                return 1;
+        }
+
+        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
+        strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
+        if ((ioctl(skfd, SIOCBONDCHANGEACTIVE, &ifr) < 0) &&
+            (ioctl(skfd, BOND_CHANGE_ACTIVE_OLD, &ifr) < 0)) {
+                saved_errno = errno;
+                v_print("Master '%s': Error: SIOCBONDCHANGEACTIVE failed: "
+                        "%s\n",
+                        master_ifname, strerror(saved_errno));
+                res = 1;
+        }
+
+        return res;
+}
+
+static int enslave(char *master_ifname, char *slave_ifname)
+{
+        struct ifreq ifr;
+        int res = 0;
+
+        if (slave_flags.ifr_flags & IFF_SLAVE) {
+                fprintf(stderr,
+                        "Illegal operation: The specified slave interface "
+                        "'%s' is already a slave\n",
+                        slave_ifname);
+                return 1;
+        }
+
+        res = set_if_down(slave_ifname, slave_flags.ifr_flags);
+        if (res) {
+                fprintf(stderr,
+                        "Slave '%s': Error: bring interface down failed\n",
+                        slave_ifname);
+                return res;
+        }
+
+        if (abi_ver < 2) {
+                /* Older bonding versions would panic if the slave has no IP
+                 * address, so get the IP setting from the master.
+                 */
+                res = set_if_addr(master_ifname, slave_ifname);
+                if (res) {
+                        fprintf(stderr,
+                                "Slave '%s': Error: set address failed\n",
+                                slave_ifname);
+                        return res;
+                }
+        } else {
+                res = clear_if_addr(slave_ifname);
+                if (res) {
+                        fprintf(stderr,
+                                "Slave '%s': Error: clear address failed\n",
+                                slave_ifname);
+                        return res;
+                }
+        }
+
+        if (master_mtu.ifr_mtu != slave_mtu.ifr_mtu) {
+                res = set_slave_mtu(slave_ifname, master_mtu.ifr_mtu);
+                if (res) {
+                        fprintf(stderr,
+                                "Slave '%s': Error: set MTU failed\n",
+                                slave_ifname);
+                        return res;
+                }
+        }
+
+        if (hwaddr_set) {
+                /* Master already has an hwaddr
+                 * so set it's hwaddr to the slave
+                 */
+                if (abi_ver < 1) {
+                        /* The driver is using an old ABI, so
+                         * the application sets the slave's
+                         * hwaddr
+                         */
+                        res = set_slave_hwaddr(slave_ifname,
+                                               &(master_hwaddr.ifr_hwaddr));
+                        if (res) {
+                                fprintf(stderr,
+                                        "Slave '%s': Error: set hw address "
+                                        "failed\n",
+                                        slave_ifname);
+                                goto undo_mtu;
+                        }
+
+                        /* For old ABI the application needs to bring the
+                         * slave back up
+                         */
+                        res = set_if_up(slave_ifname, slave_flags.ifr_flags);
+                        if (res) {
+                                fprintf(stderr,
+                                        "Slave '%s': Error: bring interface "
+                                        "down failed\n",
+                                        slave_ifname);
+                                goto undo_slave_mac;
+                        }
+                }
+                /* The driver is using a new ABI,
+                 * so the driver takes care of setting
+                 * the slave's hwaddr and bringing
+                 * it up again
+                 */
+        } else {
+                /* No hwaddr for master yet, so
+                 * set the slave's hwaddr to it
+                 */
+                if (abi_ver < 1) {
+                        /* For old ABI, the master needs to be
+                         * down before setting it's hwaddr
+                         */
+                        res = set_if_down(master_ifname, master_flags.ifr_flags);
+                        if (res) {
+                                fprintf(stderr,
+                                        "Master '%s': Error: bring interface "
+                                        "down failed\n",
+                                        master_ifname);
+                                goto undo_mtu;
+                        }
+                }
+
+                res = set_master_hwaddr(master_ifname,
+                                        &(slave_hwaddr.ifr_hwaddr));
+                if (res) {
+                        fprintf(stderr,
+                                "Master '%s': Error: set hw address "
+                                "failed\n",
+                                master_ifname);
+                        goto undo_mtu;
+                }
+
+                if (abi_ver < 1) {
+                        /* For old ABI, bring the master
+                         * back up
+                         */
+                        res = set_if_up(master_ifname, master_flags.ifr_flags);
+                        if (res) {
+                                fprintf(stderr,
+                                        "Master '%s': Error: bring interface "
+                                        "up failed\n",
+                                        master_ifname);
+                                goto undo_master_mac;
+                        }
+                }
+
+                hwaddr_set = 1;
+        }
+
+        /* Do the real thing */
+        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
+        strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
+        if ((ioctl(skfd, SIOCBONDENSLAVE, &ifr) < 0) &&
+            (ioctl(skfd, BOND_ENSLAVE_OLD, &ifr) < 0)) {
+                saved_errno = errno;
+                v_print("Master '%s': Error: SIOCBONDENSLAVE failed: %s\n",
+                        master_ifname, strerror(saved_errno));
+                res = 1;
+        }
+
+        if (res) {
+                goto undo_master_mac;
+        }
+
+        return 0;
+
+/* rollback (best effort) */
+undo_master_mac:
+        set_master_hwaddr(master_ifname, &(master_hwaddr.ifr_hwaddr));
+        hwaddr_set = 0;
+        goto undo_mtu;
+undo_slave_mac:
+        set_slave_hwaddr(slave_ifname, &(slave_hwaddr.ifr_hwaddr));
+undo_mtu:
+        set_slave_mtu(slave_ifname, slave_mtu.ifr_mtu);
+        return res;
+}
+
+static int release(char *master_ifname, char *slave_ifname)
+{
+        struct ifreq ifr;
+        int res = 0;
+
+        if (!(slave_flags.ifr_flags & IFF_SLAVE)) {
+                fprintf(stderr,
+                        "Illegal operation: The specified slave interface "
+                        "'%s' is not a slave\n",
+                        slave_ifname);
+                return 1;
+        }
+
+        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
+        strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
+        if ((ioctl(skfd, SIOCBONDRELEASE, &ifr) < 0) &&
+            (ioctl(skfd, BOND_RELEASE_OLD, &ifr) < 0)) {
+                saved_errno = errno;
+                v_print("Master '%s': Error: SIOCBONDRELEASE failed: %s\n",
+                        master_ifname, strerror(saved_errno));
+                return 1;
+        } else if (abi_ver < 1) {
+                /* The driver is using an old ABI, so we'll set the interface
+                 * down to avoid any conflicts due to same MAC/IP
+                 */
+                res = set_if_down(slave_ifname, slave_flags.ifr_flags);
+                if (res) {
+                        fprintf(stderr,
+                                "Slave '%s': Error: bring interface "
+                                "down failed\n",
+                                slave_ifname);
+                }
+        }
+
+        /* set to default mtu */
+        set_slave_mtu(slave_ifname, 1500);
+
+        return res;
+}
+
+static int get_if_settings(char *ifname, struct dev_ifr ifra[])
+{
+        int i;
+        int res = 0;
+
+        for (i = 0; ifra[i].req_ifr; i++) {
+                strncpy(ifra[i].req_ifr->ifr_name, ifname, IFNAMSIZ);
+                res = ioctl(skfd, ifra[i].req_type, ifra[i].req_ifr);
+                if (res < 0) {
+                        saved_errno = errno;
+                        v_print("Interface '%s': Error: %s failed: %s\n",
+                                ifname, ifra[i].req_name,
+                                strerror(saved_errno));
+
+                        return saved_errno;
+                }
+        }
+
+        return 0;
+}
+
+static int get_slave_flags(char *slave_ifname)
+{
+        int res = 0;
+
+        strncpy(slave_flags.ifr_name, slave_ifname, IFNAMSIZ);
+        res = ioctl(skfd, SIOCGIFFLAGS, &slave_flags);
+        if (res < 0) {
+                saved_errno = errno;
+                v_print("Slave '%s': Error: SIOCGIFFLAGS failed: %s\n",
+                        slave_ifname, strerror(saved_errno));
+        } else {
+                v_print("Slave %s: flags %04X.\n",
+                        slave_ifname, slave_flags.ifr_flags);
+        }
+
+        return res;
+}
+
+static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr)
+{
+        unsigned char *addr = (unsigned char *)hwaddr->sa_data;
+        struct ifreq ifr;
+        int res = 0;
+
+        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
+        memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr));
+        res = ioctl(skfd, SIOCSIFHWADDR, &ifr);
+        if (res < 0) {
+                saved_errno = errno;
+                v_print("Master '%s': Error: SIOCSIFHWADDR failed: %s\n",
+                        master_ifname, strerror(saved_errno));
+                return res;
+        } else {
+                v_print("Master '%s': hardware address set to "
+                        "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
+                        master_ifname, addr[0], addr[1], addr[2],
+                        addr[3], addr[4], addr[5]);
+        }
+
+        return res;
+}
+
+static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr)
+{
+        unsigned char *addr = (unsigned char *)hwaddr->sa_data;
+        struct ifreq ifr;
+        int res = 0;
+
+        strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
+        memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr));
+        res = ioctl(skfd, SIOCSIFHWADDR, &ifr);
+        if (res < 0) {
+                saved_errno = errno;
+
+                v_print("Slave '%s': Error: SIOCSIFHWADDR failed: %s\n",
+                        slave_ifname, strerror(saved_errno));
+
+                if (saved_errno == EBUSY) {
+                        v_print("  The device is busy: it must be idle "
+                                "before running this command.\n");
+                } else if (saved_errno == EOPNOTSUPP) {
+                        v_print("  The device does not support setting "
+                                "the MAC address.\n"
+                                "  Your kernel likely does not support slave "
+                                "devices.\n");
+                } else if (saved_errno == EINVAL) {
+                        v_print("  The device's address type does not match "
+                                "the master's address type.\n");
+                }
+                return res;
+        } else {
+                v_print("Slave '%s': hardware address set to "
+                        "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
+                        slave_ifname, addr[0], addr[1], addr[2],
+                        addr[3], addr[4], addr[5]);
+        }
+
+        return res;
+}
+
+static int set_slave_mtu(char *slave_ifname, int mtu)
+{
+        struct ifreq ifr;
+        int res = 0;
+
+        ifr.ifr_mtu = mtu;
+        strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
+
+        res = ioctl(skfd, SIOCSIFMTU, &ifr);
+        if (res < 0) {
+                saved_errno = errno;
+                v_print("Slave '%s': Error: SIOCSIFMTU failed: %s\n",
+                        slave_ifname, strerror(saved_errno));
+        } else {
+                v_print("Slave '%s': MTU set to %d.\n", slave_ifname, mtu);
+        }
+
+        return res;
+}
+
+static int set_if_flags(char *ifname, short flags)
+{
+        struct ifreq ifr;
+        int res = 0;
+
+        ifr.ifr_flags = flags;
+        strncpy(ifr.ifr_name, ifname, IFNAMSIZ);
+
+        res = ioctl(skfd, SIOCSIFFLAGS, &ifr);
+        if (res < 0) {
+                saved_errno = errno;
+                v_print("Interface '%s': Error: SIOCSIFFLAGS failed: %s\n",
+                        ifname, strerror(saved_errno));
+        } else {
+                v_print("Interface '%s': flags set to %04X.\n", ifname, flags);
+        }
+
+        return res;
+}
+
+static int set_if_up(char *ifname, short flags)
+{
+        return set_if_flags(ifname, flags | IFF_UP);
+}
+
+static int set_if_down(char *ifname, short flags)
+{
+        return set_if_flags(ifname, flags & ~IFF_UP);
+}
+
+static int clear_if_addr(char *ifname)
+{
+        struct ifreq ifr;
+        int res = 0;
+
+        strncpy(ifr.ifr_name, ifname, IFNAMSIZ);
+        ifr.ifr_addr.sa_family = AF_INET;
+        memset(ifr.ifr_addr.sa_data, 0, sizeof(ifr.ifr_addr.sa_data));
+
+        res = ioctl(skfd, SIOCSIFADDR, &ifr);
+        if (res < 0) {
+                saved_errno = errno;
+                v_print("Interface '%s': Error: SIOCSIFADDR failed: %s\n",
+                        ifname, strerror(saved_errno));
+        } else {
+                v_print("Interface '%s': address cleared\n", ifname);
+        }
+
+        return res;
+}
+
+static int set_if_addr(char *master_ifname, char *slave_ifname)
+{
+        struct ifreq ifr;
+        int res;
+        unsigned char *ipaddr;
+        int i;
+        struct {
+                char *req_name;
+                char *desc;
+                int g_ioctl;
+                int s_ioctl;
+        } ifra[] = {
+                {"IFADDR", "addr", SIOCGIFADDR, SIOCSIFADDR},
+                {"DSTADDR", "destination addr", SIOCGIFDSTADDR, SIOCSIFDSTADDR},
+                {"BRDADDR", "broadcast addr", SIOCGIFBRDADDR, SIOCSIFBRDADDR},
+                {"NETMASK", "netmask", SIOCGIFNETMASK, SIOCSIFNETMASK},
+                {NULL, NULL, 0, 0},
+        };
+
+        for (i = 0; ifra[i].req_name; i++) {
+                strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
+                res = ioctl(skfd, ifra[i].g_ioctl, &ifr);
+                if (res < 0) {
+                        int saved_errno = errno;
+
+                        v_print("Interface '%s': Error: SIOCG%s failed: %s\n",
+                                master_ifname, ifra[i].req_name,
+                                strerror(saved_errno));
+
+                        ifr.ifr_addr.sa_family = AF_INET;
+                        memset(ifr.ifr_addr.sa_data, 0,
+                               sizeof(ifr.ifr_addr.sa_data));
+                }
+
+                strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
+                res = ioctl(skfd, ifra[i].s_ioctl, &ifr);
+                if (res < 0) {
+                        int saved_errno = errno;
+
+                        v_print("Interface '%s': Error: SIOCS%s failed: %s\n",
+                                slave_ifname, ifra[i].req_name,
+                                strerror(saved_errno));
+
+                        return res;
+                }
+
+                ipaddr = ifr.ifr_addr.sa_data;
+                v_print("Interface '%s': set IP %s to %d.%d.%d.%d\n",
+                        slave_ifname, ifra[i].desc,
+                        ipaddr[0], ipaddr[1], ipaddr[2], ipaddr[3]);
+        }
+
+        return 0;
+}
+
+/*
+ * Local variables:
+ *  version-control: t
+ *  kept-new-versions: 5
+ *  c-indent-level: 4
+ *  c-basic-offset: 4
+ *  tab-width: 4
+ *  compile-command: "gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave"
+ * End:
+ */
+
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
new file mode 100644
index 00000000000..a2c893a7475
--- /dev/null
+++ b/Documentation/networking/ip-sysctl.txt
@@ -0,0 +1,878 @@
+/proc/sys/net/ipv4/* Variables:
+
+ip_forward - BOOLEAN
+        0 - disabled (default)
+        not 0 - enabled 
+
+        Forward Packets between interfaces.
+
+        This variable is special, its change resets all configuration
+        parameters to their default state (RFC1122 for hosts, RFC1812
+        for routers)
+
+ip_default_ttl - INTEGER
+        default 64
+
+ip_no_pmtu_disc - BOOLEAN
+        Disable Path MTU Discovery.
+        default FALSE
+
+min_pmtu - INTEGER
+        default 562 - minimum discovered Path MTU
+
+mtu_expires - INTEGER
+        Time, in seconds, that cached PMTU information is kept.
+
+min_adv_mss - INTEGER
+        The advertised MSS depends on the first hop route MTU, but will
+        never be lower than this setting.
+
+IP Fragmentation:
+
+ipfrag_high_thresh - INTEGER
+        Maximum memory used to reassemble IP fragments. When 
+        ipfrag_high_thresh bytes of memory is allocated for this purpose,
+        the fragment handler will toss packets until ipfrag_low_thresh
+        is reached.
+        
+ipfrag_low_thresh - INTEGER
+        See ipfrag_high_thresh  
+
+ipfrag_time - INTEGER
+        Time in seconds to keep an IP fragment in memory.       
+
+ipfrag_secret_interval - INTEGER
+        Regeneration interval (in seconds) of the hash secret (or lifetime 
+        for the hash secret) for IP fragments.
+        Default: 600
+
+INET peer storage:
+
+inet_peer_threshold - INTEGER
+        The approximate size of the storage.  Starting from this threshold      
+        entries will be thrown aggressively.  This threshold also determines
+        entries' time-to-live and time intervals between garbage collection
+        passes.  More entries, less time-to-live, less GC interval.
+
+inet_peer_minttl - INTEGER
+        Minimum time-to-live of entries.  Should be enough to cover fragment
+        time-to-live on the reassembling side.  This minimum time-to-live  is
+        guaranteed if the pool size is less than inet_peer_threshold.
+        Measured in jiffies(1).
+
+inet_peer_maxttl - INTEGER
+        Maximum time-to-live of entries.  Unused entries will expire after
+        this period of time if there is no memory pressure on the pool (i.e.
+        when the number of entries in the pool is very small).
+        Measured in jiffies(1).
+
+inet_peer_gc_mintime - INTEGER
+        Minimum interval between garbage collection passes.  This interval is
+        in effect under high memory pressure on the pool.
+        Measured in jiffies(1).
+
+inet_peer_gc_maxtime - INTEGER
+        Minimum interval between garbage collection passes.  This interval is
+        in effect under low (or absent) memory pressure on the pool.
+        Measured in jiffies(1).
+
+TCP variables: 
+
+tcp_syn_retries - INTEGER
+        Number of times initial SYNs for an active TCP connection attempt
+        will be retransmitted. Should not be higher than 255. Default value
+        is 5, which corresponds to ~180seconds.
+
+tcp_synack_retries - INTEGER
+        Number of times SYNACKs for a passive TCP connection attempt will
+        be retransmitted. Should not be higher than 255. Default value
+        is 5, which corresponds to ~180seconds.
+
+tcp_keepalive_time - INTEGER
+        How often TCP sends out keepalive messages when keepalive is enabled.
+        Default: 2hours.
+
+tcp_keepalive_probes - INTEGER
+        How many keepalive probes TCP sends out, until it decides that the
+        connection is broken. Default value: 9.
+
+tcp_keepalive_intvl - INTEGER
+        How frequently the probes are send out. Multiplied by
+        tcp_keepalive_probes it is time to kill not responding connection,
+        after probes started. Default value: 75sec i.e. connection
+        will be aborted after ~11 minutes of retries.
+
+tcp_retries1 - INTEGER
+        How many times to retry before deciding that something is wrong
+        and it is necessary to report this suspicion to network layer.
+        Minimal RFC value is 3, it is default, which corresponds
+        to ~3sec-8min depending on RTO.
+
+tcp_retries2 - INTEGER
+        How may times to retry before killing alive TCP connection.
+        RFC1122 says that the limit should be longer than 100 sec.
+        It is too small number. Default value 15 corresponds to ~13-30min
+        depending on RTO.
+
+tcp_orphan_retries - INTEGER
+        How may times to retry before killing TCP connection, closed
+        by our side. Default value 7 corresponds to ~50sec-16min
+        depending on RTO. If you machine is loaded WEB server,
+        you should think about lowering this value, such sockets
+        may consume significant resources. Cf. tcp_max_orphans.
+
+tcp_fin_timeout - INTEGER
+        Time to hold socket in state FIN-WAIT-2, if it was closed
+        by our side. Peer can be broken and never close its side,
+        or even died unexpectedly. Default value is 60sec.
+        Usual value used in 2.2 was 180 seconds, you may restore
+        it, but remember that if your machine is even underloaded WEB server,
+        you risk to overflow memory with kilotons of dead sockets,
+        FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
+        because they eat maximum 1.5K of memory, but they tend
+        to live longer. Cf. tcp_max_orphans.
+
+tcp_max_tw_buckets - INTEGER
+        Maximal number of timewait sockets held by system simultaneously.
+        If this number is exceeded time-wait socket is immediately destroyed
+        and warning is printed. This limit exists only to prevent
+        simple DoS attacks, you _must_ not lower the limit artificially,
+        but rather increase it (probably, after increasing installed memory),
+        if network conditions require more than default value.
+
+tcp_tw_recycle - BOOLEAN
+        Enable fast recycling TIME-WAIT sockets. Default value is 0.
+        It should not be changed without advice/request of technical
+        experts.
+
+tcp_tw_reuse - BOOLEAN
+        Allow to reuse TIME-WAIT sockets for new connections when it is
+        safe from protocol viewpoint. Default value is 0.
+        It should not be changed without advice/request of technical
+        experts.
+
+tcp_max_orphans - INTEGER
+        Maximal number of TCP sockets not attached to any user file handle,
+        held by system. If this number is exceeded orphaned connections are
+        reset immediately and warning is printed. This limit exists
+        only to prevent simple DoS attacks, you _must_ not rely on this
+        or lower the limit artificially, but rather increase it
+        (probably, after increasing installed memory),
+        if network conditions require more than default value,
+        and tune network services to linger and kill such states
+        more aggressively. Let me to remind again: each orphan eats
+        up to ~64K of unswappable memory.
+
+tcp_abort_on_overflow - BOOLEAN
+        If listening service is too slow to accept new connections,
+        reset them. Default state is FALSE. It means that if overflow
+        occurred due to a burst, connection will recover. Enable this
+        option _only_ if you are really sure that listening daemon
+        cannot be tuned to accept connections faster. Enabling this
+        option can harm clients of your server.
+
+tcp_syncookies - BOOLEAN
+        Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
+        Send out syncookies when the syn backlog queue of a socket 
+        overflows. This is to prevent against the common 'syn flood attack'
+        Default: FALSE
+
+        Note, that syncookies is fallback facility.
+        It MUST NOT be used to help highly loaded servers to stand
+        against legal connection rate. If you see synflood warnings
+        in your logs, but investigation shows that they occur
+        because of overload with legal connections, you should tune
+        another parameters until this warning disappear.
+        See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
+
+        syncookies seriously violate TCP protocol, do not allow
+        to use TCP extensions, can result in serious degradation
+        of some services (f.e. SMTP relaying), visible not by you,
+        but your clients and relays, contacting you. While you see
+        synflood warnings in logs not being really flooded, your server
+        is seriously misconfigured.
+
+tcp_stdurg - BOOLEAN
+        Use the Host requirements interpretation of the TCP urg pointer field.
+        Most hosts use the older BSD interpretation, so if you turn this on
+        Linux might not communicate correctly with them.        
+        Default: FALSE 
+        
+tcp_max_syn_backlog - INTEGER
+        Maximal number of remembered connection requests, which are
+        still did not receive an acknowledgment from connecting client.
+        Default value is 1024 for systems with more than 128Mb of memory,
+        and 128 for low memory machines. If server suffers of overload,
+        try to increase this number.
+
+tcp_window_scaling - BOOLEAN
+        Enable window scaling as defined in RFC1323.
+
+tcp_timestamps - BOOLEAN
+        Enable timestamps as defined in RFC1323.
+
+tcp_sack - BOOLEAN
+        Enable select acknowledgments (SACKS).
+
+tcp_fack - BOOLEAN
+        Enable FACK congestion avoidance and fast retransmission.
+        The value is not used, if tcp_sack is not enabled.
+
+tcp_dsack - BOOLEAN
+        Allows TCP to send "duplicate" SACKs.
+
+tcp_ecn - BOOLEAN
+        Enable Explicit Congestion Notification in TCP.
+
+tcp_reordering - INTEGER
+        Maximal reordering of packets in a TCP stream.
+        Default: 3      
+
+tcp_retrans_collapse - BOOLEAN
+        Bug-to-bug compatibility with some broken printers.
+        On retransmit try to send bigger packets to work around bugs in
+        certain TCP stacks.
+
+tcp_wmem - vector of 3 INTEGERs: min, default, max
+        min: Amount of memory reserved for send buffers for TCP socket.
+        Each TCP socket has rights to use it due to fact of its birth.
+        Default: 4K
+
+        default: Amount of memory allowed for send buffers for TCP socket
+        by default. This value overrides net.core.wmem_default used
+        by other protocols, it is usually lower than net.core.wmem_default.
+        Default: 16K
+
+        max: Maximal amount of memory allowed for automatically selected
+        send buffers for TCP socket. This value does not override
+        net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
+        Default: 128K
+
+tcp_rmem - vector of 3 INTEGERs: min, default, max
+        min: Minimal size of receive buffer used by TCP sockets.
+        It is guaranteed to each TCP socket, even under moderate memory
+        pressure.
+        Default: 8K
+
+        default: default size of receive buffer used by TCP sockets.
+        This value overrides net.core.rmem_default used by other protocols.
+        Default: 87380 bytes. This value results in window of 65535 with
+        default setting of tcp_adv_win_scale and tcp_app_win:0 and a bit
+        less for default tcp_app_win. See below about these variables.
+
+        max: maximal size of receive buffer allowed for automatically
+        selected receiver buffers for TCP socket. This value does not override
+        net.core.rmem_max, "static" selection via SO_RCVBUF does not use this.
+        Default: 87380*2 bytes.
+
+tcp_mem - vector of 3 INTEGERs: min, pressure, max
+        low: below this number of pages TCP is not bothered about its
+        memory appetite.
+
+        pressure: when amount of memory allocated by TCP exceeds this number
+        of pages, TCP moderates its memory consumption and enters memory
+        pressure mode, which is exited when memory consumption falls
+        under "low".
+
+        high: number of pages allowed for queueing by all TCP sockets.
+
+        Defaults are calculated at boot time from amount of available
+        memory.
+
+tcp_app_win - INTEGER
+        Reserve max(window/2^tcp_app_win, mss) of window for application
+        buffer. Value 0 is special, it means that nothing is reserved.
+        Default: 31
+
+tcp_adv_win_scale - INTEGER
+        Count buffering overhead as bytes/2^tcp_adv_win_scale
+        (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
+        if it is <= 0.
+        Default: 2
+
+tcp_rfc1337 - BOOLEAN
+        If set, the TCP stack behaves conforming to RFC1337. If unset,
+        we are not conforming to RFC, but prevent TCP TIME_WAIT
+        assassination.   
+        Default: 0
+
+tcp_low_latency - BOOLEAN
+        If set, the TCP stack makes decisions that prefer lower
+        latency as opposed to higher throughput.  By default, this
+        option is not set meaning that higher throughput is preferred.
+        An example of an application where this default should be
+        changed would be a Beowulf compute cluster.
+        Default: 0
+
+tcp_westwood - BOOLEAN
+        Enable TCP Westwood+ congestion control algorithm.
+        TCP Westwood+ is a sender-side only modification of the TCP Reno 
+        protocol stack that optimizes the performance of TCP congestion 
+        control. It is based on end-to-end bandwidth estimation to set 
+        congestion window and slow start threshold after a congestion 
+        episode. Using this estimation, TCP Westwood+ adaptively sets a 
+        slow start threshold and a congestion window which takes into 
+        account the bandwidth used  at the time congestion is experienced. 
+        TCP Westwood+ significantly increases fairness wrt TCP Reno in 
+        wired networks and throughput over wireless links.   
+        Default: 0
+
+tcp_vegas_cong_avoid - BOOLEAN
+        Enable TCP Vegas congestion avoidance algorithm.
+        TCP Vegas is a sender-side only change to TCP that anticipates
+        the onset of congestion by estimating the bandwidth. TCP Vegas
+        adjusts the sending rate by modifying the congestion
+        window. TCP Vegas should provide less packet loss, but it is
+        not as aggressive as TCP Reno.
+        Default:0
+
+tcp_bic - BOOLEAN
+        Enable BIC TCP congestion control algorithm.
+        BIC-TCP is a sender-side only change that ensures a linear RTT
+        fairness under large windows while offering both scalability and
+        bounded TCP-friendliness. The protocol combines two schemes
+        called additive increase and binary search increase. When the
+        congestion window is large, additive increase with a large
+        increment ensures linear RTT fairness as well as good
+        scalability. Under small congestion windows, binary search
+        increase provides TCP friendliness.
+        Default: 0
+
+tcp_bic_low_window - INTEGER
+        Sets the threshold window (in packets) where BIC TCP starts to
+        adjust the congestion window. Below this threshold BIC TCP behaves
+        the same as the default TCP Reno. 
+        Default: 14
+
+tcp_bic_fast_convergence - BOOLEAN
+        Forces BIC TCP to more quickly respond to changes in congestion
+        window. Allows two flows sharing the same connection to converge
+        more rapidly.
+        Default: 1
+
+tcp_default_win_scale - INTEGER
+        Sets the minimum window scale TCP will negotiate for on all
+        conections.
+        Default: 7
+
+tcp_tso_win_divisor - INTEGER
+       This allows control over what percentage of the congestion window
+       can be consumed by a single TSO frame.
+       The setting of this parameter is a choice between burstiness and
+       building larger TSO frames.
+       Default: 8
+
+tcp_frto - BOOLEAN
+        Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
+        timeouts.  It is particularly beneficial in wireless environments
+        where packet loss is typically due to random radio interference
+        rather than intermediate router congestion.
+
+somaxconn - INTEGER
+        Limit of socket listen() backlog, known in userspace as SOMAXCONN.
+        Defaults to 128.  See also tcp_max_syn_backlog for additional tuning
+        for TCP sockets.
+
+IP Variables:
+
+ip_local_port_range - 2 INTEGERS
+        Defines the local port range that is used by TCP and UDP to
+        choose the local port. The first number is the first, the 
+        second the last local port number. Default value depends on
+        amount of memory available on the system:
+        > 128Mb 32768-61000
+        < 128Mb 1024-4999 or even less.
+        This number defines number of active connections, which this
+        system can issue simultaneously to systems not supporting
+        TCP extensions (timestamps). With tcp_tw_recycle enabled
+        (i.e. by default) range 1024-4999 is enough to issue up to
+        2000 connections per second to systems supporting timestamps.
+
+ip_nonlocal_bind - BOOLEAN
+        If set, allows processes to bind() to non-local IP addresses,
+        which can be quite useful - but may break some applications.
+        Default: 0
+
+ip_dynaddr - BOOLEAN
+        If set non-zero, enables support for dynamic addresses.
+        If set to a non-zero value larger than 1, a kernel log
+        message will be printed when dynamic address rewriting
+        occurs.
+        Default: 0
+
+icmp_echo_ignore_all - BOOLEAN
+icmp_echo_ignore_broadcasts - BOOLEAN
+        If either is set to true, then the kernel will ignore either all
+        ICMP ECHO requests sent to it or just those to broadcast/multicast
+        addresses, respectively.
+
+icmp_ratelimit - INTEGER
+        Limit the maximal rates for sending ICMP packets whose type matches
+        icmp_ratemask (see below) to specific targets.
+        0 to disable any limiting, otherwise the maximal rate in jiffies(1)
+        Default: 100
+
+icmp_ratemask - INTEGER
+        Mask made of ICMP types for which rates are being limited.
+        Significant bits: IHGFEDCBA9876543210
+        Default mask:     0000001100000011000 (6168)
+
+        Bit definitions (see include/linux/icmp.h):
+                0 Echo Reply
+                3 Destination Unreachable *
+                4 Source Quench *
+                5 Redirect
+                8 Echo Request
+                B Time Exceeded *
+                C Parameter Problem *
+                D Timestamp Request
+                E Timestamp Reply
+                F Info Request
+                G Info Reply
+                H Address Mask Request
+                I Address Mask Reply
+
+        * These are rate limited by default (see default mask above)
+
+icmp_ignore_bogus_error_responses - BOOLEAN
+        Some routers violate RFC1122 by sending bogus responses to broadcast
+        frames.  Such violations are normally logged via a kernel warning.
+        If this is set to TRUE, the kernel will not give such warnings, which
+        will avoid log file clutter.
+        Default: FALSE
+
+igmp_max_memberships - INTEGER
+        Change the maximum number of multicast groups we can subscribe to.
+        Default: 20
+
+conf/interface/*  changes special settings per interface (where "interface" is 
+                  the name of your network interface)
+conf/all/*        is special, changes the settings for all interfaces
+
+
+log_martians - BOOLEAN
+        Log packets with impossible addresses to kernel log.
+        log_martians for the interface will be enabled if at least one of
+        conf/{all,interface}/log_martians is set to TRUE,
+        it will be disabled otherwise
+
+accept_redirects - BOOLEAN
+        Accept ICMP redirect messages.
+        accept_redirects for the interface will be enabled if:
+        - both conf/{all,interface}/accept_redirects are TRUE in the case forwarding
+          for the interface is enabled
+        or
+        - at least one of conf/{all,interface}/accept_redirects is TRUE in the case
+          forwarding for the interface is disabled
+        accept_redirects for the interface will be disabled otherwise
+        default TRUE (host)
+                FALSE (router)
+
+forwarding - BOOLEAN
+        Enable IP forwarding on this interface.
+
+mc_forwarding - BOOLEAN
+        Do multicast routing. The kernel needs to be compiled with CONFIG_MROUTE
+        and a multicast routing daemon is required.
+        conf/all/mc_forwarding must also be set to TRUE to enable multicast routing
+        for the interface
+
+medium_id - INTEGER
+        Integer value used to differentiate the devices by the medium they
+        are attached to. Two devices can have different id values when
+        the broadcast packets are received only on one of them.
+        The default value 0 means that the device is the only interface
+        to its medium, value of -1 means that medium is not known.
+        
+        Currently, it is used to change the proxy_arp behavior:
+        the proxy_arp feature is enabled for packets forwarded between
+        two devices attached to different media.
+
+proxy_arp - BOOLEAN
+        Do proxy arp.
+        proxy_arp for the interface will be enabled if at least one of
+        conf/{all,interface}/proxy_arp is set to TRUE,
+        it will be disabled otherwise
+
+shared_media - BOOLEAN
+        Send(router) or accept(host) RFC1620 shared media redirects.
+        Overrides ip_secure_redirects.
+        shared_media for the interface will be enabled if at least one of
+        conf/{all,interface}/shared_media is set to TRUE,
+        it will be disabled otherwise
+        default TRUE
+
+secure_redirects - BOOLEAN
+        Accept ICMP redirect messages only for gateways,
+        listed in default gateway list.
+        secure_redirects for the interface will be enabled if at least one of
+        conf/{all,interface}/secure_redirects is set to TRUE,
+        it will be disabled otherwise
+        default TRUE
+
+send_redirects - BOOLEAN
+        Send redirects, if router.
+        send_redirects for the interface will be enabled if at least one of
+        conf/{all,interface}/send_redirects is set to TRUE,
+        it will be disabled otherwise
+        Default: TRUE
+
+bootp_relay - BOOLEAN
+        Accept packets with source address 0.b.c.d destined
+        not to this host as local ones. It is supposed, that
+        BOOTP relay daemon will catch and forward such packets.
+        conf/all/bootp_relay must also be set to TRUE to enable BOOTP relay
+        for the interface
+        default FALSE
+        Not Implemented Yet.
+
+accept_source_route - BOOLEAN
+        Accept packets with SRR option.
+        conf/all/accept_source_route must also be set to TRUE to accept packets
+        with SRR option on the interface
+        default TRUE (router)
+                FALSE (host)
+
+rp_filter - BOOLEAN
+        1 - do source validation by reversed path, as specified in RFC1812
+            Recommended option for single homed hosts and stub network
+            routers. Could cause troubles for complicated (not loop free)
+            networks running a slow unreliable protocol (sort of RIP),
+            or using static routes.
+
+        0 - No source validation.
+
+        conf/all/rp_filter must also be set to TRUE to do source validation
+        on the interface
+
+        Default value is 0. Note that some distributions enable it
+        in startup scripts.
+
+arp_filter - BOOLEAN
+        1 - Allows you to have multiple network interfaces on the same
+        subnet, and have the ARPs for each interface be answered
+        based on whether or not the kernel would route a packet from
+        the ARP'd IP out that interface (therefore you must use source
+        based routing for this to work). In other words it allows control
+        of which cards (usually 1) will respond to an arp request.
+
+        0 - (default) The kernel can respond to arp requests with addresses
+        from other interfaces. This may seem wrong but it usually makes
+        sense, because it increases the chance of successful communication.
+        IP addresses are owned by the complete host on Linux, not by
+        particular interfaces. Only for more complex setups like load-
+        balancing, does this behaviour cause problems.
+
+        arp_filter for the interface will be enabled if at least one of
+        conf/{all,interface}/arp_filter is set to TRUE,
+        it will be disabled otherwise
+
+arp_announce - INTEGER
+        Define different restriction levels for announcing the local
+        source IP address from IP packets in ARP requests sent on
+        interface:
+        0 - (default) Use any local address, configured on any interface
+        1 - Try to avoid local addresses that are not in the target's
+        subnet for this interface. This mode is useful when target
+        hosts reachable via this interface require the source IP
+        address in ARP requests to be part of their logical network
+        configured on the receiving interface. When we generate the
+        request we will check all our subnets that include the
+        target IP and will preserve the source address if it is from
+        such subnet. If there is no such subnet we select source
+        address according to the rules for level 2.
+        2 - Always use the best local address for this target.
+        In this mode we ignore the source address in the IP packet
+        and try to select local address that we prefer for talks with
+        the target host. Such local address is selected by looking
+        for primary IP addresses on all our subnets on the outgoing
+        interface that include the target IP address. If no suitable
+        local address is found we select the first local address
+        we have on the outgoing interface or on all other interfaces,
+        with the hope we will receive reply for our request and
+        even sometimes no matter the source IP address we announce.
+
+        The max value from conf/{all,interface}/arp_announce is used.
+
+        Increasing the restriction level gives more chance for
+        receiving answer from the resolved target while decreasing
+        the level announces more valid sender's information.
+
+arp_ignore - INTEGER
+        Define different modes for sending replies in response to
+        received ARP requests that resolve local target IP addresses:
+        0 - (default): reply for any local target IP address, configured
+        on any interface
+        1 - reply only if the target IP address is local address
+        configured on the incoming interface
+        2 - reply only if the target IP address is local address
+        configured on the incoming interface and both with the
+        sender's IP address are part from same subnet on this interface
+        3 - do not reply for local addresses configured with scope host,
+        only resolutions for global and link addresses are replied
+        4-7 - reserved
+        8 - do not reply for all local addresses
+
+        The max value from conf/{all,interface}/arp_ignore is used
+        when ARP request is received on the {interface}
+
+app_solicit - INTEGER
+        The maximum number of probes to send to the user space ARP daemon
+        via netlink before dropping back to multicast probes (see
+        mcast_solicit).  Defaults to 0.
+
+disable_policy - BOOLEAN
+        Disable IPSEC policy (SPD) for this interface
+
+disable_xfrm - BOOLEAN
+        Disable IPSEC encryption on this interface, whatever the policy
+
+
+
+tag - INTEGER
+        Allows you to write a number, which can be used as required.
+        Default value is 0.
+
+(1) Jiffie: internal timeunit for the kernel. On the i386 1/100s, on the
+Alpha 1/1024s. See the HZ define in /usr/include/asm/param.h for the exact
+value on your system. 
+
+Alexey Kuznetsov.
+kuznet@ms2.inr.ac.ru
+
+Updated by:
+Andi Kleen
+ak@muc.de
+Nicolas Delon
+delon.nicolas@wanadoo.fr
+
+
+
+
+/proc/sys/net/ipv6/* Variables:
+
+IPv6 has no global variables such as tcp_*.  tcp_* settings under ipv4/ also
+apply to IPv6 [XXX?].
+
+bindv6only - BOOLEAN
+        Default value for IPV6_V6ONLY socket option,
+        which restricts use of the IPv6 socket to IPv6 communication 
+        only.
+                TRUE: disable IPv4-mapped address feature
+                FALSE: enable IPv4-mapped address feature
+
+        Default: FALSE (as specified in RFC2553bis)
+
+IPv6 Fragmentation:
+
+ip6frag_high_thresh - INTEGER
+        Maximum memory used to reassemble IPv6 fragments. When 
+        ip6frag_high_thresh bytes of memory is allocated for this purpose,
+        the fragment handler will toss packets until ip6frag_low_thresh
+        is reached.
+        
+ip6frag_low_thresh - INTEGER
+        See ip6frag_high_thresh 
+
+ip6frag_time - INTEGER
+        Time in seconds to keep an IPv6 fragment in memory.
+
+ip6frag_secret_interval - INTEGER
+        Regeneration interval (in seconds) of the hash secret (or lifetime 
+        for the hash secret) for IPv6 fragments.
+        Default: 600
+
+conf/default/*:
+        Change the interface-specific default settings.
+
+
+conf/all/*:
+        Change all the interface-specific settings.  
+
+        [XXX:  Other special features than forwarding?]
+
+conf/all/forwarding - BOOLEAN
+        Enable global IPv6 forwarding between all interfaces.  
+
+        IPv4 and IPv6 work differently here; e.g. netfilter must be used 
+        to control which interfaces may forward packets and which not.
+
+        This also sets all interfaces' Host/Router setting 
+        'forwarding' to the specified value.  See below for details.
+
+        This referred to as global forwarding.
+
+conf/interface/*:
+        Change special settings per interface.
+
+        The functional behaviour for certain settings is different 
+        depending on whether local forwarding is enabled or not.
+
+accept_ra - BOOLEAN
+        Accept Router Advertisements; autoconfigure using them.
+        
+        Functional default: enabled if local forwarding is disabled.
+                            disabled if local forwarding is enabled.
+
+accept_redirects - BOOLEAN
+        Accept Redirects.
+
+        Functional default: enabled if local forwarding is disabled.
+                            disabled if local forwarding is enabled.
+
+autoconf - BOOLEAN
+        Autoconfigure addresses using Prefix Information in Router 
+        Advertisements.
+
+        Functional default: enabled if accept_ra is enabled.
+                            disabled if accept_ra is disabled.
+
+dad_transmits - INTEGER
+        The amount of Duplicate Address Detection probes to send.
+        Default: 1
+        
+forwarding - BOOLEAN
+        Configure interface-specific Host/Router behaviour.  
+
+        Note: It is recommended to have the same setting on all 
+        interfaces; mixed router/host scenarios are rather uncommon.
+
+        FALSE:
+
+        By default, Host behaviour is assumed.  This means:
+
+        1. IsRouter flag is not set in Neighbour Advertisements.
+        2. Router Solicitations are being sent when necessary.
+        3. If accept_ra is TRUE (default), accept Router 
+           Advertisements (and do autoconfiguration).
+        4. If accept_redirects is TRUE (default), accept Redirects.
+
+        TRUE:
+
+        If local forwarding is enabled, Router behaviour is assumed. 
+        This means exactly the reverse from the above:
+
+        1. IsRouter flag is set in Neighbour Advertisements.
+        2. Router Solicitations are not sent.
+        3. Router Advertisements are ignored.
+        4. Redirects are ignored.
+
+        Default: FALSE if global forwarding is disabled (default),
+                 otherwise TRUE.
+
+hop_limit - INTEGER
+        Default Hop Limit to set.
+        Default: 64
+
+mtu - INTEGER
+        Default Maximum Transfer Unit
+        Default: 1280 (IPv6 required minimum)
+
+router_solicitation_delay - INTEGER
+        Number of seconds to wait after interface is brought up
+        before sending Router Solicitations.
+        Default: 1
+
+router_solicitation_interval - INTEGER
+        Number of seconds to wait between Router Solicitations.
+        Default: 4
+
+router_solicitations - INTEGER
+        Number of Router Solicitations to send until assuming no 
+        routers are present.
+        Default: 3
+
+use_tempaddr - INTEGER
+        Preference for Privacy Extensions (RFC3041).
+          <= 0 : disable Privacy Extensions
+          == 1 : enable Privacy Extensions, but prefer public
+                 addresses over temporary addresses.
+          >  1 : enable Privacy Extensions and prefer temporary
+                 addresses over public addresses.
+        Default:  0 (for most devices)
+                 -1 (for point-to-point devices and loopback devices)
+
+temp_valid_lft - INTEGER
+        valid lifetime (in seconds) for temporary addresses.
+        Default: 604800 (7 days)
+
+temp_prefered_lft - INTEGER
+        Preferred lifetime (in seconds) for temporary addresses.
+        Default: 86400 (1 day)
+
+max_desync_factor - INTEGER
+        Maximum value for DESYNC_FACTOR, which is a random value
+        that ensures that clients don't synchronize with each 
+        other and generate new addresses at exactly the same time.
+        value is in seconds.
+        Default: 600
+        
+regen_max_retry - INTEGER
+        Number of attempts before give up attempting to generate
+        valid temporary addresses.
+        Default: 5
+
+max_addresses - INTEGER
+        Number of maximum addresses per interface.  0 disables limitation.
+        It is recommended not set too large value (or 0) because it would 
+        be too easy way to crash kernel to allow to create too much of 
+        autoconfigured addresses.
+        Default: 16
+
+icmp/*:
+ratelimit - INTEGER
+        Limit the maximal rates for sending ICMPv6 packets.
+        0 to disable any limiting, otherwise the maximal rate in jiffies(1)
+        Default: 100
+
+
+IPv6 Update by:
+Pekka Savola <pekkas@netcore.fi>
+YOSHIFUJI Hideaki / USAGI Project <yoshfuji@linux-ipv6.org>
+
+
+/proc/sys/net/bridge/* Variables:
+
+bridge-nf-call-arptables - BOOLEAN
+        1 : pass bridged ARP traffic to arptables' FORWARD chain.
+        0 : disable this.
+        Default: 1
+
+bridge-nf-call-iptables - BOOLEAN
+        1 : pass bridged IPv4 traffic to iptables' chains.
+        0 : disable this.
+        Default: 1
+
+bridge-nf-call-ip6tables - BOOLEAN
+        1 : pass bridged IPv6 traffic to ip6tables' chains.
+        0 : disable this.
+        Default: 1
+
+bridge-nf-filter-vlan-tagged - BOOLEAN
+        1 : pass bridged vlan-tagged ARP/IP traffic to arptables/iptables.
+        0 : disable this.
+        Default: 1
+
+
+UNDOCUMENTED:
+
+dev_weight FIXME
+discovery_slots FIXME
+discovery_timeout FIXME
+fast_poll_increase FIXME
+ip6_queue_maxlen FIXME
+lap_keepalive_time FIXME
+lo_cong FIXME
+max_baud_rate FIXME
+max_dgram_qlen FIXME
+max_noreply_time FIXME
+max_tx_data_size FIXME
+max_tx_window FIXME
+min_tx_turn_time FIXME
+mod_cong FIXME
+no_cong FIXME
+no_cong_thresh FIXME
+slot_timeout FIXME
+warn_noreply_time FIXME
+
+$Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $
diff --git a/Documentation/networking/ip_dynaddr.txt b/Documentation/networking/ip_dynaddr.txt
new file mode 100644
index 00000000000..45f3c1268e8
--- /dev/null
+++ b/Documentation/networking/ip_dynaddr.txt
@@ -0,0 +1,29 @@
+IP dynamic address hack-port v0.03
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This stuff allows diald ONESHOT connections to get established by
+dynamically changing packet source address (and socket's if local procs).
+It is implemented for TCP diald-box connections(1) and IP_MASQuerading(2).
+
+If enabled[*] and forwarding interface has changed:
+  1)  Socket (and packet) source address is rewritten ON RETRANSMISSIONS
+      while in SYN_SENT state (diald-box processes).
+  2)  Out-bounded MASQueraded source address changes ON OUTPUT (when
+      internal host does retransmission) until a packet from outside is
+      received by the tunnel.
+
+This is specially helpful for auto dialup links (diald), where the
+``actual'' outgoing address is unknown at the moment the link is
+going up. So, the *same* (local AND masqueraded) connections requests that
+bring the link up will be able to get established.
+
+[*] At boot, by default no address rewriting is attempted. 
+  To enable:
+     # echo 1 > /proc/sys/net/ipv4/ip_dynaddr
+  To enable verbose mode:
+     # echo 2 > /proc/sys/net/ipv4/ip_dynaddr
+  To disable (default)
+     # echo 0 > /proc/sys/net/ipv4/ip_dynaddr
+
+Enjoy!
+
+-- Juanjo  <jjciarla@raiz.uncu.edu.ar>
diff --git a/Documentation/networking/ipddp.txt b/Documentation/networking/ipddp.txt
new file mode 100644
index 00000000000..661a5558dd8
--- /dev/null
+++ b/Documentation/networking/ipddp.txt
@@ -0,0 +1,78 @@
+Text file for ipddp.c:
+        AppleTalk-IP Decapsulation and AppleTalk-IP Encapsulation
+
+This text file is written by Jay Schulist <jschlst@samba.org>
+
+Introduction
+------------
+
+AppleTalk-IP (IPDDP) is the method computers connected to AppleTalk
+networks can use to communicate via IP. AppleTalk-IP is simply IP datagrams
+inside AppleTalk packets.
+
+Through this driver you can either allow your Linux box to communicate
+IP over an AppleTalk network or you can provide IP gatewaying functions
+for your AppleTalk users.
+
+You can currently encapsulate or decapsulate AppleTalk-IP on LocalTalk,
+EtherTalk and PPPTalk. The only limit on the protocol is that of what
+kernel AppleTalk layer and drivers are available.
+
+Each mode requires its own user space software.
+
+Compiling AppleTalk-IP Decapsulation/Encapsulation
+=================================================
+
+AppleTalk-IP decapsulation needs to be compiled into your kernel. You
+will need to turn on AppleTalk-IP driver support. Then you will need to
+select ONE of the two options; IP to AppleTalk-IP encapsulation support or
+AppleTalk-IP to IP decapsulation support. If you compile the driver
+statically you will only be able to use the driver for the function you have
+enabled in the kernel. If you compile the driver as a module you can
+select what mode you want it to run in via a module loading param.
+ipddp_mode=1 for AppleTalk-IP encapsulation and ipddp_mode=2 for
+AppleTalk-IP to IP decapsulation.
+
+Basic instructions for user space tools
+=======================================
+
+To enable AppleTalk-IP decapsulation/encapsulation you will need the 
+proper tools. You can get the tools for decapsulation from
+http://spacs1.spacs.k12.wi.us/~jschlst/index.html and for encapsulation
+from http://www.maths.unm.edu/~bradford/ltpc.html
+
+I will briefly describe the operation of the tools, but you will
+need to consult the supporting documentation for each set of tools.
+
+Decapsulation - You will need to download a software package called
+MacGate. In this distribution there will be a tool called MacRoute
+which enables you to add routes to the kernel for your Macs by hand.
+Also the tool MacRegGateWay is included to register the
+proper IP Gateway and IP addresses for your machine. Included in this
+distribution is a patch to netatalk-1.4b2+asun2.0a17.2 (available from
+ftp.u.washington.edu/pub/user-supported/asun/) this patch is optional
+but it allows automatic adding and deleting of routes for Macs. (Handy
+for locations with large Mac installations)
+
+Encapsulation - You will need to download a software daemon called ipddpd.
+This software expects there to be an AppleTalk-IP gateway on the network.
+You will also need to add the proper routes to route your Linux box's IP
+traffic out the ipddp interface.
+
+Common Uses of ipddp.c
+----------------------
+Of course AppleTalk-IP decapsulation and encapsulation, but specifically
+decapsulation is being used most for connecting LocalTalk networks to
+IP networks. Although it has been used on EtherTalk networks to allow
+Macs that are only able to tunnel IP over EtherTalk.
+
+Encapsulation has been used to allow a Linux box stuck on a LocalTalk
+network to use IP. It should work equally well if you are stuck on an
+EtherTalk only network.
+
+Further Assistance
+-------------------
+You can contact me (Jay Schulist <jschlst@samba.org>) with any
+questions regarding decapsulation or encapsulation. Bradford W. Johnson
+<johns393@maroon.tc.umn.edu> originally wrote the ipddp.c driver for IP
+encapsulation in AppleTalk.
diff --git a/Documentation/networking/iphase.txt b/Documentation/networking/iphase.txt
new file mode 100644
index 00000000000..39ccb8595bf
--- /dev/null
+++ b/Documentation/networking/iphase.txt
@@ -0,0 +1,158 @@
+
+                              READ ME FISRT
+                  ATM (i)Chip IA Linux Driver Source
+--------------------------------------------------------------------------------
+                     Read This Before You Begin!
+--------------------------------------------------------------------------------
+
+Description
+-----------
+
+This is the README file for the Interphase PCI ATM (i)Chip IA Linux driver 
+source release.
+
+The features and limitations of this driver are as follows:
+    - A single VPI (VPI value of 0) is supported.
+    - Supports 4K VCs for the server board (with 512K control memory) and 1K 
+      VCs for the client board (with 128K control memory).
+    - UBR, ABR and CBR service categories are supported.
+    - Only AAL5 is supported. 
+    - Supports setting of PCR on the VCs. 
+    - Multiple adapters in a system are supported.
+    - All variants of Interphase ATM PCI (i)Chip adapter cards are supported, 
+      including x575 (OC3, control memory 128K , 512K and packet memory 128K, 
+      512K and 1M), x525 (UTP25) and x531 (DS3 and E3). See 
+           http://www.iphase.com/products/ClassSheet.cfm?ClassID=ATM 
+      for details.
+    - Only x86 platforms are supported.
+    - SMP is supported.
+
+
+Before You Start
+---------------- 
+
+
+Installation
+------------
+
+1. Installing the adapters in the system
+   To install the ATM adapters in the system, follow the steps below.
+       a. Login as root.
+       b. Shut down the system and power off the system.
+       c. Install one or more ATM adapters in the system.
+       d. Connect each adapter to a port on an ATM switch. The green 'Link' 
+          LED on the front panel of the adapter will be on if the adapter is 
+          connected to the switch properly when the system is powered up.
+       e. Power on and boot the system.
+
+2. [ Removed ]
+
+3. Rebuild kernel with ABR support
+   [ a. and b. removed ]
+    c. Reconfigure the kernel, choose the Interphase ia driver through "make 
+       menuconfig" or "make xconfig".
+    d. Rebuild the kernel, loadable modules and the atm tools. 
+    e. Install the new built kernel and modules and reboot.
+
+4. Load the adapter hardware driver (ia driver) if it is built as a module
+       a. Login as root.
+       b. Change directory to /lib/modules/<kernel-version>/atm.
+       c. Run "insmod suni.o;insmod iphase.o"
+          The yellow 'status' LED on the front panel of the adapter will blink 
+          while the driver is loaded in the system.
+       d. To verify that the 'ia' driver is loaded successfully, run the 
+          following command:
+
+              cat /proc/atm/devices
+
+          If the driver is loaded successfully, the output of the command will 
+          be similar to the following lines:
+
+              Itf Type    ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...
+              0   ia      xxxxxxxxx  0 ( 0 0 0 0 0 )  5 ( 0 0 0 0 0 )
+
+          You can also check the system log file /var/log/messages for messages
+          related to the ATM driver.
+
+5. Ia Driver Configuration 
+
+5.1 Configuration of adapter buffers
+    The (i)Chip boards have 3 different packet RAM size variants: 128K, 512K and
+    1M. The RAM size decides the number of buffers and buffer size. The default 
+    size and number of buffers are set as following: 
+
+          Totol    Rx RAM   Tx RAM   Rx Buf   Tx Buf   Rx buf   Tx buf
+         RAM size   size     size     size     size      cnt      cnt
+         --------  ------   ------   ------   ------   ------   ------
+           128K      64K      64K      10K      10K       6        6
+           512K     256K     256K      10K      10K      25       25
+             1M     512K     512K      10K      10K      51       51
+
+       These setting should work well in most environments, but can be
+       changed by typing the following command: 
+ 
+           insmod <IA_DIR>/ia.o IA_RX_BUF=<RX_CNT> IA_RX_BUF_SZ=<RX_SIZE> \
+                   IA_TX_BUF=<TX_CNT> IA_TX_BUF_SZ=<TX_SIZE> 
+       Where:
+            RX_CNT = number of receive buffers in the range (1-128)
+            RX_SIZE = size of receive buffers in the range (48-64K)
+            TX_CNT = number of transmit buffers in the range (1-128)
+            TX_SIZE = size of transmit buffers in the range (48-64K)
+
+            1. Transmit and receive buffer size must be a multiple of 4.
+            2. Care should be taken so that the memory required for the
+               transmit and receive buffers is less than or equal to the
+               total adapter packet memory.   
+
+5.2 Turn on ia debug trace
+
+    When the ia driver is built with the CONFIG_ATM_IA_DEBUG flag, the driver 
+    can provide more debug trace if needed. There is a bit mask variable, 
+    IADebugFlag, which controls the output of the traces. You can find the bit 
+    map of the IADebugFlag in iphase.h. 
+    The debug trace can be turn on through the insmod command line option, for 
+    example, "insmod iphase.o IADebugFlag=0xffffffff" can turn on all the debug 
+    traces together with loading the driver.
+
+6. Ia Driver Test Using ttcp_atm and PVC
+
+   For the PVC setup, the test machines can either be connected back-to-back or 
+   through a switch. If connected through the switch, the switch must be 
+   configured for the PVC(s).
+
+   a. For UBR test:
+      At the test machine intended to receive data, type:
+         ttcp_atm -r -a -s 0.100 
+      At the other test machine, type:
+         ttcp_atm -t -a -s 0.100 -n 10000
+      Run "ttcp_atm -h" to display more options of the ttcp_atm tool.
+   b. For ABR test:
+      It is the same as the UBR testing, but with an extra command option:
+         -Pabr:max_pcr=<xxx>
+         where:
+             xxx = the maximum peak cell rate, from 170 - 353207.
+         This option must be set on both the machines.
+   c. For CBR test:
+      It is the same as the UBR testing, but with an extra command option:
+         -Pcbr:max_pcr=<xxx>
+         where:
+             xxx = the maximum peak cell rate, from 170 - 353207.
+         This option may only be set on the transmit machine.
+
+
+OUTSTANDING ISSUES
+------------------
+
+
+
+Contact Information
+-------------------
+
+     Customer Support:
+         United States: Telephone:      (214) 654-5555
+                        Fax:            (214) 654-5500
+                        E-Mail:         intouch@iphase.com
+         Europe:        Telephone:      33 (0)1 41 15 44 00
+                        Fax:            33 (0)1 41 15 12 13
+     World Wide Web:    http://www.iphase.com
+     Anonymous FTP:     ftp.iphase.com
diff --git a/Documentation/networking/irda.txt b/Documentation/networking/irda.txt
new file mode 100644
index 00000000000..9e5b8e66d6a
--- /dev/null
+++ b/Documentation/networking/irda.txt
@@ -0,0 +1,14 @@
+To use the IrDA protocols within Linux you will need to get a suitable copy
+of the IrDA Utilities. More detailed information about these and associated
+programs can be found on http://irda.sourceforge.net/
+
+For more information about how to use the IrDA protocol stack, see the
+Linux Infared HOWTO (http://www.tuxmobil.org/Infrared-HOWTO/Infrared-HOWTO.html)
+by Werner Heuser <wehe@tuxmobil.org>
+
+There is an active mailing list for discussing Linux-IrDA matters called
+    irda-users@lists.sourceforge.net
+
+
+
+
diff --git a/Documentation/networking/ixgb.txt b/Documentation/networking/ixgb.txt
new file mode 100644
index 00000000000..7c98277777e
--- /dev/null
+++ b/Documentation/networking/ixgb.txt
@@ -0,0 +1,212 @@
+Linux* Base Driver for the Intel(R) PRO/10GbE Family of Adapters
+================================================================
+
+November 17, 2004
+
+
+Contents
+========
+
+- In This Release
+- Identifying Your Adapter
+- Command Line Parameters
+- Improving Performance
+- Support
+
+
+In This Release
+===============
+
+This file describes the Linux* Base Driver for the Intel(R) PRO/10GbE Family 
+of Adapters, version 1.0.x.  
+
+For questions related to hardware requirements, refer to the documentation 
+supplied with your Intel PRO/10GbE adapter. All hardware requirements listed 
+apply to use with Linux.
+
+Identifying Your Adapter
+========================
+
+To verify your Intel adapter is supported, find the board ID number on the 
+adapter. Look for a label that has a barcode and a number in the format  
+A12345-001. 
+
+Use the above information and the Adapter & Driver ID Guide at:
+
+  http://support.intel.com/support/network/adapter/pro100/21397.htm
+
+For the latest Intel network drivers for Linux, go to:
+
+    http://downloadfinder.intel.com/scripts-df/support_intel.asp
+
+Command Line Parameters
+=======================
+
+If the driver is built as a module, the  following optional parameters are 
+used by entering them on the command line with the modprobe or insmod command
+using this syntax:
+
+     modprobe ixgb [<option>=<VAL1>,<VAL2>,...]
+
+     insmod ixgb [<option>=<VAL1>,<VAL2>,...]
+
+For example, with two PRO/10GbE PCI adapters, entering:
+
+    insmod ixgb TxDescriptors=80,128
+
+loads the ixgb driver with 80 TX resources for the first adapter and 128 TX 
+resources for the second adapter.
+
+The default value for each parameter is generally the recommended setting,
+unless otherwise noted. Also, if the driver is statically built into the
+kernel, the driver is loaded with the default values for all the parameters.
+Ethtool can be used to change some of the parameters at runtime.
+
+FlowControl
+Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
+Default: Read from the EEPROM
+         If EEPROM is not detected, default is 3
+    This parameter controls the automatic generation(Tx) and response(Rx) to 
+    Ethernet PAUSE frames.
+
+RxDescriptors
+Valid Range: 64-512
+Default Value: 512
+    This value is the number of receive descriptors allocated by the driver. 
+    Increasing this value allows the driver to buffer more incoming packets. 
+    Each descriptor is 16 bytes.  A receive buffer is also allocated for 
+    each descriptor and can be either 2048, 4056, 8192, or 16384 bytes, 
+    depending on the MTU setting. When the MTU size is 1500 or less, the 
+    receive buffer size is 2048 bytes. When the MTU is greater than 1500 the
+    receive buffer size will be either 4056, 8192, or 16384 bytes. The 
+    maximum MTU size is 16114.
+
+RxIntDelay
+Valid Range: 0-65535 (0=off)
+Default Value: 6
+    This value delays the generation of receive interrupts in units of 
+    0.8192 microseconds.  Receive interrupt reduction can improve CPU 
+    efficiency if properly tuned for specific network traffic. Increasing 
+    this value adds extra latency to frame reception and can end up 
+    decreasing the throughput of TCP traffic. If the system is reporting 
+    dropped receives, this value may be set too high, causing the driver to 
+    run out of available receive descriptors.
+
+TxDescriptors
+Valid Range: 64-4096
+Default Value: 256
+    This value is the number of transmit descriptors allocated by the driver.
+    Increasing this value allows the driver to queue more transmits. Each 
+    descriptor is 16 bytes.
+
+XsumRX
+Valid Range: 0-1
+Default Value: 1
+    A value of '1' indicates that the driver should enable IP checksum
+    offload for received packets (both UDP and TCP) to the adapter hardware.
+
+XsumTX
+Valid Range: 0-1
+Default Value: 1
+    A value of '1' indicates that the driver should enable IP checksum
+    offload for transmitted packets (both UDP and TCP) to the adapter 
+    hardware.
+
+Improving Performance
+=====================
+
+With the Intel PRO/10 GbE adapter, the default Linux configuration will very 
+likely limit the total available throughput artificially.  There is a set of 
+things that when applied together increase the ability of Linux to transmit 
+and receive data.  The following enhancements were originally acquired from
+settings published at http://www.spec.org/web99 for various submitted results 
+using Linux.
+
+NOTE: These changes are only suggestions, and serve as a starting point for 
+tuning your network performance.
+
+The changes are made in three major ways, listed in order of greatest effect:
+- Use ifconfig to modify the mtu (maximum transmission unit) and the txqueuelen 
+  parameter.
+- Use sysctl to modify /proc parameters (essentially kernel tuning)
+- Use setpci to modify the MMRBC field in PCI-X configuration space to increase 
+  transmit burst lengths on the bus.
+
+NOTE: setpci modifies the adapter's configuration registers to allow it to read 
+up to 4k bytes at a time (for transmits).  However, for some systems the 
+behavior after modifying this register may be undefined (possibly errors of some 
+kind). A power-cycle, hard reset or explicitly setting the e6 register back to 
+22 (setpci -d 8086:1048 e6.b=22) may be required to get back to a stable 
+configuration.
+
+- COPY these lines and paste them into ixgb_perf.sh:
+#!/bin/bash
+echo "configuring network performance , edit this file to change the interface"
+# set mmrbc to 4k reads, modify only Intel 10GbE device IDs
+setpci -d 8086:1048 e6.b=2e
+# set the MTU (max transmission unit) - it requires your switch and clients to change too!
+# set the txqueuelen
+# your ixgb adapter should be loaded as eth1 for this to work, change if needed
+ifconfig eth1 mtu 9000 txqueuelen 1000 up
+# call the sysctl utility to modify /proc/sys entries 
+sysctl -p ./sysctl_ixgb.conf 
+- END ixgb_perf.sh
+
+- COPY these lines and paste them into sysctl_ixgb.conf:
+# some of the defaults may be different for your kernel
+# call this file with sysctl -p <this file>
+# these are just suggested values that worked well to increase throughput in
+# several network benchmark tests, your mileage may vary
+
+### IPV4 specific settings
+net.ipv4.tcp_timestamps = 0 # turns TCP timestamp support off, default 1, reduces CPU use
+net.ipv4.tcp_sack = 0 # turn SACK support off, default on
+# on systems with a VERY fast bus -> memory interface this is the big gainer 
+net.ipv4.tcp_rmem = 10000000 10000000 10000000 # sets min/default/max TCP read buffer, default 4096 87380 174760
+net.ipv4.tcp_wmem = 10000000 10000000 10000000 # sets min/pressure/max TCP write buffer, default 4096 16384 131072
+net.ipv4.tcp_mem = 10000000 10000000 10000000 # sets min/pressure/max TCP buffer space, default 31744 32256 32768
+
+### CORE settings (mostly for socket and UDP effect)
+net.core.rmem_max = 524287 # maximum receive socket buffer size, default 131071
+net.core.wmem_max = 524287 # maximum send socket buffer size, default 131071
+net.core.rmem_default = 524287 # default receive socket buffer size, default 65535
+net.core.wmem_default = 524287 # default send socket buffer size, default 65535
+net.core.optmem_max = 524287 # maximum amount of option memory buffers, default 10240
+net.core.netdev_max_backlog = 300000 # number of unprocessed input packets before kernel starts dropping them, default 300
+- END sysctl_ixgb.conf
+
+Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface 
+your ixgb driver is using.
+
+NOTE: Unless these scripts are added to the boot process, these changes will 
+only last only until the next system reboot.
+
+
+Resolving Slow UDP Traffic
+--------------------------
+
+If your server does not seem to be able to receive UDP traffic as fast as it 
+can receive TCP traffic, it could be because Linux, by default, does not set 
+the network stack buffers as large as they need to be to support high UDP 
+transfer rates. One way to alleviate this problem is to allow more memory to 
+be used by the IP stack to store incoming data. 
+
+For instance, use the commands: 
+    sysctl -w net.core.rmem_max=262143
+and
+    sysctl -w net.core.rmem_default=262143
+to increase the read buffer memory max and default to 262143 (256k - 1) from 
+defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables 
+will increase the amount of memory used by the network stack for receives, and 
+can be increased significantly more if necessary for your application.
+
+Support
+=======
+
+For general information and support, go to the Intel support website at:
+
+    http://support.intel.com
+
+If an issue is identified with the released source code on the supported
+kernel with a supported adapter, email the specific information related to 
+the issue to linux.nics@intel.com.
diff --git a/Documentation/networking/lapb-module.txt b/Documentation/networking/lapb-module.txt
new file mode 100644
index 00000000000..d4fc8f22155
--- /dev/null
+++ b/Documentation/networking/lapb-module.txt
@@ -0,0 +1,263 @@
+                The Linux LAPB Module Interface 1.3
+
+                      Jonathan Naylor 29.12.96
+
+Changed (Henner Eisen, 2000-10-29): int return value for data_indication() 
+
+The LAPB module will be a separately compiled module for use by any parts of
+the Linux operating system that require a LAPB service. This document
+defines the interfaces to, and the services provided by this module. The
+term module in this context does not imply that the LAPB module is a
+separately loadable module, although it may be. The term module is used in
+its more standard meaning.
+
+The interface to the LAPB module consists of functions to the module,
+callbacks from the module to indicate important state changes, and
+structures for getting and setting information about the module.
+
+Structures
+----------
+
+Probably the most important structure is the skbuff structure for holding
+received and transmitted data, however it is beyond the scope of this
+document.
+
+The two LAPB specific structures are the LAPB initialisation structure and
+the LAPB parameter structure. These will be defined in a standard header
+file, <linux/lapb.h>. The header file <net/lapb.h> is internal to the LAPB
+module and is not for use.
+
+LAPB Initialisation Structure
+-----------------------------
+
+This structure is used only once, in the call to lapb_register (see below).
+It contains information about the device driver that requires the services
+of the LAPB module.
+
+struct lapb_register_struct {
+        void (*connect_confirmation)(int token, int reason);
+        void (*connect_indication)(int token, int reason);
+        void (*disconnect_confirmation)(int token, int reason);
+        void (*disconnect_indication)(int token, int reason);
+        int  (*data_indication)(int token, struct sk_buff *skb);
+        void (*data_transmit)(int token, struct sk_buff *skb);
+};
+
+Each member of this structure corresponds to a function in the device driver
+that is called when a particular event in the LAPB module occurs. These will
+be described in detail below. If a callback is not required (!!) then a NULL
+may be substituted.
+
+
+LAPB Parameter Structure
+------------------------
+
+This structure is used with the lapb_getparms and lapb_setparms functions
+(see below). They are used to allow the device driver to get and set the
+operational parameters of the LAPB implementation for a given connection.
+
+struct lapb_parms_struct {
+        unsigned int t1;
+        unsigned int t1timer;
+        unsigned int t2;
+        unsigned int t2timer;
+        unsigned int n2;
+        unsigned int n2count;
+        unsigned int window;
+        unsigned int state;
+        unsigned int mode;
+};
+
+T1 and T2 are protocol timing parameters and are given in units of 100ms. N2
+is the maximum number of tries on the link before it is declared a failure.
+The window size is the maximum number of outstanding data packets allowed to
+be unacknowledged by the remote end, the value of the window is between 1
+and 7 for a standard LAPB link, and between 1 and 127 for an extended LAPB
+link.
+
+The mode variable is a bit field used for setting (at present) three values.
+The bit fields have the following meanings:
+
+Bit     Meaning
+0       LAPB operation (0=LAPB_STANDARD 1=LAPB_EXTENDED).
+1       [SM]LP operation (0=LAPB_SLP 1=LAPB=MLP).
+2       DTE/DCE operation (0=LAPB_DTE 1=LAPB_DCE)
+3-31    Reserved, must be 0.
+
+Extended LAPB operation indicates the use of extended sequence numbers and
+consequently larger window sizes, the default is standard LAPB operation.
+MLP operation is the same as SLP operation except that the addresses used by
+LAPB are different to indicate the mode of operation, the default is Single
+Link Procedure. The difference between DCE and DTE operation is (i) the
+addresses used for commands and responses, and (ii) when the DCE is not
+connected, it sends DM without polls set, every T1. The upper case constant
+names will be defined in the public LAPB header file.
+
+
+Functions
+---------
+
+The LAPB module provides a number of function entry points.
+
+
+int lapb_register(void *token, struct lapb_register_struct);
+
+This must be called before the LAPB module may be used. If the call is
+successful then LAPB_OK is returned. The token must be a unique identifier
+generated by the device driver to allow for the unique identification of the
+instance of the LAPB link. It is returned by the LAPB module in all of the
+callbacks, and is used by the device driver in all calls to the LAPB module.
+For multiple LAPB links in a single device driver, multiple calls to
+lapb_register must be made. The format of the lapb_register_struct is given
+above. The return values are:
+
+LAPB_OK                 LAPB registered successfully.
+LAPB_BADTOKEN           Token is already registered.
+LAPB_NOMEM              Out of memory
+
+
+int lapb_unregister(void *token);
+
+This releases all the resources associated with a LAPB link. Any current
+LAPB link will be abandoned without further messages being passed. After
+this call, the value of token is no longer valid for any calls to the LAPB
+function. The valid return values are:
+
+LAPB_OK                 LAPB unregistered successfully.
+LAPB_BADTOKEN           Invalid/unknown LAPB token.
+
+
+int lapb_getparms(void *token, struct lapb_parms_struct *parms);
+
+This allows the device driver to get the values of the current LAPB
+variables, the lapb_parms_struct is described above. The valid return values
+are:
+
+LAPB_OK                 LAPB getparms was successful.
+LAPB_BADTOKEN           Invalid/unknown LAPB token.
+
+
+int lapb_setparms(void *token, struct lapb_parms_struct *parms);
+
+This allows the device driver to set the values of the current LAPB
+variables, the lapb_parms_struct is described above. The values of t1timer,
+t2timer and n2count are ignored, likewise changing the mode bits when
+connected will be ignored. An error implies that none of the values have
+been changed. The valid return values are:
+
+LAPB_OK                 LAPB getparms was successful.
+LAPB_BADTOKEN           Invalid/unknown LAPB token.
+LAPB_INVALUE            One of the values was out of its allowable range.
+
+
+int lapb_connect_request(void *token);
+
+Initiate a connect using the current parameter settings. The valid return
+values are:
+
+LAPB_OK                 LAPB is starting to connect.
+LAPB_BADTOKEN           Invalid/unknown LAPB token.
+LAPB_CONNECTED          LAPB module is already connected.
+
+
+int lapb_disconnect_request(void *token);
+
+Initiate a disconnect. The valid return values are:
+
+LAPB_OK                 LAPB is starting to disconnect.
+LAPB_BADTOKEN           Invalid/unknown LAPB token.
+LAPB_NOTCONNECTED       LAPB module is not connected.
+
+
+int lapb_data_request(void *token, struct sk_buff *skb);
+
+Queue data with the LAPB module for transmitting over the link. If the call
+is successful then the skbuff is owned by the LAPB module and may not be
+used by the device driver again. The valid return values are:
+
+LAPB_OK                 LAPB has accepted the data.
+LAPB_BADTOKEN           Invalid/unknown LAPB token.
+LAPB_NOTCONNECTED       LAPB module is not connected.
+
+
+int lapb_data_received(void *token, struct sk_buff *skb);
+
+Queue data with the LAPB module which has been received from the device. It
+is expected that the data passed to the LAPB module has skb->data pointing
+to the beginning of the LAPB data. If the call is successful then the skbuff
+is owned by the LAPB module and may not be used by the device driver again.
+The valid return values are:
+
+LAPB_OK                 LAPB has accepted the data.
+LAPB_BADTOKEN           Invalid/unknown LAPB token.
+
+
+Callbacks
+---------
+
+These callbacks are functions provided by the device driver for the LAPB
+module to call when an event occurs. They are registered with the LAPB
+module with lapb_register (see above) in the structure lapb_register_struct
+(see above).
+
+
+void (*connect_confirmation)(void *token, int reason);
+
+This is called by the LAPB module when a connection is established after
+being requested by a call to lapb_connect_request (see above). The reason is
+always LAPB_OK.
+
+
+void (*connect_indication)(void *token, int reason);
+
+This is called by the LAPB module when the link is established by the remote
+system. The value of reason is always LAPB_OK.
+
+
+void (*disconnect_confirmation)(void *token, int reason);
+
+This is called by the LAPB module when an event occurs after the device
+driver has called lapb_disconnect_request (see above). The reason indicates
+what has happened. In all cases the LAPB link can be regarded as being
+terminated. The values for reason are:
+
+LAPB_OK                 The LAPB link was terminated normally.
+LAPB_NOTCONNECTED       The remote system was not connected.
+LAPB_TIMEDOUT           No response was received in N2 tries from the remote
+                        system.
+
+
+void (*disconnect_indication)(void *token, int reason);
+
+This is called by the LAPB module when the link is terminated by the remote
+system or another event has occurred to terminate the link. This may be
+returned in response to a lapb_connect_request (see above) if the remote
+system refused the request. The values for reason are:
+
+LAPB_OK                 The LAPB link was terminated normally by the remote
+                        system.
+LAPB_REFUSED            The remote system refused the connect request.
+LAPB_NOTCONNECTED       The remote system was not connected.
+LAPB_TIMEDOUT           No response was received in N2 tries from the remote
+                        system.
+
+
+int (*data_indication)(void *token, struct sk_buff *skb);
+
+This is called by the LAPB module when data has been received from the
+remote system that should be passed onto the next layer in the protocol
+stack. The skbuff becomes the property of the device driver and the LAPB
+module will not perform any more actions on it. The skb->data pointer will
+be pointing to the first byte of data after the LAPB header.
+
+This method should return NET_RX_DROP (as defined in the header
+file include/linux/netdevice.h) if and only if the frame was dropped
+before it could be delivered to the upper layer.
+
+
+void (*data_transmit)(void *token, struct sk_buff *skb);
+
+This is called by the LAPB module when data is to be transmitted to the
+remote system by the device driver. The skbuff becomes the property of the
+device driver and the LAPB module will not perform any more actions on it.
+The skb->data pointer will be pointing to the first byte of the LAPB header.
diff --git a/Documentation/networking/ltpc.txt b/Documentation/networking/ltpc.txt
new file mode 100644
index 00000000000..fe2a9129d95
--- /dev/null
+++ b/Documentation/networking/ltpc.txt
@@ -0,0 +1,131 @@
+This is the ALPHA version of the ltpc driver.
+
+In order to use it, you will need at least version 1.3.3 of the
+netatalk package, and the Apple or Farallon LocalTalk PC card.
+There are a number of different LocalTalk cards for the PC; this
+driver applies only to the one with the 65c02 processor chip on it.
+
+To include it in the kernel, select the CONFIG_LTPC switch in the
+configuration dialog.  You can also compile it as a module.
+
+While the driver will attempt to autoprobe the I/O port address, IRQ
+line, and DMA channel of the card, this does not always work.  For
+this reason, you should be prepared to supply these parameters
+yourself.  (see "Card Configuration" below for how to determine or
+change the settings on your card)
+
+When the driver is compiled into the kernel, you can add a line such
+as the following to your /etc/lilo.conf:
+
+ append="ltpc=0x240,9,1"
+
+where the parameters (in order) are the port address, IRQ, and DMA
+channel.  The second and third values can be omitted, in which case
+the driver will try to determine them itself.
+
+If you load the driver as a module, you can pass the parameters "io=",
+"irq=", and "dma=" on the command line with insmod or modprobe, or add
+them as options in /etc/modprobe.conf:
+
+ alias lt0 ltpc # autoload the module when the interface is configured
+ options ltpc io=0x240 irq=9 dma=1
+
+Before starting up the netatalk demons (perhaps in rc.local), you
+need to add a line such as:
+
+ /sbin/ifconfig lt0 127.0.0.42
+
+The address is unimportant - however, the card needs to be configured
+with ifconfig so that Netatalk can find it.
+
+The appropriate netatalk configuration depends on whether you are
+attached to a network that includes AppleTalk routers or not.  If,
+like me, you are simply connecting to your home Macintoshes and
+printers, you need to set up netatalk to "seed".  The way I do this
+is to have the lines
+
+ dummy -seed -phase 2 -net 2000 -addr 2000.26 -zone "1033"
+ lt0 -seed -phase 1 -net 1033 -addr 1033.27 -zone "1033"
+
+in my atalkd.conf.  What is going on here is that I need to fool
+netatalk into thinking that there are two AppleTalk interfaces
+present; otherwise, it refuses to seed.  This is a hack, and a more
+permanent solution would be to alter the netatalk code.  Also, make
+sure you have the correct name for the dummy interface - If it's
+compiled as a module, you will need to refer to it as "dummy0" or some
+such.
+
+If you are attached to an extended AppleTalk network, with routers on
+it, then you don't need to fool around with this -- the appropriate
+line in atalkd.conf is
+
+ lt0 -phase 1
+
+--------------------------------------
+
+Card Configuration:
+
+The interrupts and so forth are configured via the dipswitch on the
+board.  Set the switches so as not to conflict with other hardware.
+
+       Interrupts -- set at most one.  If none are set, the driver uses
+       polled mode.  Because the card was developed in the XT era, the
+       original documentation refers to IRQ2.  Since you'll be running
+       this on an AT (or later) class machine, that really means IRQ9.
+
+       SW1     IRQ 4
+       SW2     IRQ 3
+       SW3     IRQ 9 (2 in original card documentation only applies to XT)
+
+
+       DMA -- choose DMA 1 or 3, and set both corresponding switches.
+
+       SW4     DMA 3
+       SW5     DMA 1
+       SW6     DMA 3
+       SW7     DMA 1
+
+
+       I/O address -- choose one.
+
+       SW8     220 / 240
+
+--------------------------------------
+
+IP:
+
+Yes, it is possible to do IP over LocalTalk.  However, you can't just
+treat the LocalTalk device like an ordinary Ethernet device, even if
+that's what it looks like to Netatalk.
+
+Instead, you follow the same procedure as for doing IP in EtherTalk.
+See Documentation/networking/ipddp.txt for more information about the
+kernel driver and userspace tools needed.
+
+--------------------------------------
+
+BUGS:
+
+IRQ autoprobing often doesn't work on a cold boot.  To get around
+this, either compile the driver as a module, or pass the parameters
+for the card to the kernel as described above.
+
+Also, as usual, autoprobing is not recommended when you use the driver
+as a module. (though it usually works at boot time, at least)
+
+Polled mode is *really* slow sometimes, but this seems to depend on
+the configuration of the network.
+
+It may theoretically be possible to use two LTPC cards in the same
+machine, but this is unsupported, so if you really want to do this,
+you'll probably have to hack the initialization code a bit.
+
+______________________________________
+
+THANKS:
+        Thanks to Alan Cox for helpful discussions early on in this
+work, and to Denis Hainsworth for doing the bleeding-edge testing.
+
+-- Bradford Johnson <bradford@math.umn.edu>
+
+-- Updated 11/09/1998 by David Huggins-Daines <dhd@debian.org>
diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt
new file mode 100644
index 00000000000..5049a64313d
--- /dev/null
+++ b/Documentation/networking/multicast.txt
@@ -0,0 +1,64 @@
+Behaviour of Cards Under Multicast
+==================================
+
+This is how they currently behave, not what the hardware can do--for example,
+the Lance driver doesn't use its filter, even though the code for loading
+it is in the DEC Lance-based driver.
+
+The following are requirements for multicasting 
+-----------------------------------------------
+AppleTalk       Multicast       hardware filtering not important but
+                                 avoid cards only doing promisc
+IP-Multicast    Multicast       hardware filters really help
+IP-MRoute       AllMulti        hardware filters are of no help
+
+
+Board           Multicast       AllMulti        Promisc         Filter
+------------------------------------------------------------------------
+3c501           YES             YES             YES             Software
+3c503           YES             YES             YES             Hardware
+3c505           YES             NO              YES             Hardware
+3c507           NO              NO              NO              N/A
+3c509           YES             YES             YES             Software
+3c59x           YES             YES             YES             Software
+ac3200          YES             YES             YES             Hardware
+apricot         YES             PROMISC         YES             Hardware
+arcnet          NO              NO              NO              N/A
+at1700          PROMISC         PROMISC         YES             Software
+atp             PROMISC         PROMISC         YES             Software
+cs89x0          YES             YES             YES             Software
+de4x5           YES             YES             YES             Hardware
+de600           NO              NO              NO              N/A
+de620           PROMISC         PROMISC         YES             Software
+depca           YES             PROMISC         YES             Hardware
+dmfe            YES             YES             YES             Software(*)
+e2100           YES             YES             YES             Hardware
+eepro           YES             PROMISC         YES             Hardware
+eexpress        NO              NO              NO              N/A
+ewrk3           YES             PROMISC         YES             Hardware
+hp-plus         YES             YES             YES             Hardware
+hp              YES             YES             YES             Hardware
+hp100           YES             YES             YES             Hardware
+ibmtr           NO              NO              NO              N/A
+ioc3-eth        YES             YES             YES             Hardware
+lance           YES             YES             YES             Software(#)
+ne              YES             YES             YES             Hardware
+ni52            <------------------ Buggy ------------------>
+ni65            YES             YES             YES             Software(#)
+seeq            NO              NO              NO              N/A
+sgiseek         <------------------ Buggy ------------------>
+sk_g16          NO              NO              YES             N/A
+smc-ultra       YES             YES             YES             Hardware
+sunlance        YES             YES             YES             Hardware
+tulip           YES             YES             YES             Hardware
+wavelan         YES             PROMISC         YES             Hardware
+wd              YES             YES             YES             Hardware
+xirc2ps_cs      YES             YES             YES             Hardware
+znet            YES             YES             YES             Software
+
+
+PROMISC = This multicast mode is in fact promiscuous mode. Avoid using
+cards who go PROMISC on any multicast in a multicast kernel.
+
+(#) = Hardware multicast support is not used yet.
+(*) = Hardware support for Davicom 9132 chipset only.
diff --git a/Documentation/networking/ncsa-telnet b/Documentation/networking/ncsa-telnet
new file mode 100644
index 00000000000..d77d28b0909
--- /dev/null
+++ b/Documentation/networking/ncsa-telnet
@@ -0,0 +1,16 @@
+NCSA telnet doesn't work with path MTU discovery enabled. This is due to a
+bug in NCSA that also stops it working with other modern networking code
+such as Solaris.
+
+The following information is courtesy of 
+Marek <marekm@i17linuxb.ists.pwr.wroc.pl>
+
+There is a fixed version somewhere on ftp.upe.ac.za (sorry, I don't
+remember the exact pathname, and this site is very slow from here).
+It may or may not be faster for you to get it from
+ftp://ftp.ists.pwr.wroc.pl/pub/msdos/telnet/ncsa_upe/tel23074.zip
+(source is in v230704s.zip).  I have tested it with 1.3.79 (with
+path mtu discovery enabled - ncsa 2.3.08 didn't work) and it seems
+to work.  I don't know if anyone is working on this code - this
+version is over a year old.  Too bad - it's faster and often more
+stable than these windoze telnets, and runs on almost anything...
diff --git a/Documentation/networking/net-modules.txt b/Documentation/networking/net-modules.txt
new file mode 100644
index 00000000000..3830a83513d
--- /dev/null
+++ b/Documentation/networking/net-modules.txt
@@ -0,0 +1,324 @@
+Wed 2-Aug-95  <matti.aarnio@utu.fi>
+
+                Linux network driver modules
+
+        Do not mistake this for "README.modules" at the top-level
+        directory!  That document tells about modules in general, while
+        this one tells only about network device driver modules.
+
+        This is a potpourri of INSMOD-time(*) configuration options
+        (if such exists) and their default values of various modules
+        in the Linux network drivers collection.
+
+        Some modules have also hidden (= non-documented) tunable values.
+        The choice of not documenting them is based on general belief, that
+        the less the user needs to know, the better.  (There are things that
+        driver developers can use, others should not confuse themselves.)
+
+        In many cases it is highly preferred that insmod:ing is done
+        ONLY with defining an explicit address for the card, AND BY
+        NOT USING AUTO-PROBING!
+
+        Now most cards have some explicitly defined base address that they
+        are compiled with (to avoid auto-probing, among other things).
+        If that compiled value does not match your actual configuration,
+        do use the "io=0xXXX" -parameter for the insmod, and give there
+        a value matching your environment.
+
+        If you are adventurous, you can ask the driver to autoprobe
+        by using the "io=0" parameter, however it is a potentially dangerous
+        thing to do in a live system.  (If you don't know where the
+        card is located, you can try autoprobing, and after possible
+        crash recovery, insmod with proper IO-address..)
+
+        --------------------------
+        (*)     "INSMOD-time" means when you load module with
+                /sbin/insmod  you can feed it optional parameters.
+                See "man insmod".
+        --------------------------
+
+
+        8390 based Network Modules              (Paul Gortmaker, Nov 12, 1995)
+        --------------------------
+
+(Includes: smc-ultra, ne, wd, 3c503, hp, hp-plus, e2100 and ac3200)
+
+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 transceivers. The "insmod" manual describes the usage
+of comma separated value lists.
+
+It is *STRONGLY RECOMMENDED* that you supply "io=" instead of autoprobing.
+If an "io=" argument is not supplied, then the ISA 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.
+
+
+----------------------------------------------------------------------
+Card/Module List - Configurable Parameters and Default Values
+----------------------------------------------------------------------
+
+3c501.c:
+        io  = 0x280     IO base address
+        irq = 5         IRQ
+        (Probes ports:  0x280, 0x300)
+
+3c503.c:
+        io = 0          (It will complain if you don't supply an "io=0xNNN")
+        irq = 0         (IRQ software selected by driver using autoIRQ)
+        xcvr = 0        (Use xcvr=1 to select external transceiver.)
+        (Probes ports: 0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2A0, 0x2E0)
+
+3c505.c:
+        io = 0
+        irq = 0
+        dma = 6         (not autoprobed)
+        (Probes ports: 0x300, 0x280, 0x310)
+
+3c507.c:
+        io = 0x300
+        irq = 0
+        (Probes ports: 0x300, 0x320, 0x340, 0x280)
+
+3c509.c:
+        io = 0
+        irq = 0
+        ( Module load-time probing Works reliably only on EISA, ISA ID-PROBE
+          IS NOT RELIABLE!  Compile this driver statically into kernel for
+          now, if you need it auto-probing on an ISA-bus machine. )
+
+8390.c:
+        (No public options, several other modules need this one)
+
+a2065.c:
+        Since this is a Zorro board, it supports full autoprobing, even for
+        multiple boards. (m68k/Amiga)
+
+ac3200.c:
+        io = 0          (Checks 0x1000 to 0x8fff in 0x1000 intervals)
+        irq = 0         (Read from config register)
+        (EISA probing..)
+
+apricot.c:
+        io = 0x300  (Can't be altered!)
+        irq = 10
+
+arcnet.c:
+        io = 0
+        irqnum = 0
+        shmem = 0
+        num = 0
+        DO SET THESE MANUALLY AT INSMOD!
+        (When probing, looks at the following possible addresses:
+         Suggested ones:
+                0x300, 0x2E0, 0x2F0, 0x2D0
+         Other ones:
+                0x200, 0x210, 0x220, 0x230, 0x240, 0x250, 0x260, 0x270,
+                0x280, 0x290, 0x2A0, 0x2B0, 0x2C0,
+                       0x310, 0x320, 0x330, 0x340, 0x350, 0x360, 0x370,
+                0x380, 0x390, 0x3A0,                      0x3E0, 0x3F0  )
+
+ariadne.c:
+        Since this is a Zorro board, it supports full autoprobing, even for
+        multiple boards. (m68k/Amiga)
+
+at1700.c:
+        io = 0x260
+        irq = 0
+        (Probes ports: 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320, 0x380, 0x300)
+
+atari_bionet.c:
+        Supports full autoprobing. (m68k/Atari)
+
+atari_pamsnet.c:
+        Supports full autoprobing. (m68k/Atari)
+
+atarilance.c:
+        Supports full autoprobing. (m68k/Atari)
+
+atp.c: *Not modularized*
+        (Probes ports: 0x378, 0x278, 0x3BC;
+         fixed IRQs: 5 and 7                    )
+
+cops.c:
+        io = 0x240
+        irq = 5
+        nodeid = 0      (AutoSelect = 0, NodeID 1-254 is hand selected.)
+        (Probes ports: 0x240, 0x340, 0x200, 0x210, 0x220, 0x230, 0x260,
+                       0x2A0, 0x300, 0x310, 0x320, 0x330, 0x350, 0x360) 
+
+de4x5.c:
+        io = 0x000b
+        irq = 10
+        is_not_dec = 0  -- For non-DEC card using DEC 21040/21041/21140 chip, set this to 1
+        (EISA, and PCI probing)
+
+de600.c:
+        de600_debug = 0
+        (On port 0x378, irq 7 -- lpt1;  compile time configurable)
+
+de620.c:
+        bnc = 0, utp = 0  <-- Force media by setting either.
+        io = 0x378      (also compile-time configurable)
+        irq = 7
+
+depca.c:
+        io = 0x200
+        irq = 7
+        (Probes ports:  ISA:  0x300, 0x200;
+                        EISA: 0x0c00            )
+
+dummy.c:
+        No options
+
+e2100.c:
+        io = 0          (It will complain if you don't supply an "io=0xNNN")
+        irq = 0         (IRQ software selected by driver)
+        mem = 0         (Override default shared memory start of 0xd0000)
+        xcvr = 0        (Use xcvr=1 to select external transceiver.)
+        (Probes ports: 0x300, 0x280, 0x380, 0x220)
+
+eepro.c:
+        io = 0x200
+        irq = 0
+        (Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340, 0x360)
+
+eexpress.c:
+        io = 0x300
+        irq = 0         (IRQ value read from EEPROM)
+        (Probes ports: 0x300, 0x270, 0x320, 0x340)
+
+eql.c:
+        (No parameters)
+
+ewrk3.c:
+        io = 0x300
+        irq = 5
+        (With module no autoprobing!
+         On EISA-bus does EISA probing.
+         Static linkage probes ports on ISA bus:
+                0x100, 0x120, 0x140, 0x160, 0x180, 0x1A0, 0x1C0,
+                0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0,
+                0x300,        0x340, 0x360, 0x380, 0x3A0, 0x3C0)
+
+hp-plus.c:
+        io = 0          (It will complain if you don't supply an "io=0xNNN")
+        irq = 0         (IRQ read from configuration register)
+        (Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340)
+
+hp.c:
+        io = 0          (It will complain if you don't supply an "io=0xNNN")
+        irq = 0         (IRQ software selected by driver using autoIRQ)
+        (Probes ports: 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240)
+
+hp100.c:
+        hp100_port = 0 (IO-base address)
+        (Does EISA-probing, if on EISA-slot;
+         On ISA-bus probes all ports from 0x100 thru to 0x3E0
+         in increments of 0x020)
+
+hydra.c:
+        Since this is a Zorro board, it supports full autoprobing, even for
+        multiple boards. (m68k/Amiga)
+
+ibmtr.c:
+        io = 0xa20, 0xa24 (autoprobed by default)
+        irq = 0 (driver cannot select irq - read from hardware)
+        mem = 0 (shared memory base set at 0xd0000 and not yet 
+                 able to override thru mem= parameter.)
+
+lance.c: *Not modularized*
+        (PCI, and ISA probing; "CONFIG_PCI" needed for PCI support)
+        (Probes ISA ports: 0x300, 0x320, 0x340, 0x360)
+
+loopback.c: *Static kernel component*
+
+ne.c:
+        io = 0          (Explicitly *requires* an "io=0xNNN" value)
+        irq = 0         (Tries to determine configured IRQ via autoIRQ)
+        (Probes ports: 0x300, 0x280, 0x320, 0x340, 0x360)
+
+net_init.c: *Static kernel component*
+
+ni52.c: *Not modularized*
+        (Probes ports:  0x300, 0x280, 0x360, 0x320, 0x340
+                mems:   0xD0000, 0xD2000, 0xC8000, 0xCA000,
+                        0xD4000, 0xD6000, 0xD8000 )
+
+ni65.c: *Not modularized*  **16MB MEMORY BARRIER BUG**
+        (Probes ports:  0x300, 0x320, 0x340, 0x360)
+
+pi2.c:  *Not modularized* (well, NON-STANDARD modularization!)
+        Only one card supported at this time.
+        (Probes ports: 0x380, 0x300, 0x320, 0x340, 0x360, 0x3A0)
+
+plip.c:
+        io = 0
+        irq = 0         (by default, uses IRQ 5 for port at 0x3bc, IRQ 7
+                        for port at 0x378, and IRQ 2 for port at 0x278)
+        (Probes ports: 0x278, 0x378, 0x3bc)
+
+ppp.c:
+        No options (ppp-2.2+ has some, this is based on non-dynamic
+        version from ppp-2.1.2d)
+
+seeq8005.c: *Not modularized*
+        (Probes ports: 0x300, 0x320, 0x340, 0x360)
+
+sk_g16.c: *Not modularized*
+        (Probes ports: 0x100, 0x180, 0x208, 0x220m 0x288, 0x320, 0x328, 0x390)
+
+skeleton.c: *Skeleton*
+
+slhc.c:
+        No configuration parameters
+
+slip.c:
+        slip_maxdev = 256 (default value from SL_NRUNIT on slip.h)
+
+
+smc-ultra.c:
+        io = 0          (It will complain if you don't supply an "io=0xNNN")
+        irq = 0         (IRQ val. read from EEPROM)
+        (Probes ports:  0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380)
+
+tulip.c: *Partial modularization*
+        (init-time memory allocation makes problems..)
+
+tunnel.c:
+        No insmod parameters
+
+wavelan.c:
+        io = 0x390      (Settable, but change not recommended)
+        irq = 0         (Not honoured, if changed..)
+
+wd.c:
+        io = 0          (It will complain if you don't supply an "io=0xNNN")
+        irq = 0         (IRQ val. read from EEPROM, ancient cards use autoIRQ)
+        mem = 0         (Force shared-memory on address 0xC8000, or whatever..)
+        mem_end = 0     (Force non-std. mem. size via supplying mem_end val.)
+                        (eg. for 32k WD8003EBT, use mem=0xd0000 mem_end=0xd8000)
+        (Probes ports:  0x300, 0x280, 0x380, 0x240)
+
+znet.c: *Not modularized*
+        (Only one device on  Zenith Z-Note (notebook?) systems,
+         configuration information from (EE)PROM)
diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
new file mode 100644
index 00000000000..53618fb1a71
--- /dev/null
+++ b/Documentation/networking/netconsole.txt
@@ -0,0 +1,57 @@
+
+started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
+2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
+
+Please send bug reports to Matt Mackall <mpm@selenic.com>
+
+This module logs kernel printk messages over UDP allowing debugging of
+problem where disk logging fails and serial consoles are impractical.
+
+It can be used either built-in or as a module. As a built-in,
+netconsole initializes immediately after NIC cards and will bring up
+the specified interface as soon as possible. While this doesn't allow
+capture of early kernel panics, it does capture most of the boot
+process.
+
+It takes a string configuration parameter "netconsole" in the
+following format:
+
+ netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
+
+   where
+        src-port      source for UDP packets (defaults to 6665)
+        src-ip        source IP to use (interface address)
+        dev           network interface (eth0)
+        tgt-port      port for logging agent (6666)
+        tgt-ip        IP address for logging agent
+        tgt-macaddr   ethernet MAC address for logging agent (broadcast)
+
+Examples:
+
+ linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
+
+  or
+
+ insmod netconsole netconsole=@/,@10.0.0.2/
+
+Built-in netconsole starts immediately after the TCP stack is
+initialized and attempts to bring up the supplied dev at the supplied
+address.
+
+The remote host can run either 'netcat -u -l -p <port>' or syslogd.
+
+WARNING: the default target ethernet setting uses the broadcast
+ethernet address to send packets, which can cause increased load on
+other systems on the same ethernet segment.
+
+NOTE: the network device (eth1 in the above case) can run any kind
+of other network traffic, netconsole is not intrusive. Netconsole
+might cause slight delays in other traffic if the volume of kernel
+messages is high, but should have no other impact.
+
+Netconsole was designed to be as instantaneous as possible, to
+enable the logging of even the most critical kernel bugs. It works
+from IRQ contexts as well, and does not enable interrupts while
+sending packets. Due to these unique needs, configuration can not
+be more automatic, and some fundamental limitations will remain:
+only IP networks, UDP packets and ethernet devices are supported.
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
new file mode 100644
index 00000000000..1509f3aff96
--- /dev/null
+++ b/Documentation/networking/netdevices.txt
@@ -0,0 +1,75 @@
+
+Network Devices, the Kernel, and You!
+
+
+Introduction
+============
+The following is a random collection of documentation regarding
+network devices.
+
+struct net_device allocation rules
+==================================
+Network device structures need to persist even after module is unloaded and
+must be allocated with kmalloc.  If device has registered successfully,
+it will be freed on last use by free_netdev.  This is required to handle the
+pathologic case cleanly (example: rmmod mydriver </sys/class/net/myeth/mtu )
+
+There are routines in net_init.c to handle the common cases of
+alloc_etherdev, alloc_netdev.  These reserve extra space for driver
+private data which gets freed when the network device is freed. If
+separately allocated data is attached to the network device
+(dev->priv) then it is up to the module exit handler to free that.
+
+
+struct net_device synchronization rules
+=======================================
+dev->open:
+        Synchronization: rtnl_lock() semaphore.
+        Context: process
+
+dev->stop:
+        Synchronization: rtnl_lock() semaphore.
+        Context: process
+        Note1: netif_running() is guaranteed false
+        Note2: dev->poll() is guaranteed to be stopped
+
+dev->do_ioctl:
+        Synchronization: rtnl_lock() semaphore.
+        Context: process
+
+dev->get_stats:
+        Synchronization: dev_base_lock rwlock.
+        Context: nominally process, but don't sleep inside an rwlock
+
+dev->hard_start_xmit:
+        Synchronization: dev->xmit_lock spinlock.
+        When the driver sets NETIF_F_LLTX in dev->features this will be
+        called without holding xmit_lock. In this case the driver 
+        has to lock by itself when needed. It is recommended to use a try lock
+        for this and return -1 when the spin lock fails. 
+        The locking there should also properly protect against 
+        set_multicast_list
+        Context: BHs disabled
+        Notes: netif_queue_stopped() is guaranteed false
+        Return codes: 
+        o NETDEV_TX_OK everything ok. 
+        o NETDEV_TX_BUSY Cannot transmit packet, try later 
+          Usually a bug, means queue start/stop flow control is broken in
+          the driver. Note: the driver must NOT put the skb in its DMA ring.
+        o NETDEV_TX_LOCKED Locking failed, please retry quickly.
+          Only valid when NETIF_F_LLTX is set.
+
+dev->tx_timeout:
+        Synchronization: dev->xmit_lock spinlock.
+        Context: BHs disabled
+        Notes: netif_queue_stopped() is guaranteed true
+
+dev->set_multicast_list:
+        Synchronization: dev->xmit_lock spinlock.
+        Context: BHs disabled
+
+dev->poll:
+        Synchronization: __LINK_STATE_RX_SCHED bit in dev->state.  See
+                dev_close code and comments in net/core/dev.c for more info.
+        Context: softirq
+
diff --git a/Documentation/networking/netif-msg.txt b/Documentation/networking/netif-msg.txt
new file mode 100644
index 00000000000..18ad4cea625
--- /dev/null
+++ b/Documentation/networking/netif-msg.txt
@@ -0,0 +1,79 @@
+
+________________
+NETIF Msg Level
+
+The design of the network interface message level setting.
+
+History
+
+ The design of the debugging message interface was guided and
+ constrained by backwards compatibility previous practice.  It is useful
+ to understand the history and evolution in order to understand current
+ practice and relate it to older driver source code.
+
+ From the beginning of Linux, each network device driver has had a local
+ integer variable that controls the debug message level.  The message
+ level ranged from 0 to 7, and monotonically increased in verbosity.
+
+ The message level was not precisely defined past level 3, but were
+ always implemented within +-1 of the specified level.  Drivers tended
+ to shed the more verbose level messages as they matured.
+    0  Minimal messages, only essential information on fatal errors.
+    1  Standard messages, initialization status.  No run-time messages
+    2  Special media selection messages, generally timer-driver.
+    3  Interface starts and stops, including normal status messages
+    4  Tx and Rx frame error messages, and abnormal driver operation
+    5  Tx packet queue information, interrupt events.
+    6  Status on each completed Tx packet and received Rx packets
+    7  Initial contents of Tx and Rx packets
+
+ Initially this message level variable was uniquely named in each driver
+ e.g. "lance_debug", so that a kernel symbolic debugger could locate and
+ modify the setting.  When kernel modules became common, the variables
+ were consistently renamed to "debug" and allowed to be set as a module
+ parameter.
+
+ This approach worked well.  However there is always a demand for
+ additional features.  Over the years the following emerged as
+ reasonable and easily implemented enhancements
+   Using an ioctl() call to modify the level.
+   Per-interface rather than per-driver message level setting.
+   More selective control over the type of messages emitted.
+
+ The netif_msg recommandation adds these features with only a minor
+ complexity and code size increase.
+
+ The recommendation is the following points
+    Retaining the per-driver integer variable "debug" as a module
+    parameter with a default level of '1'.
+
+    Adding a per-interface private variable named "msg_enable".  The
+    variable is a bit map rather than a level, and is initialized as
+       1 << debug
+    Or more precisely
+        debug < 0 ? 0 : 1 << min(sizeof(int)-1, debug)
+
+    Messages should changes from
+      if (debug > 1)
+           printk(MSG_DEBUG "%s: ...
+    to
+      if (np->msg_enable & NETIF_MSG_LINK)
+           printk(MSG_DEBUG "%s: ...
+
+
+The set of message levels is named
+  Old level   Name   Bit position
+    0    NETIF_MSG_DRV          0x0001
+    1    NETIF_MSG_PROBE        0x0002
+    2    NETIF_MSG_LINK         0x0004
+    2    NETIF_MSG_TIMER        0x0004
+    3    NETIF_MSG_IFDOWN       0x0008
+    3    NETIF_MSG_IFUP         0x0008
+    4    NETIF_MSG_RX_ERR       0x0010
+    4    NETIF_MSG_TX_ERR       0x0010
+    5    NETIF_MSG_TX_QUEUED    0x0020
+    5    NETIF_MSG_INTR         0x0020
+    6    NETIF_MSG_TX_DONE      0x0040
+    6    NETIF_MSG_RX_STATUS    0x0040
+    7    NETIF_MSG_PKTDATA      0x0080
+
diff --git a/Documentation/networking/olympic.txt b/Documentation/networking/olympic.txt
new file mode 100644
index 00000000000..c65a94010ea
--- /dev/null
+++ b/Documentation/networking/olympic.txt
@@ -0,0 +1,79 @@
+
+IBM PCI Pit/Pit-Phy/Olympic CHIPSET BASED TOKEN RING CARDS README
+
+Release 0.2.0 - Release    
+        June 8th 1999 Peter De Schrijver & Mike Phillips
+Release 0.9.C - Release
+        April 18th 2001 Mike Phillips
+
+Thanks:
+Erik De Cock, Adrian Bridgett and Frank Fiene for their 
+patience and testing.
+Donald Champion for the cardbus support
+Kyle Lucke for the dma api changes.   
+Jonathon Bitner for hardware support. 
+Everybody on linux-tr for their continued support.  
+ 
+Options:
+
+The driver accepts four options: ringspeed, pkt_buf_sz,  
+message_level and network_monitor.
+
+These options can be specified differently for each card found. 
+
+ringspeed:  Has one of three settings 0 (default), 4 or 16.  0 will 
+make the card autosense the ringspeed and join at the appropriate speed, 
+this will be the default option for most people.  4 or 16 allow you to 
+explicitly force the card to operate at a certain speed.  The card will fail 
+if you try to insert it at the wrong speed. (Although some hubs will allow 
+this so be *very* careful).  The main purpose for explicitly setting the ring
+speed is for when the card is first on the ring.  In autosense mode, if the card
+cannot detect any active monitors on the ring it will not open, so you must 
+re-init the card at the appropriate speed.  Unfortunately at present the only
+way of doing this is rmmod and insmod which is a bit tough if it is compiled
+in the kernel.
+
+pkt_buf_sz:  This is this initial receive buffer allocation size.  This will
+default to 4096 if no value is entered. You may increase performance of the 
+driver by setting this to a value larger than the network packet size, although
+the driver now re-sizes buffers based on MTU settings as well. 
+
+message_level: Controls level of messages created by the driver. Defaults to 0:
+which only displays start-up and critical messages.  Presently any non-zero 
+value will display all soft messages as well.  NB This does not turn 
+debugging messages on, that must be done by modified the source code.
+
+network_monitor: Any non-zero value will provide a quasi network monitoring 
+mode.  All unexpected MAC frames (beaconing etc.) will be received
+by the driver and the source and destination addresses printed. 
+Also an entry will be added in  /proc/net called olympic_tr%d, where tr%d
+is the registered device name, i.e tr0, tr1, etc. This displays low
+level information about the configuration of the ring and the adapter.
+This feature has been designed for network administrators to assist in 
+the diagnosis of network / ring problems. (This used to OLYMPIC_NETWORK_MONITOR,
+but has now changed to allow each adapter to be configured differently and
+to alleviate the necessity to re-compile olympic to turn the option on).
+
+Multi-card:
+
+The driver will detect multiple cards and will work with shared interrupts,
+each card is assigned the next token ring device, i.e. tr0 , tr1, tr2.  The 
+driver should also happily reside in the system with other drivers.  It has 
+been tested with ibmtr.c running, and I personally have had one Olicom PCI 
+card and two IBM olympic cards (all on the same interrupt), all running
+together. 
+
+Variable MTU size:
+
+The driver can handle a MTU size upto either 4500 or 18000 depending upon 
+ring speed.  The driver also changes the size of the receive buffers as part
+of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
+to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 
+position = 296,000 bytes of memory space, plus of course anything 
+necessary for the tx sk_buff's.  Remember this is per card, so if you are
+building routers, gateway's etc, you could start to use a lot of memory
+real fast.
+
+
+6/8/99 Peter De Schrijver and Mike Phillips
+
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
new file mode 100644
index 00000000000..8d4cf78258e
--- /dev/null
+++ b/Documentation/networking/packet_mmap.txt
@@ -0,0 +1,399 @@
+--------------------------------------------------------------------------------
++ ABSTRACT
+--------------------------------------------------------------------------------
+
+This file documents the CONFIG_PACKET_MMAP option available with the PACKET
+socket interface on 2.4 and 2.6 kernels. This type of sockets is used for 
+capture network traffic with utilities like tcpdump or any other that uses 
+the libpcap library. 
+
+You can find the latest version of this document at
+
+    http://pusa.uv.es/~ulisses/packet_mmap/
+
+Please send me your comments to
+
+    Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
+
+-------------------------------------------------------------------------------
++ Why use PACKET_MMAP
+--------------------------------------------------------------------------------
+
+In Linux 2.4/2.6 if PACKET_MMAP is not enabled, the capture process is very
+inefficient. It uses very limited buffers and requires one system call
+to capture each packet, it requires two if you want to get packet's 
+timestamp (like libpcap always does).
+
+In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size 
+configurable circular buffer mapped in user space. This way reading packets just 
+needs to wait for them, most of the time there is no need to issue a single 
+system call. By using a shared buffer between the kernel and the user 
+also has the benefit of minimizing packet copies.
+
+It's fine to use PACKET_MMAP to improve the performance of the capture process, 
+but it isn't everything. At least, if you are capturing at high speeds (this 
+is relative to the cpu speed), you should check if the device driver of your 
+network interface card supports some sort of interrupt load mitigation or 
+(even better) if it supports NAPI, also make sure it is enabled.
+
+--------------------------------------------------------------------------------
++ How to use CONFIG_PACKET_MMAP
+--------------------------------------------------------------------------------
+
+From the user standpoint, you should use the higher level libpcap library, wich
+is a de facto standard, portable across nearly all operating systems
+including Win32. 
+
+Said that, at time of this writing, official libpcap 0.8.1 is out and doesn't include
+support for PACKET_MMAP, and also probably the libpcap included in your distribution. 
+
+I'm aware of two implementations of PACKET_MMAP in libpcap:
+
+    http://pusa.uv.es/~ulisses/packet_mmap/  (by Simon Patarin, based on libpcap 0.6.2)
+    http://public.lanl.gov/cpw/              (by Phil Wood, based on lastest libpcap)
+
+The rest of this document is intended for people who want to understand
+the low level details or want to improve libpcap by including PACKET_MMAP
+support.
+
+--------------------------------------------------------------------------------
++ How to use CONFIG_PACKET_MMAP directly
+--------------------------------------------------------------------------------
+
+From the system calls stand point, the use of PACKET_MMAP involves
+the following process:
+
+
+[setup]     socket() -------> creation of the capture socket
+            setsockopt() ---> allocation of the circular buffer (ring)
+            mmap() ---------> maping of the allocated buffer to the
+                              user process
+
+[capture]   poll() ---------> to wait for incoming packets
+
+[shutdown]  close() --------> destruction of the capture socket and
+                              deallocation of all associated 
+                              resources.
+
+
+socket creation and destruction is straight forward, and is done 
+the same way with or without PACKET_MMAP:
+
+int fd;
+
+fd= socket(PF_PACKET, mode, htons(ETH_P_ALL))
+
+where mode is SOCK_RAW for the raw interface were link level
+information can be captured or SOCK_DGRAM for the cooked
+interface where link level information capture is not 
+supported and a link level pseudo-header is provided 
+by the kernel.
+
+The destruction of the socket and all associated resources
+is done by a simple call to close(fd).
+
+Next I will describe PACKET_MMAP settings and it's constraints,
+also the maping of the circular buffer in the user process and 
+the use of this buffer.
+
+--------------------------------------------------------------------------------
++ PACKET_MMAP settings
+--------------------------------------------------------------------------------
+
+
+To setup PACKET_MMAP from user level code is done with a call like
+
+     setsockopt(fd, SOL_PACKET, PACKET_RX_RING, (void *) &req, sizeof(req))
+
+The most significant argument in the previous call is the req parameter, 
+this parameter must to have the following structure:
+
+    struct tpacket_req
+    {
+        unsigned int    tp_block_size;  /* Minimal size of contiguous block */
+        unsigned int    tp_block_nr;    /* Number of blocks */
+        unsigned int    tp_frame_size;  /* Size of frame */
+        unsigned int    tp_frame_nr;    /* Total number of frames */
+    };
+
+This structure is defined in /usr/include/linux/if_packet.h and establishes a 
+circular buffer (ring) of unswappable memory mapped in the capture process. 
+Being mapped in the capture process allows reading the captured frames and 
+related meta-information like timestamps without requiring a system call.
+
+Captured frames are grouped in blocks. Each block is a physically contiguous 
+region of memory and holds tp_block_size/tp_frame_size frames. The total number 
+of blocks is tp_block_nr. Note that tp_frame_nr is a redundant parameter because
+
+    frames_per_block = tp_block_size/tp_frame_size
+
+indeed, packet_set_ring checks that the following condition is true
+
+    frames_per_block * tp_block_nr == tp_frame_nr
+
+
+Lets see an example, with the following values:
+
+     tp_block_size= 4096
+     tp_frame_size= 2048
+     tp_block_nr  = 4
+     tp_frame_nr  = 8
+
+we will get the following buffer structure:
+
+        block #1                 block #2         
++---------+---------+    +---------+---------+    
+| frame 1 | frame 2 |    | frame 3 | frame 4 |    
++---------+---------+    +---------+---------+    
+
+        block #3                 block #4
++---------+---------+    +---------+---------+
+| frame 5 | frame 6 |    | frame 7 | frame 8 |
++---------+---------+    +---------+---------+
+
+A frame can be of any size with the only condition it can fit in a block. A block
+can only hold an integer number of frames, or in other words, a frame cannot 
+be spawn accross two blocks so there are some datails you have to take into 
+account when choosing the frame_size. See "Maping and use of the circular 
+buffer (ring)".
+
+
+--------------------------------------------------------------------------------
++ PACKET_MMAP setting constraints
+--------------------------------------------------------------------------------
+
+In kernel versions prior to 2.4.26 (for the 2.4 branch) and 2.6.5 (2.6 branch),
+the PACKET_MMAP buffer could hold only 32768 frames in a 32 bit architecture or
+16384 in a 64 bit architecture. For information on these kernel versions
+see http://pusa.uv.es/~ulisses/packet_mmap/packet_mmap.pre-2.4.26_2.6.5.txt
+
+ Block size limit
+------------------
+
+As stated earlier, each block is a contiguous physical region of memory. These 
+memory regions are allocated with calls to the __get_free_pages() function. As 
+the name indicates, this function allocates pages of memory, and the second
+argument is "order" or a power of two number of pages, that is 
+(for PAGE_SIZE == 4096) order=0 ==> 4096 bytes, order=1 ==> 8192 bytes, 
+order=2 ==> 16384 bytes, etc. The maximum size of a 
+region allocated by __get_free_pages is determined by the MAX_ORDER macro. More 
+precisely the limit can be calculated as:
+
+   PAGE_SIZE << MAX_ORDER
+
+   In a i386 architecture PAGE_SIZE is 4096 bytes 
+   In a 2.4/i386 kernel MAX_ORDER is 10
+   In a 2.6/i386 kernel MAX_ORDER is 11
+
+So get_free_pages can allocate as much as 4MB or 8MB in a 2.4/2.6 kernel 
+respectively, with an i386 architecture.
+
+User space programs can include /usr/include/sys/user.h and 
+/usr/include/linux/mmzone.h to get PAGE_SIZE MAX_ORDER declarations.
+
+The pagesize can also be determined dynamically with the getpagesize (2) 
+system call. 
+
+
+ Block number limit
+--------------------
+
+To understand the constraints of PACKET_MMAP, we have to see the structure 
+used to hold the pointers to each block.
+
+Currently, this structure is a dynamically allocated vector with kmalloc 
+called pg_vec, its size limits the number of blocks that can be allocated.
+
+    +---+---+---+---+
+    | x | x | x | x |
+    +---+---+---+---+
+      |   |   |   |
+      |   |   |   v
+      |   |   v  block #4
+      |   v  block #3
+      v  block #2
+     block #1
+
+
+kmalloc allocates any number of bytes of phisically contiguous memory from 
+a pool of pre-determined sizes. This pool of memory is mantained by the slab 
+allocator wich is at the end the responsible for doing the allocation and 
+hence wich imposes the maximum memory that kmalloc can allocate. 
+
+In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The 
+predetermined sizes that kmalloc uses can be checked in the "size-<bytes>" 
+entries of /proc/slabinfo
+
+In a 32 bit architecture, pointers are 4 bytes long, so the total number of 
+pointers to blocks is
+
+     131072/4 = 32768 blocks
+
+
+ PACKET_MMAP buffer size calculator
+------------------------------------
+
+Definitions:
+
+<size-max>    : is the maximum size of allocable with kmalloc (see /proc/slabinfo)
+<pointer size>: depends on the architecture -- sizeof(void *)
+<page size>   : depends on the architecture -- PAGE_SIZE or getpagesize (2)
+<max-order>   : is the value defined with MAX_ORDER
+<frame size>  : it's an upper bound of frame's capture size (more on this later)
+
+from these definitions we will derive 
+
+        <block number> = <size-max>/<pointer size>
+        <block size> = <pagesize> << <max-order>
+
+so, the max buffer size is
+
+        <block number> * <block size>
+
+and, the number of frames be
+
+        <block number> * <block size> / <frame size>
+
+Suposse the following parameters, wich apply for 2.6 kernel and an
+i386 architecture:
+
+        <size-max> = 131072 bytes
+        <pointer size> = 4 bytes
+        <pagesize> = 4096 bytes
+        <max-order> = 11
+
+and a value for <frame size> of 2048 byteas. These parameters will yield
+
+        <block number> = 131072/4 = 32768 blocks
+        <block size> = 4096 << 11 = 8 MiB.
+
+and hence the buffer will have a 262144 MiB size. So it can hold 
+262144 MiB / 2048 bytes = 134217728 frames
+
+
+Actually, this buffer size is not possible with an i386 architecture. 
+Remember that the memory is allocated in kernel space, in the case of 
+an i386 kernel's memory size is limited to 1GiB.
+
+All memory allocations are not freed until the socket is closed. The memory 
+allocations are done with GFP_KERNEL priority, this basically means that 
+the allocation can wait and swap other process' memory in order to allocate 
+the nececessary memory, so normally limits can be reached.
+
+ Other constraints
+-------------------
+
+If you check the source code you will see that what I draw here as a frame
+is not only the link level frame. At the begining of each frame there is a 
+header called struct tpacket_hdr used in PACKET_MMAP to hold link level's frame
+meta information like timestamp. So what we draw here a frame it's really 
+the following (from include/linux/if_packet.h):
+
+/*
+   Frame structure:
+
+   - Start. Frame must be aligned to TPACKET_ALIGNMENT=16
+   - struct tpacket_hdr
+   - pad to TPACKET_ALIGNMENT=16
+   - struct sockaddr_ll
+   - Gap, chosen so that packet data (Start+tp_net) alignes to 
+     TPACKET_ALIGNMENT=16
+   - Start+tp_mac: [ Optional MAC header ]
+   - Start+tp_net: Packet data, aligned to TPACKET_ALIGNMENT=16.
+   - Pad to align to TPACKET_ALIGNMENT=16
+ */
+           
+ 
+ The following are conditions that are checked in packet_set_ring
+
+   tp_block_size must be a multiple of PAGE_SIZE (1)
+   tp_frame_size must be greater than TPACKET_HDRLEN (obvious)
+   tp_frame_size must be a multiple of TPACKET_ALIGNMENT
+   tp_frame_nr   must be exactly frames_per_block*tp_block_nr
+
+Note that tp_block_size should be choosed to be a power of two or there will
+be a waste of memory.
+
+--------------------------------------------------------------------------------
++ Maping and use of the circular buffer (ring)
+--------------------------------------------------------------------------------
+
+The maping of the buffer in the user process is done with the conventional 
+mmap function. Even the circular buffer is compound of several physically
+discontiguous blocks of memory, they are contiguous to the user space, hence
+just one call to mmap is needed:
+
+    mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+
+If tp_frame_size is a divisor of tp_block_size frames will be 
+contiguosly spaced by tp_frame_size bytes. If not, each 
+tp_block_size/tp_frame_size frames there will be a gap between 
+the frames. This is because a frame cannot be spawn across two
+blocks. 
+
+At the beginning of each frame there is an status field (see 
+struct tpacket_hdr). If this field is 0 means that the frame is ready
+to be used for the kernel, If not, there is a frame the user can read 
+and the following flags apply:
+
+     from include/linux/if_packet.h
+
+     #define TP_STATUS_COPY          2 
+     #define TP_STATUS_LOSING        4 
+     #define TP_STATUS_CSUMNOTREADY  8 
+
+
+TP_STATUS_COPY        : This flag indicates that the frame (and associated
+                        meta information) has been truncated because it's 
+                        larger than tp_frame_size. This packet can be 
+                        read entirely with recvfrom().
+                        
+                        In order to make this work it must to be
+                        enabled previously with setsockopt() and 
+                        the PACKET_COPY_THRESH option. 
+
+                        The number of frames than can be buffered to 
+                        be read with recvfrom is limited like a normal socket.
+                        See the SO_RCVBUF option in the socket (7) man page.
+
+TP_STATUS_LOSING      : indicates there were packet drops from last time 
+                        statistics where checked with getsockopt() and
+                        the PACKET_STATISTICS option.
+
+TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets wich 
+                        it's checksum will be done in hardware. So while 
+                        reading the packet we should not try to check the 
+                        checksum. 
+
+for convenience there are also the following defines:
+
+     #define TP_STATUS_KERNEL        0
+     #define TP_STATUS_USER          1
+
+The kernel initializes all frames to TP_STATUS_KERNEL, when the kernel
+receives a packet it puts in the buffer and updates the status with
+at least the TP_STATUS_USER flag. Then the user can read the packet,
+once the packet is read the user must zero the status field, so the kernel 
+can use again that frame buffer.
+
+The user can use poll (any other variant should apply too) to check if new
+packets are in the ring:
+
+    struct pollfd pfd;
+
+    pfd.fd = fd;
+    pfd.revents = 0;
+    pfd.events = POLLIN|POLLRDNORM|POLLERR;
+
+    if (status == TP_STATUS_KERNEL)
+        retval = poll(&pfd, 1, timeout);
+
+It doesn't incur in a race condition to first check the status value and 
+then poll for frames.
+
+--------------------------------------------------------------------------------
++ THANKS
+--------------------------------------------------------------------------------
+   
+   Jesse Brandeburg, for fixing my grammathical/spelling errors
+
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt
new file mode 100644
index 00000000000..cc4b4d04129
--- /dev/null
+++ b/Documentation/networking/pktgen.txt
@@ -0,0 +1,214 @@
+
+
+                  HOWTO for the linux packet generator 
+                  ------------------------------------
+
+Date: 041221
+
+Enable CONFIG_NET_PKTGEN to compile and build pktgen.o either in kernel
+or as module. Module is preferred. insmod pktgen if needed. Once running
+pktgen creates a thread on each CPU where each thread has affinty it's CPU.
+Monitoring and controlling is done via /proc. Easiest to select a suitable 
+a sample script and configure.
+
+On a dual CPU:
+
+ps aux | grep pkt
+root       129  0.3  0.0     0    0 ?        SW    2003 523:20 [pktgen/0]
+root       130  0.3  0.0     0    0 ?        SW    2003 509:50 [pktgen/1]
+
+
+For montoring and control pktgen creates:
+        /proc/net/pktgen/pgctrl
+        /proc/net/pktgen/kpktgend_X
+        /proc/net/pktgen/ethX
+
+
+Viewing threads
+===============
+/proc/net/pktgen/kpktgend_0 
+Name: kpktgend_0  max_before_softirq: 10000
+Running: 
+Stopped: eth1 
+Result: OK: max_before_softirq=10000
+
+Most important the devices assigend to thread. Note! A device can only belong 
+to one thread.
+
+
+Viewing devices
+===============
+
+Parm section holds configured info. Current hold running stats. 
+Result is printed after run or after interruption. Example:
+
+/proc/net/pktgen/eth1       
+
+Params: count 10000000  min_pkt_size: 60  max_pkt_size: 60
+     frags: 0  delay: 0  clone_skb: 1000000  ifname: eth1
+     flows: 0 flowlen: 0
+     dst_min: 10.10.11.2  dst_max: 
+     src_min:   src_max: 
+     src_mac: 00:00:00:00:00:00  dst_mac: 00:04:23:AC:FD:82
+     udp_src_min: 9  udp_src_max: 9  udp_dst_min: 9  udp_dst_max: 9
+     src_mac_count: 0  dst_mac_count: 0 
+     Flags: 
+Current:
+     pkts-sofar: 10000000  errors: 39664
+     started: 1103053986245187us  stopped: 1103053999346329us idle: 880401us
+     seq_num: 10000011  cur_dst_mac_offset: 0  cur_src_mac_offset: 0
+     cur_saddr: 0x10a0a0a  cur_daddr: 0x20b0a0a
+     cur_udp_dst: 9  cur_udp_src: 9
+     flows: 0
+Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
+  763292pps 390Mb/sec (390805504bps) errors: 39664
+
+Confguring threads and devices
+==============================
+This is done via the /proc interface easiest done via pgset in the scripts
+
+Examples:
+
+ pgset "clone_skb 1"     sets the number of copies of the same packet
+ pgset "clone_skb 0"     use single SKB for all transmits
+ pgset "pkt_size 9014"   sets packet size to 9014
+ pgset "frags 5"         packet will consist of 5 fragments
+ pgset "count 200000"    sets number of packets to send, set to zero
+                         for continious sends untill explicitl stopped.
+
+ pgset "delay 5000"      adds delay to hard_start_xmit(). nanoseconds
+
+ pgset "dst 10.0.0.1"    sets IP destination address
+                         (BEWARE! This generator is very aggressive!)
+
+ pgset "dst_min 10.0.0.1"            Same as dst
+ pgset "dst_max 10.0.0.254"          Set the maximum destination IP.
+ pgset "src_min 10.0.0.1"            Set the minimum (or only) source IP.
+ pgset "src_max 10.0.0.254"          Set the maximum source IP.
+ pgset "dst6 fec0::1"     IPV6 destination address
+ pgset "src6 fec0::2"     IPV6 source address
+ pgset "dstmac 00:00:00:00:00:00"    sets MAC destination address
+ pgset "srcmac 00:00:00:00:00:00"    sets MAC source address
+
+ pgset "src_mac_count 1" Sets the number of MACs we'll range through.  
+                         The 'minimum' MAC is what you set with srcmac.
+
+ pgset "dst_mac_count 1" Sets the number of MACs we'll range through.
+                         The 'minimum' MAC is what you set with dstmac.
+
+ pgset "flag [name]"     Set a flag to determine behaviour.  Current flags
+                         are: IPSRC_RND #IP Source is random (between min/max),
+                              IPDST_RND, UDPSRC_RND,
+                              UDPDST_RND, MACSRC_RND, MACDST_RND 
+
+ pgset "udp_src_min 9"   set UDP source port min, If < udp_src_max, then
+                         cycle through the port range.
+
+ pgset "udp_src_max 9"   set UDP source port max.
+ pgset "udp_dst_min 9"   set UDP destination port min, If < udp_dst_max, then
+                         cycle through the port range.
+ pgset "udp_dst_max 9"   set UDP destination port max.
+
+ pgset stop               aborts injection. Also, ^C aborts generator.
+
+
+Example scripts
+===============
+
+A collection of small tutorial scripts for pktgen is in expamples dir.
+
+pktgen.conf-1-1                  # 1 CPU 1 dev 
+pktgen.conf-1-2                  # 1 CPU 2 dev
+pktgen.conf-2-1                  # 2 CPU's 1 dev 
+pktgen.conf-2-2                  # 2 CPU's 2 dev
+pktgen.conf-1-1-rdos             # 1 CPU 1 dev w. route DoS 
+pktgen.conf-1-1-ip6              # 1 CPU 1 dev ipv6
+pktgen.conf-1-1-ip6-rdos         # 1 CPU 1 dev ipv6  w. route DoS
+pktgen.conf-1-1-flows            # 1 CPU 1 dev multiple flows.
+
+Run in shell: ./pktgen.conf-X-Y It does all the setup including sending. 
+
+
+Interrupt affinity
+===================
+Note when adding devices to a specific CPU there good idea to also assign 
+/proc/irq/XX/smp_affinity so the TX-interrupts gets bound to the same CPU.
+as this reduces cache bouncing when freeing skb's.
+
+
+Current commands and configuration options
+==========================================
+
+** Pgcontrol commands:
+
+start
+stop
+
+** Thread commands:
+
+add_device
+rem_device_all
+max_before_softirq
+
+
+** Device commands:
+
+count
+clone_skb
+debug
+
+frags
+delay
+
+src_mac_count
+dst_mac_count
+
+pkt_size 
+min_pkt_size
+max_pkt_size
+
+udp_src_min
+udp_src_max
+
+udp_dst_min
+udp_dst_max
+
+flag
+  IPSRC_RND
+  TXSIZE_RND
+  IPDST_RND
+  UDPSRC_RND
+  UDPDST_RND
+  MACSRC_RND
+  MACDST_RND
+
+dst_min
+dst_max
+
+src_min
+src_max
+
+dst_mac
+src_mac
+
+clear_counters
+
+dst6
+src6
+
+flows
+flowlen
+
+References:
+ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/
+ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/
+
+Paper from Linux-Kongress in Erlangen 2004.
+ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/pktgen_paper.pdf
+
+Thanks to:
+Grant Grundler for testing on IA-64 and parisc, Harald Welte,  Lennert Buytenhek
+Stephen Hemminger, Andi Kleen, Dave Miller and many others.
+
+
+Good luck with the linux net-development.
\ No newline at end of file
diff --git a/Documentation/networking/policy-routing.txt b/Documentation/networking/policy-routing.txt
new file mode 100644
index 00000000000..36f6936d7f2
--- /dev/null
+++ b/Documentation/networking/policy-routing.txt
@@ -0,0 +1,150 @@
+Classes
+-------
+
+        "Class" is a complete routing table in common sense.
+        I.e. it is tree of nodes (destination prefix, tos, metric)
+        with attached information: gateway, device etc.
+        This tree is looked up as specified in RFC1812 5.2.4.3
+        1. Basic match
+        2. Longest match
+        3. Weak TOS.
+        4. Metric. (should not be in kernel space, but they are)
+        5. Additional pruning rules. (not in kernel space).
+        
+        We have two special type of nodes:
+        REJECT - abort route lookup and return an error value.
+        THROW  - abort route lookup in this class.
+
+
+        Currently the number of classes is limited to 255
+        (0 is reserved for "not specified class")
+
+        Three classes are builtin:
+
+        RT_CLASS_LOCAL=255 - local interface addresses,
+        broadcasts, nat addresses.
+
+        RT_CLASS_MAIN=254  - all normal routes are put there
+        by default.
+
+        RT_CLASS_DEFAULT=253 - if ip_fib_model==1, then
+        normal default routes are put there, if ip_fib_model==2
+        all gateway routes are put there.
+
+
+Rules
+-----
+        Rule is a record of (src prefix, src interface, tos, dst prefix)
+        with attached information.
+
+        Rule types:
+        RTP_ROUTE - lookup in attached class
+        RTP_NAT   - lookup in attached class and if a match is found,
+                    translate packet source address.
+        RTP_MASQUERADE - lookup in attached class and if a match is found,
+                    masquerade packet as sourced by us.
+        RTP_DROP   - silently drop the packet.
+        RTP_REJECT - drop the packet and send ICMP NET UNREACHABLE.
+        RTP_PROHIBIT - drop the packet and send ICMP COMM. ADM. PROHIBITED.
+
+        Rule flags:
+        RTRF_LOG - log route creations.
+        RTRF_VALVE - One way route (used with masquerading)
+
+Default setup:
+
+root@amber:/pub/ip-routing # iproute -r
+Kernel routing policy rules
+Pref Source             Destination        TOS Iface   Cl
+   0 default            default            00  *       255
+ 254 default            default            00  *       254
+ 255 default            default            00  *       253
+
+
+Lookup algorithm
+----------------
+
+        We scan rules list, and if a rule is matched, apply it.
+        If a route is found, return it.
+        If it is not found or a THROW node was matched, continue
+        to scan rules.
+
+Applications
+------------
+
+1.      Just ignore classes. All the routes are put into MAIN class
+        (and/or into DEFAULT class).
+
+        HOWTO:  iproute add PREFIX [ tos TOS ] [ gw GW ] [ dev DEV ]
+                [ metric METRIC ] [ reject ] ... (look at iproute utility)
+
+                or use route utility from current net-tools.
+                
+2.      Opposite case. Just forget all that you know about routing
+        tables. Every rule is supplied with its own gateway, device
+        info. record. This approach is not appropriate for automated
+        route maintenance, but it is ideal for manual configuration.
+
+        HOWTO:  iproute addrule [ from PREFIX ] [ to PREFIX ] [ tos TOS ]
+                [ dev INPUTDEV] [ pref PREFERENCE ] route [ gw GATEWAY ]
+                [ dev OUTDEV ] .....
+
+        Warning: As of now the size of the routing table in this
+        approach is limited to 256. If someone likes this model, I'll
+        relax this limitation.
+
+3.      OSPF classes (see RFC1583, RFC1812 E.3.3)
+        Very clean, stable and robust algorithm for OSPF routing
+        domains. Unfortunately, it is not widely used in the Internet.
+
+        Proposed setup:
+        255 local addresses
+        254 interface routes
+        253 ASE routes with external metric
+        252 ASE routes with internal metric
+        251 inter-area routes
+        250 intra-area routes for 1st area
+        249 intra-area routes for 2nd area
+        etc.
+        
+        Rules:
+        iproute addrule class 253
+        iproute addrule class 252
+        iproute addrule class 251
+        iproute addrule to a-prefix-for-1st-area class 250
+        iproute addrule to another-prefix-for-1st-area class 250
+        ...
+        iproute addrule to a-prefix-for-2nd-area class 249
+        ...
+
+        Area classes must be terminated with reject record.
+        iproute add default reject class 250
+        iproute add default reject class 249
+        ...
+
+4.      The Variant Router Requirements Algorithm (RFC1812 E.3.2)
+        Create 16 classes for different TOS values.
+        It is a funny, but pretty useless algorithm.
+        I listed it just to show the power of new routing code.
+
+5.      All the variety of combinations......
+
+
+GATED
+-----
+
+        Gated does not understand classes, but it will work
+        happily in MAIN+DEFAULT. All policy routes can be set
+        and maintained manually.
+
+IMPORTANT NOTE
+--------------
+        route.c has a compilation time switch CONFIG_IP_LOCAL_RT_POLICY.
+        If it is set, locally originated packets are routed
+        using all the policy list. This is not very convenient and
+        pretty ambiguous when used with NAT and masquerading.
+        I set it to FALSE by default.
+
+
+Alexey Kuznetov
+kuznet@ms2.inr.ac.ru
diff --git a/Documentation/networking/ppp_generic.txt b/Documentation/networking/ppp_generic.txt
new file mode 100644
index 00000000000..15b5172fbb9
--- /dev/null
+++ b/Documentation/networking/ppp_generic.txt
@@ -0,0 +1,432 @@
+                PPP Generic Driver and Channel Interface
+                ----------------------------------------
+
+                            Paul Mackerras
+                           paulus@samba.org
+                              7 Feb 2002
+
+The generic PPP driver in linux-2.4 provides an implementation of the
+functionality which is of use in any PPP implementation, including:
+
+* the network interface unit (ppp0 etc.)
+* the interface to the networking code
+* PPP multilink: splitting datagrams between multiple links, and
+  ordering and combining received fragments
+* the interface to pppd, via a /dev/ppp character device
+* packet compression and decompression
+* TCP/IP header compression and decompression
+* detecting network traffic for demand dialling and for idle timeouts
+* simple packet filtering
+
+For sending and receiving PPP frames, the generic PPP driver calls on
+the services of PPP `channels'.  A PPP channel encapsulates a
+mechanism for transporting PPP frames from one machine to another.  A
+PPP channel implementation can be arbitrarily complex internally but
+has a very simple interface with the generic PPP code: it merely has
+to be able to send PPP frames, receive PPP frames, and optionally
+handle ioctl requests.  Currently there are PPP channel
+implementations for asynchronous serial ports, synchronous serial
+ports, and for PPP over ethernet.
+
+This architecture makes it possible to implement PPP multilink in a
+natural and straightforward way, by allowing more than one channel to
+be linked to each ppp network interface unit.  The generic layer is
+responsible for splitting datagrams on transmit and recombining them
+on receive.
+
+
+PPP channel API
+---------------
+
+See include/linux/ppp_channel.h for the declaration of the types and
+functions used to communicate between the generic PPP layer and PPP
+channels.
+
+Each channel has to provide two functions to the generic PPP layer,
+via the ppp_channel.ops pointer:
+
+* start_xmit() is called by the generic layer when it has a frame to
+  send.  The channel has the option of rejecting the frame for
+  flow-control reasons.  In this case, start_xmit() should return 0
+  and the channel should call the ppp_output_wakeup() function at a
+  later time when it can accept frames again, and the generic layer
+  will then attempt to retransmit the rejected frame(s).  If the frame
+  is accepted, the start_xmit() function should return 1.
+
+* ioctl() provides an interface which can be used by a user-space
+  program to control aspects of the channel's behaviour.  This
+  procedure will be called when a user-space program does an ioctl
+  system call on an instance of /dev/ppp which is bound to the
+  channel.  (Usually it would only be pppd which would do this.)
+
+The generic PPP layer provides seven functions to channels:
+
+* ppp_register_channel() is called when a channel has been created, to
+  notify the PPP generic layer of its presence.  For example, setting
+  a serial port to the PPPDISC line discipline causes the ppp_async
+  channel code to call this function.
+
+* ppp_unregister_channel() is called when a channel is to be
+  destroyed.  For example, the ppp_async channel code calls this when
+  a hangup is detected on the serial port.
+
+* ppp_output_wakeup() is called by a channel when it has previously
+  rejected a call to its start_xmit function, and can now accept more
+  packets.
+
+* ppp_input() is called by a channel when it has received a complete
+  PPP frame.
+
+* ppp_input_error() is called by a channel when it has detected that a
+  frame has been lost or dropped (for example, because of a FCS (frame
+  check sequence) error).
+
+* ppp_channel_index() returns the channel index assigned by the PPP
+  generic layer to this channel.  The channel should provide some way
+  (e.g. an ioctl) to transmit this back to user-space, as user-space
+  will need it to attach an instance of /dev/ppp to this channel.
+
+* ppp_unit_number() returns the unit number of the ppp network
+  interface to which this channel is connected, or -1 if the channel
+  is not connected.
+
+Connecting a channel to the ppp generic layer is initiated from the
+channel code, rather than from the generic layer.  The channel is
+expected to have some way for a user-level process to control it
+independently of the ppp generic layer.  For example, with the
+ppp_async channel, this is provided by the file descriptor to the
+serial port.
+
+Generally a user-level process will initialize the underlying
+communications medium and prepare it to do PPP.  For example, with an
+async tty, this can involve setting the tty speed and modes, issuing
+modem commands, and then going through some sort of dialog with the
+remote system to invoke PPP service there.  We refer to this process
+as `discovery'.  Then the user-level process tells the medium to
+become a PPP channel and register itself with the generic PPP layer.
+The channel then has to report the channel number assigned to it back
+to the user-level process.  From that point, the PPP negotiation code
+in the PPP daemon (pppd) can take over and perform the PPP
+negotiation, accessing the channel through the /dev/ppp interface.
+
+At the interface to the PPP generic layer, PPP frames are stored in
+skbuff structures and start with the two-byte PPP protocol number.
+The frame does *not* include the 0xff `address' byte or the 0x03
+`control' byte that are optionally used in async PPP.  Nor is there
+any escaping of control characters, nor are there any FCS or framing
+characters included.  That is all the responsibility of the channel
+code, if it is needed for the particular medium.  That is, the skbuffs
+presented to the start_xmit() function contain only the 2-byte
+protocol number and the data, and the skbuffs presented to ppp_input()
+must be in the same format.
+
+The channel must provide an instance of a ppp_channel struct to
+represent the channel.  The channel is free to use the `private' field
+however it wishes.  The channel should initialize the `mtu' and
+`hdrlen' fields before calling ppp_register_channel() and not change
+them until after ppp_unregister_channel() returns.  The `mtu' field
+represents the maximum size of the data part of the PPP frames, that
+is, it does not include the 2-byte protocol number.
+
+If the channel needs some headroom in the skbuffs presented to it for
+transmission (i.e., some space free in the skbuff data area before the
+start of the PPP frame), it should set the `hdrlen' field of the
+ppp_channel struct to the amount of headroom required.  The generic
+PPP layer will attempt to provide that much headroom but the channel
+should still check if there is sufficient headroom and copy the skbuff
+if there isn't.
+
+On the input side, channels should ideally provide at least 2 bytes of
+headroom in the skbuffs presented to ppp_input().  The generic PPP
+code does not require this but will be more efficient if this is done.
+
+
+Buffering and flow control
+--------------------------
+
+The generic PPP layer has been designed to minimize the amount of data
+that it buffers in the transmit direction.  It maintains a queue of
+transmit packets for the PPP unit (network interface device) plus a
+queue of transmit packets for each attached channel.  Normally the
+transmit queue for the unit will contain at most one packet; the
+exceptions are when pppd sends packets by writing to /dev/ppp, and
+when the core networking code calls the generic layer's start_xmit()
+function with the queue stopped, i.e. when the generic layer has
+called netif_stop_queue(), which only happens on a transmit timeout.
+The start_xmit function always accepts and queues the packet which it
+is asked to transmit.
+
+Transmit packets are dequeued from the PPP unit transmit queue and
+then subjected to TCP/IP header compression and packet compression
+(Deflate or BSD-Compress compression), as appropriate.  After this
+point the packets can no longer be reordered, as the decompression
+algorithms rely on receiving compressed packets in the same order that
+they were generated.
+
+If multilink is not in use, this packet is then passed to the attached
+channel's start_xmit() function.  If the channel refuses to take
+the packet, the generic layer saves it for later transmission.  The
+generic layer will call the channel's start_xmit() function again
+when the channel calls  ppp_output_wakeup() or when the core
+networking code calls the generic layer's start_xmit() function
+again.  The generic layer contains no timeout and retransmission
+logic; it relies on the core networking code for that.
+
+If multilink is in use, the generic layer divides the packet into one
+or more fragments and puts a multilink header on each fragment.  It
+decides how many fragments to use based on the length of the packet
+and the number of channels which are potentially able to accept a
+fragment at the moment.  A channel is potentially able to accept a
+fragment if it doesn't have any fragments currently queued up for it
+to transmit.  The channel may still refuse a fragment; in this case
+the fragment is queued up for the channel to transmit later.  This
+scheme has the effect that more fragments are given to higher-
+bandwidth channels.  It also means that under light load, the generic
+layer will tend to fragment large packets across all the channels,
+thus reducing latency, while under heavy load, packets will tend to be
+transmitted as single fragments, thus reducing the overhead of
+fragmentation.
+
+
+SMP safety
+----------
+
+The PPP generic layer has been designed to be SMP-safe.  Locks are
+used around accesses to the internal data structures where necessary
+to ensure their integrity.  As part of this, the generic layer
+requires that the channels adhere to certain requirements and in turn
+provides certain guarantees to the channels.  Essentially the channels
+are required to provide the appropriate locking on the ppp_channel
+structures that form the basis of the communication between the
+channel and the generic layer.  This is because the channel provides
+the storage for the ppp_channel structure, and so the channel is
+required to provide the guarantee that this storage exists and is
+valid at the appropriate times.
+
+The generic layer requires these guarantees from the channel:
+
+* The ppp_channel object must exist from the time that
+  ppp_register_channel() is called until after the call to
+  ppp_unregister_channel() returns.
+
+* No thread may be in a call to any of ppp_input(), ppp_input_error(),
+  ppp_output_wakeup(), ppp_channel_index() or ppp_unit_number() for a
+  channel at the time that ppp_unregister_channel() is called for that
+  channel.
+
+* ppp_register_channel() and ppp_unregister_channel() must be called
+  from process context, not interrupt or softirq/BH context.
+
+* The remaining generic layer functions may be called at softirq/BH
+  level but must not be called from a hardware interrupt handler.
+
+* The generic layer may call the channel start_xmit() function at
+  softirq/BH level but will not call it at interrupt level.  Thus the
+  start_xmit() function may not block.
+
+* The generic layer will only call the channel ioctl() function in
+  process context.
+
+The generic layer provides these guarantees to the channels:
+
+* The generic layer will not call the start_xmit() function for a
+  channel while any thread is already executing in that function for
+  that channel.
+
+* The generic layer will not call the ioctl() function for a channel
+  while any thread is already executing in that function for that
+  channel.
+
+* By the time a call to ppp_unregister_channel() returns, no thread
+  will be executing in a call from the generic layer to that channel's
+  start_xmit() or ioctl() function, and the generic layer will not
+  call either of those functions subsequently.
+
+
+Interface to pppd
+-----------------
+
+The PPP generic layer exports a character device interface called
+/dev/ppp.  This is used by pppd to control PPP interface units and
+channels.  Although there is only one /dev/ppp, each open instance of
+/dev/ppp acts independently and can be attached either to a PPP unit
+or a PPP channel.  This is achieved using the file->private_data field
+to point to a separate object for each open instance of /dev/ppp.  In
+this way an effect similar to Solaris' clone open is obtained,
+allowing us to control an arbitrary number of PPP interfaces and
+channels without having to fill up /dev with hundreds of device names.
+
+When /dev/ppp is opened, a new instance is created which is initially
+unattached.  Using an ioctl call, it can then be attached to an
+existing unit, attached to a newly-created unit, or attached to an
+existing channel.  An instance attached to a unit can be used to send
+and receive PPP control frames, using the read() and write() system
+calls, along with poll() if necessary.  Similarly, an instance
+attached to a channel can be used to send and receive PPP frames on
+that channel.
+
+In multilink terms, the unit represents the bundle, while the channels
+represent the individual physical links.  Thus, a PPP frame sent by a
+write to the unit (i.e., to an instance of /dev/ppp attached to the
+unit) will be subject to bundle-level compression and to fragmentation
+across the individual links (if multilink is in use).  In contrast, a
+PPP frame sent by a write to the channel will be sent as-is on that
+channel, without any multilink header.
+
+A channel is not initially attached to any unit.  In this state it can
+be used for PPP negotiation but not for the transfer of data packets.
+It can then be connected to a PPP unit with an ioctl call, which
+makes it available to send and receive data packets for that unit.
+
+The ioctl calls which are available on an instance of /dev/ppp depend
+on whether it is unattached, attached to a PPP interface, or attached
+to a PPP channel.  The ioctl calls which are available on an
+unattached instance are:
+
+* PPPIOCNEWUNIT creates a new PPP interface and makes this /dev/ppp
+  instance the "owner" of the interface.  The argument should point to
+  an int which is the desired unit number if >= 0, or -1 to assign the
+  lowest unused unit number.  Being the owner of the interface means
+  that the interface will be shut down if this instance of /dev/ppp is
+  closed.
+
+* PPPIOCATTACH attaches this instance to an existing PPP interface.
+  The argument should point to an int containing the unit number.
+  This does not make this instance the owner of the PPP interface.
+
+* PPPIOCATTCHAN attaches this instance to an existing PPP channel.
+  The argument should point to an int containing the channel number.
+
+The ioctl calls available on an instance of /dev/ppp attached to a
+channel are:
+
+* PPPIOCDETACH detaches the instance from the channel.  This ioctl is
+  deprecated since the same effect can be achieved by closing the
+  instance.  In order to prevent possible races this ioctl will fail
+  with an EINVAL error if more than one file descriptor refers to this
+  instance (i.e. as a result of dup(), dup2() or fork()).
+
+* PPPIOCCONNECT connects this channel to a PPP interface.  The
+  argument should point to an int containing the interface unit
+  number.  It will return an EINVAL error if the channel is already
+  connected to an interface, or ENXIO if the requested interface does
+  not exist.
+
+* PPPIOCDISCONN disconnects this channel from the PPP interface that
+  it is connected to.  It will return an EINVAL error if the channel
+  is not connected to an interface.
+
+* All other ioctl commands are passed to the channel ioctl() function.
+
+The ioctl calls that are available on an instance that is attached to
+an interface unit are:
+
+* PPPIOCSMRU sets the MRU (maximum receive unit) for the interface.
+  The argument should point to an int containing the new MRU value.
+
+* PPPIOCSFLAGS sets flags which control the operation of the
+  interface.  The argument should be a pointer to an int containing
+  the new flags value.  The bits in the flags value that can be set
+  are:
+        SC_COMP_TCP             enable transmit TCP header compression
+        SC_NO_TCP_CCID          disable connection-id compression for
+                                TCP header compression
+        SC_REJ_COMP_TCP         disable receive TCP header decompression
+        SC_CCP_OPEN             Compression Control Protocol (CCP) is
+                                open, so inspect CCP packets
+        SC_CCP_UP               CCP is up, may (de)compress packets
+        SC_LOOP_TRAFFIC         send IP traffic to pppd
+        SC_MULTILINK            enable PPP multilink fragmentation on
+                                transmitted packets
+        SC_MP_SHORTSEQ          expect short multilink sequence
+                                numbers on received multilink fragments
+        SC_MP_XSHORTSEQ         transmit short multilink sequence nos.
+
+  The values of these flags are defined in <linux/if_ppp.h>.  Note
+  that the values of the SC_MULTILINK, SC_MP_SHORTSEQ and
+  SC_MP_XSHORTSEQ bits are ignored if the CONFIG_PPP_MULTILINK option
+  is not selected.
+
+* PPPIOCGFLAGS returns the value of the status/control flags for the
+  interface unit.  The argument should point to an int where the ioctl
+  will store the flags value.  As well as the values listed above for
+  PPPIOCSFLAGS, the following bits may be set in the returned value:
+        SC_COMP_RUN             CCP compressor is running
+        SC_DECOMP_RUN           CCP decompressor is running
+        SC_DC_ERROR             CCP decompressor detected non-fatal error
+        SC_DC_FERROR            CCP decompressor detected fatal error
+
+* PPPIOCSCOMPRESS sets the parameters for packet compression or
+  decompression.  The argument should point to a ppp_option_data
+  structure (defined in <linux/if_ppp.h>), which contains a
+  pointer/length pair which should describe a block of memory
+  containing a CCP option specifying a compression method and its
+  parameters.  The ppp_option_data struct also contains a `transmit'
+  field.  If this is 0, the ioctl will affect the receive path,
+  otherwise the transmit path.
+
+* PPPIOCGUNIT returns, in the int pointed to by the argument, the unit
+  number of this interface unit.
+
+* PPPIOCSDEBUG sets the debug flags for the interface to the value in
+  the int pointed to by the argument.  Only the least significant bit
+  is used; if this is 1 the generic layer will print some debug
+  messages during its operation.  This is only intended for debugging
+  the generic PPP layer code; it is generally not helpful for working
+  out why a PPP connection is failing.
+
+* PPPIOCGDEBUG returns the debug flags for the interface in the int
+  pointed to by the argument.
+
+* PPPIOCGIDLE returns the time, in seconds, since the last data
+  packets were sent and received.  The argument should point to a
+  ppp_idle structure (defined in <linux/ppp_defs.h>).  If the
+  CONFIG_PPP_FILTER option is enabled, the set of packets which reset
+  the transmit and receive idle timers is restricted to those which
+  pass the `active' packet filter.
+
+* PPPIOCSMAXCID sets the maximum connection-ID parameter (and thus the
+  number of connection slots) for the TCP header compressor and
+  decompressor.  The lower 16 bits of the int pointed to by the
+  argument specify the maximum connection-ID for the compressor.  If
+  the upper 16 bits of that int are non-zero, they specify the maximum
+  connection-ID for the decompressor, otherwise the decompressor's
+  maximum connection-ID is set to 15.
+
+* PPPIOCSNPMODE sets the network-protocol mode for a given network
+  protocol.  The argument should point to an npioctl struct (defined
+  in <linux/if_ppp.h>).  The `protocol' field gives the PPP protocol
+  number for the protocol to be affected, and the `mode' field
+  specifies what to do with packets for that protocol:
+
+        NPMODE_PASS     normal operation, transmit and receive packets
+        NPMODE_DROP     silently drop packets for this protocol
+        NPMODE_ERROR    drop packets and return an error on transmit
+        NPMODE_QUEUE    queue up packets for transmit, drop received
+                        packets
+
+  At present NPMODE_ERROR and NPMODE_QUEUE have the same effect as
+  NPMODE_DROP.
+
+* PPPIOCGNPMODE returns the network-protocol mode for a given
+  protocol.  The argument should point to an npioctl struct with the
+  `protocol' field set to the PPP protocol number for the protocol of
+  interest.  On return the `mode' field will be set to the network-
+  protocol mode for that protocol.
+
+* PPPIOCSPASS and PPPIOCSACTIVE set the `pass' and `active' packet
+  filters.  These ioctls are only available if the CONFIG_PPP_FILTER
+  option is selected.  The argument should point to a sock_fprog
+  structure (defined in <linux/filter.h>) containing the compiled BPF
+  instructions for the filter.  Packets are dropped if they fail the
+  `pass' filter; otherwise, if they fail the `active' filter they are
+  passed but they do not reset the transmit or receive idle timer.
+
+* PPPIOCSMRRU enables or disables multilink processing for received
+  packets and sets the multilink MRRU (maximum reconstructed receive
+  unit).  The argument should point to an int containing the new MRRU
+  value.  If the MRRU value is 0, processing of received multilink
+  fragments is disabled.  This ioctl is only available if the
+  CONFIG_PPP_MULTILINK option is selected.
+
+Last modified: 7-feb-2002
diff --git a/Documentation/networking/proc_net_tcp.txt b/Documentation/networking/proc_net_tcp.txt
new file mode 100644
index 00000000000..59cb915c371
--- /dev/null
+++ b/Documentation/networking/proc_net_tcp.txt
@@ -0,0 +1,47 @@
+This document describes the interfaces /proc/net/tcp and /proc/net/tcp6.
+
+These /proc interfaces provide information about currently active TCP 
+connections, and are implemented by tcp_get_info() in net/ipv4/tcp_ipv4.c and
+tcp6_get_info() in net/ipv6/tcp_ipv6.c, respectively.
+
+It will first list all listening TCP sockets, and next list all established
+TCP connections. A typical entry of /proc/net/tcp would look like this (split 
+up into 3 parts because of the length of the line):
+
+   46: 010310AC:9C4C 030310AC:1770 01 
+   |      |      |      |      |   |--> connection state
+   |      |      |      |      |------> remote TCP port number
+   |      |      |      |-------------> remote IPv4 address
+   |      |      |--------------------> local TCP port number
+   |      |---------------------------> local IPv4 address
+   |----------------------------------> number of entry
+
+   00000150:00000000 01:00000019 00000000  
+      |        |     |     |       |--> number of unrecovered RTO timeouts
+      |        |     |     |----------> number of jiffies until timer expires
+      |        |     |----------------> timer_active (see below)
+      |        |----------------------> receive-queue
+      |-------------------------------> transmit-queue
+
+   1000        0 54165785 4 cd1e6040 25 4 27 3 -1
+    |          |    |     |    |     |  | |  | |--> slow start size threshold, 
+    |          |    |     |    |     |  | |  |      or -1 if the treshold
+    |          |    |     |    |     |  | |  |      is >= 0xFFFF
+    |          |    |     |    |     |  | |  |----> sending congestion window
+    |          |    |     |    |     |  | |-------> (ack.quick<<1)|ack.pingpong
+    |          |    |     |    |     |  |---------> Predicted tick of soft clock
+    |          |    |     |    |     |              (delayed ACK control data)
+    |          |    |     |    |     |------------> retransmit timeout
+    |          |    |     |    |------------------> location of socket in memory
+    |          |    |     |-----------------------> socket reference count
+    |          |    |-----------------------------> inode
+    |          |----------------------------------> unanswered 0-window probes
+    |---------------------------------------------> uid
+
+timer_active:
+  0  no timer is pending
+  1  retransmit-timer is pending
+  2  another timer (e.g. delayed ack or keepalive) is pending
+  3  this is a socket in TIME_WAIT state. Not all fields will contain 
+     data (or even exist)
+  4  zero window probe timer is pending
diff --git a/Documentation/networking/pt.txt b/Documentation/networking/pt.txt
new file mode 100644
index 00000000000..72e888c1d98
--- /dev/null
+++ b/Documentation/networking/pt.txt
@@ -0,0 +1,58 @@
+This is the README for the Gracilis Packetwin device driver, version 0.5
+ALPHA for Linux 1.3.43.
+
+These files will allow you to talk to the PackeTwin (now know as PT) and
+connect through it just like a pair of TNCs.  To do this you will also
+require the AX.25 code in the kernel enabled.
+
+There are four files in this archive; this readme, a patch file, a .c file
+and finally a .h file.  The two program files need to be put into the
+drivers/net directory in the Linux source tree, for me this is the
+directory /usr/src/linux/drivers/net.  The patch file needs to be patched in
+at the top of the Linux source tree (/usr/src/linux in my case).
+
+You will most probably have to edit the pt.c file to suit your own setup,
+this should just involve changing some of the defines at the top of the file. 
+Please note that if you run an external modem you must specify a speed of 0.
+
+The program is currently setup to run a 4800 baud external modem on port A
+and a Kantronics DE-9600 daughter board on port B so if you have this (or
+something similar) then you're right.
+
+To compile in the driver, put the files in the correct place and patch in
+the diff.  You will have to re-configure the kernel again before you
+recompile it. 
+
+The driver is not real good at the moment for finding the card.  You can
+'help' it by changing the order of the potential addresses in the structure
+found in the pt_init() function so the address of where the card is is put
+first.
+
+After compiling, you have to get them going, they are pretty well like any
+other net device and just need ifconfig to get them going.
+As an example, here is my /etc/rc.net
+--------------------------
+
+#
+# Configure the PackeTwin, port A.
+/sbin/ifconfig pt0a 44.136.8.87 hw ax25 vk2xlz mtu 512 
+/sbin/ifconfig pt0a 44.136.8.87 broadcast 44.136.8.255 netmask 255.255.255.0
+/sbin/route add -net 44.136.8.0 netmask 255.255.255.0 dev pt0a
+/sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.136.8.68 dev pt0a
+/sbin/route add -net 138.25.16.0 netmask 255.255.240.0 dev pt0a
+/sbin/route add -host 44.136.8.255 dev pt0a
+#
+# Configure the PackeTwin, port B.
+/sbin/ifconfig pt0b 44.136.8.87 hw ax25 vk2xlz-1 mtu 512
+/sbin/ifconfig pt0b 44.136.8.87 broadcast 44.255.255.255 netmask 255.0.0.0
+/sbin/route add -host 44.136.8.216 dev pt0b
+/sbin/route add -host 44.136.8.95  dev pt0b
+/sbin/route add -host 44.255.255.255 dev pt0b
+
+This version of the driver comes under the GNU GPL.  If you have one of my
+previous (non-GPL) versions of the driver, please update to this one.
+
+I hope that this all works well for you.  I would be pleased to hear how
+many people use the driver and if it does its job.
+
+  - Craig vk2xlz <csmall@small.dropbear.id.au>
diff --git a/Documentation/networking/ray_cs.txt b/Documentation/networking/ray_cs.txt
new file mode 100644
index 00000000000..b1def00bc4a
--- /dev/null
+++ b/Documentation/networking/ray_cs.txt
@@ -0,0 +1,151 @@
+September 21, 1999
+
+Copyright (c) 1998  Corey Thomas (corey@world.std.com)
+
+This file is the documentation for the Raylink Wireless LAN card driver for
+Linux.  The Raylink wireless LAN card is a PCMCIA card which provides IEEE
+802.11 compatible wireless network connectivity at 1 and 2 megabits/second.
+See http://www.raytheon.com/micro/raylink/ for more information on the Raylink
+card.  This driver is in early development and does have bugs.  See the known
+bugs and limitations at the end of this document for more information.
+This driver also works with WebGear's Aviator 2.4 and Aviator Pro
+wireless LAN cards.
+
+As of kernel 2.3.18, the ray_cs driver is part of the Linux kernel
+source.  My web page for the development of ray_cs is at
+http://world.std.com/~corey/raylink.html and I can be emailed at
+corey@world.std.com
+
+The kernel driver is based on ray_cs-1.62.tgz
+
+The driver at my web page is intended to be used as an add on to
+David Hinds pcmcia package.  All the command line parameters are
+available when compiled as a module.  When built into the kernel, only
+the essid= string parameter is available via the kernel command line.
+This will change after the method of sorting out parameters for all
+the PCMCIA drivers is agreed upon.  If you must have a built in driver
+with nondefault parameters, they can be edited in
+/usr/src/linux/drivers/net/pcmcia/ray_cs.c.  Searching for MODULE_PARM
+will find them all.
+
+Information on card services is available at:
+        ftp://hyper.stanford.edu/pub/pcmcia/doc
+        http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html
+
+
+Card services user programs are still required for PCMCIA devices.
+pcmcia-cs-3.1.1 or greater is required for the kernel version of
+the driver.
+
+Currently, ray_cs is not part of David Hinds card services package,
+so the following magic is required.
+
+At the end of the /etc/pcmcia/config.opts file, add the line: 
+source ./ray_cs.opts 
+This will make card services read the ray_cs.opts file
+when starting.  Create the file /etc/pcmcia/ray_cs.opts containing the
+following:
+
+#### start of /etc/pcmcia/ray_cs.opts ###################
+# Configuration options for Raylink Wireless LAN PCMCIA card
+device "ray_cs"
+  class "network" module "misc/ray_cs"
+
+card "RayLink PC Card WLAN Adapter"
+  manfid 0x01a6, 0x0000
+  bind "ray_cs"
+
+module "misc/ray_cs" opts ""
+#### end of /etc/pcmcia/ray_cs.opts #####################
+
+
+To join an existing network with
+different parameters, contact the network administrator for the 
+configuration information, and edit /etc/pcmcia/ray_cs.opts.
+Add the parameters below between the empty quotes.
+
+Parameters for ray_cs driver which may be specified in ray_cs.opts:
+
+bc              integer         0 = normal mode (802.11 timing)
+                                1 = slow down inter frame timing to allow
+                                    operation with older breezecom access
+                                    points.
+
+beacon_period   integer         beacon period in Kilo-microseconds
+                                legal values = must be integer multiple 
+                                               of hop dwell
+                                default = 256
+
+country         integer         1 = USA (default)
+                                2 = Europe
+                                3 = Japan
+                                4 = Korea
+                                5 = Spain
+                                6 = France
+                                7 = Israel
+                                8 = Australia
+
+essid           string          ESS ID - network name to join
+                                string with maximum length of 32 chars
+                                default value = "ADHOC_ESSID"
+
+hop_dwell       integer         hop dwell time in Kilo-microseconds 
+                                legal values = 16,32,64,128(default),256
+
+irq_mask        integer         linux standard 16 bit value 1bit/IRQ
+                                lsb is IRQ 0, bit 1 is IRQ 1 etc.
+                                Used to restrict choice of IRQ's to use.
+                                Recommended method for controlling
+                                interrupts is in /etc/pcmcia/config.opts
+
+net_type        integer         0 (default) = adhoc network, 
+                                1 = infrastructure
+
+phy_addr        string          string containing new MAC address in
+                                hex, must start with x eg
+                                x00008f123456
+
+psm             integer         0 = continuously active
+                                1 = power save mode (not useful yet)
+
+pc_debug        integer         (0-5) larger values for more verbose
+                                logging.  Replaces ray_debug.
+
+ray_debug       integer         Replaced with pc_debug
+
+ray_mem_speed   integer         defaults to 500
+
+sniffer         integer         0 = not sniffer (default)
+                                1 = sniffer which can be used to record all
+                                    network traffic using tcpdump or similar, 
+                                    but no normal network use is allowed.
+
+translate       integer         0 = no translation (encapsulate frames)
+                                1 = translation    (RFC1042/802.1)
+
+
+More on sniffer mode:
+
+tcpdump does not understand 802.11 headers, so it can't
+interpret the contents, but it can record to a file.  This is only
+useful for debugging 802.11 lowlevel protocols that are not visible to
+linux.  If you want to watch ftp xfers, or do similar things, you
+don't need to use sniffer mode.  Also, some packet types are never
+sent up by the card, so you will never see them (ack, rts, cts, probe
+etc.)  There is a simple program (showcap) included in the ray_cs
+package which parses the 802.11 headers.
+
+Known Problems and missing features
+
+        Does not work with non x86
+
+        Does not work with SMP
+
+        Support for defragmenting frames is not yet debugged, and in
+        fact is known to not work.  I have never encountered a net set
+        up to fragment, but still, it should be fixed.
+
+        The ioctl support is incomplete.  The hardware address cannot be set
+        using ifconfig yet.  If a different hardware address is needed, it may
+        be set using the phy_addr parameter in ray_cs.opts.  This requires
+        a card insertion to take effect.
diff --git a/Documentation/networking/routing.txt b/Documentation/networking/routing.txt
new file mode 100644
index 00000000000..a26838b930f
--- /dev/null
+++ b/Documentation/networking/routing.txt
@@ -0,0 +1,46 @@
+The directory ftp.inr.ac.ru:/ip-routing contains:
+
+- iproute.c - "professional" routing table maintenance utility.
+
+- rdisc.tar.gz - rdisc daemon, ported from Sun.
+        STRONGLY RECOMMENDED FOR ALL HOSTS.
+
+- routing.tgz - original Mike McLagan's route by source patch.
+                Currently it is obsolete.
+
+- gated.dif-ss<NEWEST>.gz - gated-R3_6Alpha_2 fixes.
+                Look at README.gated
+
+- mrouted-3.8.dif.gz - mrouted-3.8 fixes.
+
+- rtmon.c - trivial debugging utility: reads and stores netlink.
+
+
+NEWS for user.
+
+- Policy based routing. Routing decisions are made on the basis
+  not only of destination address, but also source address,
+  TOS and incoming interface.
+- Complete set of IP level control messages.
+  Now Linux is the only OS in the world complying to RFC requirements.
+  Great win 8)
+- New interface addressing paradigm.
+  Assignment of address ranges to interface,
+  multiple prefixes etc. etc.
+  Do not bother, it is compatible with the old one. Moreover:
+- You don't need to do "route add aaa.bbb.ccc... eth0" anymore,
+  it is done automatically.
+- "Abstract" UNIX sockets and security enhancements.
+  This is necessary to use TIRPC and TLI emulation library.
+
+NEWS for hacker.
+
+- New destination cache. Flexible, robust and just beautiful.
+- Network stack is reordered, simplified, optimized, a lot of bugs fixed.
+  (well, and new bugs were introduced, but I haven't seen them yet 8))
+  It is difficult to describe all the changes, look into source.
+
+If you see this file, then this patch works 8)
+
+Alexey Kuznetsov.
+kuznet@ms2.inr.ac.ru
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt
new file mode 100644
index 00000000000..6726b524ec4
--- /dev/null
+++ b/Documentation/networking/s2io.txt
@@ -0,0 +1,48 @@
+S2IO Technologies XFrame 10 Gig adapter.
+-------------------------------------------
+
+I. Module loadable parameters.
+When loaded as a module, the driver provides a host of Module loadable
+parameters, so the device can be tuned as per the users needs.
+A list of the Module params is given below.
+(i)     ring_num: This can be used to program the number of
+                 receive rings used in the driver.
+(ii)    ring_len: This defines the number of descriptors each ring
+                 can have. There can be a maximum of 8 rings.
+(iii)   frame_len: This is an array of size 8. Using this we can 
+                 set the maximum size of the received frame that can
+                 be steered into the corrsponding receive ring. 
+(iv)    fifo_num: This defines the number of Tx FIFOs thats used in
+                 the driver. 
+(v)     fifo_len: Each element defines the number of 
+                 Tx descriptors that can be associated with each 
+                 corresponding FIFO. There are a maximum of 8 FIFOs.
+(vi)    tx_prio: This is a bool, if module is loaded with a non-zero
+                value for tx_prio multi FIFO scheme is activated.
+(vii)   rx_prio: This is a bool, if module is loaded with a non-zero
+                value for tx_prio multi RING scheme is activated.
+(viii)  latency_timer: The value given against this param will be
+                 loaded into the latency timer register in PCI Config
+                 space, else the register is left with its reset value.
+
+II. Performance tuning.
+ By changing a few sysctl parameters.
+        Copy the following lines into a file and run the following command,
+        "sysctl -p <file_name>"
+### IPV4 specific settings
+net.ipv4.tcp_timestamps = 0 # turns TCP timestamp support off, default 1, reduces CPU use
+net.ipv4.tcp_sack = 0 # turn SACK support off, default on
+# on systems with a VERY fast bus -> memory interface this is the big gainer
+net.ipv4.tcp_rmem = 10000000 10000000 10000000 # sets min/default/max TCP read buffer, default 4096 87380 174760
+net.ipv4.tcp_wmem = 10000000 10000000 10000000 # sets min/pressure/max TCP write buffer, default 4096 16384 131072
+net.ipv4.tcp_mem = 10000000 10000000 10000000 # sets min/pressure/max TCP buffer space, default 31744 32256 32768
+                                                                                
+### CORE settings (mostly for socket and UDP effect)
+net.core.rmem_max = 524287 # maximum receive socket buffer size, default 131071
+net.core.wmem_max = 524287 # maximum send socket buffer size, default 131071
+net.core.rmem_default = 524287 # default receive socket buffer size, default 65535
+net.core.wmem_default = 524287 # default send socket buffer size, default 65535
+net.core.optmem_max = 524287 # maximum amount of option memory buffers, default 10240
+net.core.netdev_max_backlog = 300000 # number of unprocessed input packets before kernel starts dropping them, default 300
+---End of performance tuning file---
+
diff --git a/Documentation/networking/sctp.txt b/Documentation/networking/sctp.txt
new file mode 100644
index 00000000000..0c790a76910
--- /dev/null
+++ b/Documentation/networking/sctp.txt
@@ -0,0 +1,38 @@
+Linux Kernel SCTP 
+
+This is the current BETA release of the Linux Kernel SCTP reference
+implementation.  
+
+SCTP (Stream Control Transmission Protocol) is a IP based, message oriented,
+reliable transport protocol, with congestion control, support for
+transparent multi-homing, and multiple ordered streams of messages.
+RFC2960 defines the core protocol.  The IETF SIGTRAN working group originally
+developed the SCTP protocol and later handed the protocol over to the 
+Transport Area (TSVWG) working group for the continued evolvement of SCTP as a 
+general purpose transport.  
+
+See the IETF website (http://www.ietf.org) for further documents on SCTP. 
+See http://www.ietf.org/rfc/rfc2960.txt 
+
+The initial project goal is to create an Linux kernel reference implementation
+of SCTP that is RFC 2960 compliant and provides an programming interface 
+referred to as the  UDP-style API of the Sockets Extensions for SCTP, as 
+proposed in IETF Internet-Drafts.    
+
+
+Caveats:  
+
+-lksctp can be built as statically or as a module.  However, be aware that 
+module removal of lksctp is not yet a safe activity.   
+
+-There is tentative support for IPv6, but most work has gone towards 
+implementation and testing lksctp on IPv4.   
+
+
+For more information, please visit the lksctp project website:
+   http://www.sf.net/projects/lksctp
+
+Or contact the lksctp developers through the mailing list:
+   <lksctp-developers@lists.sourceforge.net> 
+
+
diff --git a/Documentation/networking/shaper.txt b/Documentation/networking/shaper.txt
new file mode 100644
index 00000000000..6c4ebb66a90
--- /dev/null
+++ b/Documentation/networking/shaper.txt
@@ -0,0 +1,48 @@
+Traffic Shaper For Linux
+
+This is the current BETA release of the traffic shaper for Linux. It works
+within the following limits:
+
+o       Minimum shaping speed is currently about 9600 baud (it can only
+shape down to 1 byte per clock tick)
+
+o       Maximum is about 256K, it will go above this but get a bit blocky.
+
+o       If you ifconfig the master device that a shaper is attached to down
+then your machine will follow.
+
+o       The shaper must be a module.
+
+
+Setup:
+
+        A shaper device is configured using the shapeconfig program.
+Typically you will do something like this
+
+shapecfg attach shaper0 eth1
+shapecfg speed shaper0 64000
+ifconfig shaper0 myhost netmask 255.255.255.240 broadcast 1.2.3.4.255 up
+route add -net some.network netmask a.b.c.d dev shaper0
+
+The shaper should have the same IP address as the device it is attached to
+for normal use.
+
+Gotchas:
+
+        The shaper shapes transmitted traffic. It's rather impossible to
+shape received traffic except at the end (or a router) transmitting it.
+
+        Gated/routed/rwhod/mrouted all see the shaper as an additional device
+and will treat it as such unless patched. Note that for mrouted you can run
+mrouted tunnels via a traffic shaper to control bandwidth usage.
+
+        The shaper is device/route based. This makes it very easy to use
+with any setup BUT less flexible. You may need to use iproute2 to set up
+multiple route tables to get the flexibility.
+
+        There is no "borrowing" or "sharing" scheme. This is a simple
+traffic limiter. We implement Van Jacobson and Sally Floyd's CBQ
+architecture into Linux 2.2. This is the preferred solution. Shaper is
+for simple or back compatible setups.
+
+Alan
diff --git a/Documentation/networking/sis900.txt b/Documentation/networking/sis900.txt
new file mode 100644
index 00000000000..bddffd7385a
--- /dev/null
+++ b/Documentation/networking/sis900.txt
@@ -0,0 +1,257 @@
+
+SiS 900/7016 Fast Ethernet Device Driver
+
+Ollie Lho
+
+Lei Chun Chang
+
+   Copyright © 1999 by Silicon Integrated System Corp.
+   
+   This document gives some information on installation and usage of SiS
+   900/7016 device driver under Linux.
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or (at
+   your option) any later version.
+   
+   This program is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+   General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+   USA
+     _________________________________________________________________
+   
+   Table of Contents
+   1. Introduction
+   2. Changes
+   3. Tested Environment
+   4. Files in This Package
+   5. Installation
+          
+        Building the driver as loadable module
+        Building the driver into kernel
+                
+   6. Known Problems and Bugs
+   7. Revision History
+   8. Acknowledgements
+     _________________________________________________________________
+   
+Chapter 1. Introduction
+
+   This document describes the revision 1.06 and 1.07 of SiS 900/7016
+   Fast Ethernet device driver under Linux. The driver is developed by
+   Silicon Integrated System Corp. and distributed freely under the GNU
+   General Public License (GPL). The driver can be compiled as a loadable
+   module and used under Linux kernel version 2.2.x. (rev. 1.06) With
+   minimal changes, the driver can also be used under 2.3.x and 2.4.x
+   kernel (rev. 1.07), please see Chapter 5. If you are intended to use
+   the driver for earlier kernels, you are on your own.
+   
+   The driver is tested with usual TCP/IP applications including FTP,
+   Telnet, Netscape etc. and is used constantly by the developers.
+   
+   Please send all comments/fixes/questions to Lei-Chun Chang.
+     _________________________________________________________________
+   
+Chapter 2. Changes
+
+   Changes made in Revision 1.07
+   
+    1. Separation of sis900.c and sis900.h in order to move most constant
+       definition to sis900.h (many of those constants were corrected)
+    2. Clean up PCI detection, the pci-scan from Donald Becker were not
+       used, just simple pci_find_*.
+    3. MII detection is modified to support multiple mii transceiver.
+    4. Bugs in read_eeprom, mdio_* were removed.
+    5. Lot of sis900 irrelevant comments were removed/changed and more
+       comments were added to reflect the real situation.
+    6. Clean up of physical/virtual address space mess in buffer
+       descriptors.
+    7. Better transmit/receive error handling.
+    8. The driver now uses zero-copy single buffer management scheme to
+       improve performance.
+    9. Names of variables were changed to be more consistent.
+   10. Clean up of auo-negotiation and timer code.
+   11. Automatic detection and change of PHY on the fly.
+   12. Bug in mac probing fixed.
+   13. Fix 630E equalier problem by modifying the equalizer workaround
+       rule.
+   14. Support for ICS1893 10/100 Interated PHYceiver.
+   15. Support for media select by ifconfig.
+   16. Added kernel-doc extratable documentation.
+     _________________________________________________________________
+   
+Chapter 3. Tested Environment
+
+   This driver is developed on the following hardware
+   
+     * Intel Celeron 500 with SiS 630 (rev 02) chipset
+     * SiS 900 (rev 01) and SiS 7016/7014 Fast Ethernet Card
+       
+   and tested with these software environments
+   
+     * Red Hat Linux version 6.2
+     * Linux kernel version 2.4.0
+     * Netscape version 4.6
+     * NcFTP 3.0.0 beta 18
+     * Samba version 2.0.3
+     _________________________________________________________________
+   
+Chapter 4. Files in This Package
+
+   In the package you can find these files:
+   
+   sis900.c
+          Driver source file in C
+          
+   sis900.h
+          Header file for sis900.c
+          
+   sis900.sgml
+          DocBook SGML source of the document
+          
+   sis900.txt
+          Driver document in plain text
+     _________________________________________________________________
+   
+Chapter 5. Installation
+
+   Silicon Integrated System Corp. is cooperating closely with core Linux
+   Kernel developers. The revisions of SiS 900 driver are distributed by
+   the usuall channels for kernel tar files and patches. Those kernel tar
+   files for official kernel and patches for kernel pre-release can be
+   download at official kernel ftp site and its mirrors. The 1.06
+   revision can be found in kernel version later than 2.3.15 and
+   pre-2.2.14, and 1.07 revision can be found in kernel version 2.4.0. If
+   you have no prior experience in networking under Linux, please read
+   Ethernet HOWTO and Networking HOWTO available from Linux Documentation
+   Project (LDP).
+   
+   The driver is bundled in release later than 2.2.11 and 2.3.15 so this
+   is the most easy case. Be sure you have the appropriate packages for
+   compiling kernel source. Those packages are listed in Document/Changes
+   in kernel source distribution. If you have to install the driver other
+   than those bundled in kernel release, you should have your driver file
+   sis900.c and sis900.h copied into /usr/src/linux/drivers/net/ first.
+   There are two alternative ways to install the driver
+     _________________________________________________________________
+   
+Building the driver as loadable module
+
+   To build the driver as a loadable kernel module you have to
+   reconfigure the kernel to activate network support by
+   
+make menuconfig
+
+   Choose "Loadable module support --->", then select "Enable loadable
+   module support".
+   
+   Choose "Network Device Support --->", select "Ethernet (10 or
+   100Mbit)". Then select "EISA, VLB, PCI and on board controllers", and
+   choose "SiS 900/7016 PCI Fast Ethernet Adapter support" to "M".
+   
+   After reconfiguring the kernel, you can make the driver module by
+   
+make modules
+
+   The driver should be compiled with no errors. After compiling the
+   driver, the driver can be installed to proper place by
+   
+make modules_install
+
+   Load the driver into kernel by
+   
+insmod sis900
+
+   When loading the driver into memory, some information message can be
+   view by
+   
+dmesg
+
+   or
+cat /var/log/message
+
+   If the driver is loaded properly you will have messages similar to
+   this:
+   
+sis900.c: v1.07.06  11/07/2000
+eth0: SiS 900 PCI Fast Ethernet at 0xd000, IRQ 10, 00:00:e8:83:7f:a4.
+eth0: SiS 900 Internal MII PHY transceiver found at address 1.
+eth0: Using SiS 900 Internal MII PHY as default
+
+   showing the version of the driver and the results of probing routine.
+   
+   Once the driver is loaded, network can be brought up by
+   
+/sbin/ifconfig eth0 IPADDR broadcast BROADCAST netmask NETMASK media TYPE
+
+   where IPADDR, BROADCAST, NETMASK are your IP address, broadcast
+   address and netmask respectively. TYPE is used to set medium type used
+   by the device. Typical values are "10baseT"(twisted-pair 10Mbps
+   Ethernet) or "100baseT" (twisted-pair 100Mbps Ethernet). For more
+   information on how to configure network interface, please refer to
+   Networking HOWTO.
+   
+   The link status is also shown by kernel messages. For example, after
+   the network interface is activated, you may have the message:
+   
+eth0: Media Link On 100mbps full-duplex
+
+   If you try to unplug the twist pair (TP) cable you will get
+   
+eth0: Media Link Off
+
+   indicating that the link is failed.
+     _________________________________________________________________
+   
+Building the driver into kernel
+
+   If you want to make the driver into kernel, choose "Y" rather than "M"
+   on "SiS 900/7016 PCI Fast Ethernet Adapter support" when configuring
+   the kernel. Build the kernel image in the usual way
+   
+make clean
+
+make bzlilo
+
+   Next time the system reboot, you have the driver in memory.
+     _________________________________________________________________
+   
+Chapter 6. Known Problems and Bugs
+
+   There are some known problems and bugs. If you find any other bugs
+   please mail to lcchang@sis.com.tw
+   
+    1. AM79C901 HomePNA PHY is not thoroughly tested, there may be some
+       bugs in the "on the fly" change of transceiver.
+    2. A bug is hidden somewhere in the receive buffer management code,
+       the bug causes NULL pointer reference in the kernel. This fault is
+       caught before bad things happen and reported with the message:
+       eth0: NULL pointer encountered in Rx ring, skipping which can be
+       viewed with dmesg or cat /var/log/message.
+    3. The media type change from 10Mbps to 100Mbps twisted-pair ethernet
+       by ifconfig causes the media link down.
+     _________________________________________________________________
+   
+Chapter 7. Revision History
+
+     * November 13, 2000, Revision 1.07, seventh release, 630E problem
+       fixed and further clean up.
+     * November 4, 1999, Revision 1.06, Second release, lots of clean up
+       and optimization.
+     * August 8, 1999, Revision 1.05, Initial Public Release
+     _________________________________________________________________
+   
+Chapter 8. Acknowledgements
+
+   This driver was originally derived form Donald Becker's pci-skeleton
+   and rtl8139 drivers. Donald also provided various suggestion regarded
+   with improvements made in revision 1.06.
+   
+   The 1.05 revision was created by Jim Huang, AMD 79c901 support was
+   added by Chin-Shan Li.
diff --git a/Documentation/networking/sk98lin.txt b/Documentation/networking/sk98lin.txt
new file mode 100644
index 00000000000..851fc97bb22
--- /dev/null
+++ b/Documentation/networking/sk98lin.txt
@@ -0,0 +1,568 @@
+(C)Copyright 1999-2004 Marvell(R).
+All rights reserved
+===========================================================================
+
+sk98lin.txt created 13-Feb-2004
+
+Readme File for sk98lin v6.23
+Marvell Yukon/SysKonnect SK-98xx Gigabit Ethernet Adapter family driver for LINUX
+
+This file contains
+ 1  Overview
+ 2  Required Files
+ 3  Installation
+    3.1  Driver Installation
+    3.2  Inclusion of adapter at system start
+ 4  Driver Parameters
+    4.1  Per-Port Parameters
+    4.2  Adapter Parameters
+ 5  Large Frame Support
+ 6  VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
+ 7  Troubleshooting
+
+===========================================================================
+
+
+1  Overview
+===========
+
+The sk98lin driver supports the Marvell Yukon and SysKonnect 
+SK-98xx/SK-95xx compliant Gigabit Ethernet Adapter on Linux. It has 
+been tested with Linux on Intel/x86 machines.
+***
+
+
+2  Required Files
+=================
+
+The linux kernel source.
+No additional files required.
+***
+
+
+3  Installation
+===============
+
+It is recommended to download the latest version of the driver from the 
+SysKonnect web site www.syskonnect.com. If you have downloaded the latest
+driver, the Linux kernel has to be patched before the driver can be 
+installed. For details on how to patch a Linux kernel, refer to the 
+patch.txt file.
+
+3.1  Driver Installation
+------------------------
+
+The following steps describe the actions that are required to install
+the driver and to start it manually. These steps should be carried
+out for the initial driver setup. Once confirmed to be ok, they can
+be included in the system start.
+
+NOTE 1: To perform the following tasks you need 'root' access.
+
+NOTE 2: In case of problems, please read the section "Troubleshooting" 
+        below.
+
+The driver can either be integrated into the kernel or it can be compiled 
+as a module. Select the appropriate option during the kernel 
+configuration.
+
+Compile/use the driver as a module
+----------------------------------
+To compile the driver, go to the directory /usr/src/linux and
+execute the command "make menuconfig" or "make xconfig" and proceed as 
+follows:
+
+To integrate the driver permanently into the kernel, proceed as follows:
+
+1. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
+2. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support" 
+   with (*) 
+3. Build a new kernel when the configuration of the above options is 
+   finished.
+4. Install the new kernel.
+5. Reboot your system.
+
+To use the driver as a module, proceed as follows:
+
+1. Enable 'loadable module support' in the kernel.
+2. For automatic driver start, enable the 'Kernel module loader'.
+3. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
+4. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support" 
+   with (M)
+5. Execute the command "make modules".
+6. Execute the command "make modules_install".
+   The appropiate modules will be installed.
+7. Reboot your system.
+
+
+Load the module manually
+------------------------
+To load the module manually, proceed as follows:
+
+1. Enter "modprobe sk98lin".
+2. If a Marvell Yukon or SysKonnect SK-98xx adapter is installed in 
+   your computer and you have a /proc file system, execute the command:
+   "ls /proc/net/sk98lin/" 
+   This should produce an output containing a line with the following 
+   format:
+   eth0   eth1  ...
+   which indicates that your adapter has been found and initialized.
+   
+   NOTE 1: If you have more than one Marvell Yukon or SysKonnect SK-98xx 
+           adapter installed, the adapters will be listed as 'eth0', 
+                   'eth1', 'eth2', etc.
+                   For each adapter, repeat steps 3 and 4 below.
+
+   NOTE 2: If you have other Ethernet adapters installed, your Marvell
+           Yukon or SysKonnect SK-98xx adapter will be mapped to the 
+                   next available number, e.g. 'eth1'. The mapping is executed 
+                   automatically.
+           The module installation message (displayed either in a system
+           log file or on the console) prints a line for each adapter 
+           found containing the corresponding 'ethX'.
+
+3. Select an IP address and assign it to the respective adapter by 
+   entering:
+   ifconfig eth0 <ip-address>
+   With this command, the adapter is connected to the Ethernet. 
+   
+   SK-98xx Gigabit Ethernet Server Adapters: The yellow LED on the adapter 
+   is now active, the link status LED of the primary port is active and 
+   the link status LED of the secondary port (on dual port adapters) is 
+   blinking (if the ports are connected to a switch or hub).
+   SK-98xx V2.0 Gigabit Ethernet Adapters: The link status LED is active.
+   In addition, you will receive a status message on the console stating
+   "ethX: network connection up using port Y" and showing the selected 
+   connection parameters (x stands for the ethernet device number 
+   (0,1,2, etc), y stands for the port name (A or B)).
+
+   NOTE: If you are in doubt about IP addresses, ask your network
+         administrator for assistance.
+  
+4. Your adapter should now be fully operational.
+   Use 'ping <otherstation>' to verify the connection to other computers 
+   on your network.
+5. To check the adapter configuration view /proc/net/sk98lin/[devicename].
+   For example by executing:    
+   "cat /proc/net/sk98lin/eth0" 
+
+Unload the module
+-----------------
+To stop and unload the driver modules, proceed as follows:
+
+1. Execute the command "ifconfig eth0 down".
+2. Execute the command "rmmod sk98lin".
+
+3.2  Inclusion of adapter at system start
+-----------------------------------------
+
+Since a large number of different Linux distributions are 
+available, we are unable to describe a general installation procedure
+for the driver module.
+Because the driver is now integrated in the kernel, installation should
+be easy, using the standard mechanism of your distribution.
+Refer to the distribution's manual for installation of ethernet adapters.
+
+***
+
+4  Driver Parameters
+====================
+
+Parameters can be set at the command line after the module has been 
+loaded with the command 'modprobe'.
+In some distributions, the configuration tools are able to pass parameters
+to the driver module.
+
+If you use the kernel module loader, you can set driver parameters
+in the file /etc/modprobe.conf (or /etc/modules.conf in 2.4 or earlier).
+To set the driver parameters in this file, proceed as follows:
+
+1. Insert a line of the form :
+   options sk98lin ...
+   For "...", the same syntax is required as described for the command
+   line paramaters of modprobe below.
+2. To activate the new parameters, either reboot your computer
+   or 
+   unload and reload the driver.
+   The syntax of the driver parameters is:
+
+        modprobe sk98lin parameter=value1[,value2[,value3...]]
+
+   where value1 refers to the first adapter, value2 to the second etc.
+
+NOTE: All parameters are case sensitive. Write them exactly as shown 
+      below.
+
+Example:
+Suppose you have two adapters. You want to set auto-negotiation
+on the first adapter to ON and on the second adapter to OFF.
+You also want to set DuplexCapabilities on the first adapter
+to FULL, and on the second adapter to HALF.
+Then, you must enter:
+
+        modprobe sk98lin AutoNeg_A=On,Off DupCap_A=Full,Half
+
+NOTE: The number of adapters that can be configured this way is
+      limited in the driver (file skge.c, constant SK_MAX_CARD_PARAM).
+      The current limit is 16. If you happen to install
+      more adapters, adjust this and recompile.
+
+
+4.1  Per-Port Parameters
+------------------------
+
+These settings are available for each port on the adapter.
+In the following description, '?' stands for the port for
+which you set the parameter (A or B).
+
+Speed
+-----
+Parameter:    Speed_?
+Values:       10, 100, 1000, Auto
+Default:      Auto
+
+This parameter is used to set the speed capabilities. It is only valid 
+for the SK-98xx V2.0 copper adapters.
+Usually, the speed is negotiated between the two ports during link 
+establishment. If this fails, a port can be forced to a specific setting
+with this parameter.
+
+Auto-Negotiation
+----------------
+Parameter:    AutoNeg_?
+Values:       On, Off, Sense
+Default:      On
+  
+The "Sense"-mode automatically detects whether the link partner supports
+auto-negotiation or not.
+
+Duplex Capabilities
+-------------------
+Parameter:    DupCap_?
+Values:       Half, Full, Both
+Default:      Both
+
+This parameters is only relevant if auto-negotiation for this port is 
+not set to "Sense". If auto-negotiation is set to "On", all three values
+are possible. If it is set to "Off", only "Full" and "Half" are allowed.
+This parameter is usefull if your link partner does not support all
+possible combinations.
+
+Flow Control
+------------
+Parameter:    FlowCtrl_?
+Values:       Sym, SymOrRem, LocSend, None
+Default:      SymOrRem
+
+This parameter can be used to set the flow control capabilities the 
+port reports during auto-negotiation. It can be set for each port 
+individually.
+Possible modes:
+   -- Sym      = Symmetric: both link partners are allowed to send 
+                  PAUSE frames
+   -- SymOrRem = SymmetricOrRemote: both or only remote partner 
+                  are allowed to send PAUSE frames
+   -- LocSend  = LocalSend: only local link partner is allowed 
+                  to send PAUSE frames
+   -- None     = no link partner is allowed to send PAUSE frames
+  
+NOTE: This parameter is ignored if auto-negotiation is set to "Off".
+
+Role in Master-Slave-Negotiation (1000Base-T only)
+--------------------------------------------------
+Parameter:    Role_?
+Values:       Auto, Master, Slave
+Default:      Auto
+
+This parameter is only valid for the SK-9821 and SK-9822 adapters.
+For two 1000Base-T ports to communicate, one must take the role of the
+master (providing timing information), while the other must be the 
+slave. Usually, this is negotiated between the two ports during link 
+establishment. If this fails, a port can be forced to a specific setting
+with this parameter.
+
+
+4.2  Adapter Parameters
+-----------------------
+
+Connection Type (SK-98xx V2.0 copper adapters only)
+---------------
+Parameter:    ConType
+Values:       Auto, 100FD, 100HD, 10FD, 10HD
+Default:      Auto
+
+The parameter 'ConType' is a combination of all five per-port parameters
+within one single parameter. This simplifies the configuration of both ports
+of an adapter card! The different values of this variable reflect the most 
+meaningful combinations of port parameters.
+
+The following table shows the values of 'ConType' and the corresponding
+combinations of the per-port parameters:
+
+    ConType   |  DupCap   AutoNeg   FlowCtrl   Role             Speed
+    ----------+------------------------------------------------------
+    Auto      |  Both     On        SymOrRem   Auto             Auto
+    100FD     |  Full     Off       None       Auto (ignored)   100
+    100HD     |  Half     Off       None       Auto (ignored)   100
+    10FD      |  Full     Off       None       Auto (ignored)   10
+    10HD      |  Half     Off       None       Auto (ignored)   10
+
+Stating any other port parameter together with this 'ConType' variable
+will result in a merged configuration of those settings. This due to 
+the fact, that the per-port parameters (e.g. Speed_? ) have a higher
+priority than the combined variable 'ConType'.
+
+NOTE: This parameter is always used on both ports of the adapter card.
+
+Interrupt Moderation
+--------------------
+Parameter:    Moderation
+Values:       None, Static, Dynamic
+Default:      None
+
+Interrupt moderation is employed to limit the maxmimum number of interrupts
+the driver has to serve. That is, one or more interrupts (which indicate any
+transmit or receive packet to be processed) are queued until the driver 
+processes them. When queued interrupts are to be served, is determined by the
+'IntsPerSec' parameter, which is explained later below.
+
+Possible modes:
+
+   -- None - No interrupt moderation is applied on the adapter card. 
+      Therefore, each transmit or receive interrupt is served immediately
+      as soon as it appears on the interrupt line of the adapter card.
+
+   -- Static - Interrupt moderation is applied on the adapter card. 
+      All transmit and receive interrupts are queued until a complete
+      moderation interval ends. If such a moderation interval ends, all
+      queued interrupts are processed in one big bunch without any delay.
+      The term 'static' reflects the fact, that interrupt moderation is
+      always enabled, regardless how much network load is currently 
+      passing via a particular interface. In addition, the duration of
+      the moderation interval has a fixed length that never changes while
+      the driver is operational.
+
+   -- Dynamic - Interrupt moderation might be applied on the adapter card,
+      depending on the load of the system. If the driver detects that the
+      system load is too high, the driver tries to shield the system against 
+      too much network load by enabling interrupt moderation. If - at a later
+      time - the CPU utilizaton decreases again (or if the network load is 
+      negligible) the interrupt moderation will automatically be disabled.
+
+Interrupt moderation should be used when the driver has to handle one or more
+interfaces with a high network load, which - as a consequence - leads also to a
+high CPU utilization. When moderation is applied in such high network load 
+situations, CPU load might be reduced by 20-30%.
+
+NOTE: The drawback of using interrupt moderation is an increase of the round-
+trip-time (RTT), due to the queueing and serving of interrupts at dedicated
+moderation times.
+
+Interrupts per second
+---------------------
+Parameter:    IntsPerSec
+Values:       30...40000 (interrupts per second)
+Default:      2000
+
+This parameter is only used, if either static or dynamic interrupt moderation
+is used on a network adapter card. Using this paramter if no moderation is
+applied, will lead to no action performed.
+
+This parameter determines the length of any interrupt moderation interval. 
+Assuming that static interrupt moderation is to be used, an 'IntsPerSec' 
+parameter value of 2000 will lead to an interrupt moderation interval of
+500 microseconds. 
+
+NOTE: The duration of the moderation interval is to be chosen with care.
+At first glance, selecting a very long duration (e.g. only 100 interrupts per 
+second) seems to be meaningful, but the increase of packet-processing delay 
+is tremendous. On the other hand, selecting a very short moderation time might
+compensate the use of any moderation being applied.
+
+
+Preferred Port
+--------------
+Parameter:    PrefPort
+Values:       A, B
+Default:      A
+
+This is used to force the preferred port to A or B (on dual-port network 
+adapters). The preferred port is the one that is used if both are detected
+as fully functional.
+
+RLMT Mode (Redundant Link Management Technology)
+------------------------------------------------
+Parameter:    RlmtMode
+Values:       CheckLinkState,CheckLocalPort, CheckSeg, DualNet
+Default:      CheckLinkState
+
+RLMT monitors the status of the port. If the link of the active port 
+fails, RLMT switches immediately to the standby link. The virtual link is 
+maintained as long as at least one 'physical' link is up. 
+
+Possible modes:
+
+   -- CheckLinkState - Check link state only: RLMT uses the link state
+      reported by the adapter hardware for each individual port to 
+      determine whether a port can be used for all network traffic or 
+      not.
+
+   -- CheckLocalPort - In this mode, RLMT monitors the network path 
+      between the two ports of an adapter by regularly exchanging packets
+      between them. This mode requires a network configuration in which 
+      the two ports are able to "see" each other (i.e. there must not be 
+      any router between the ports).
+
+   -- CheckSeg - Check local port and segmentation: This mode supports the
+      same functions as the CheckLocalPort mode and additionally checks 
+      network segmentation between the ports. Therefore, this mode is only
+      to be used if Gigabit Ethernet switches are installed on the network
+      that have been configured to use the Spanning Tree protocol. 
+
+   -- DualNet - In this mode, ports A and B are used as separate devices. 
+      If you have a dual port adapter, port A will be configured as eth0 
+      and port B as eth1. Both ports can be used independently with 
+      distinct IP addresses. The preferred port setting is not used. 
+      RLMT is turned off.
+   
+NOTE: RLMT modes CLP and CLPSS are designed to operate in configurations 
+      where a network path between the ports on one adapter exists. 
+      Moreover, they are not designed to work where adapters are connected
+      back-to-back.
+***
+
+
+5  Large Frame Support
+======================
+
+The driver supports large frames (also called jumbo frames). Using large 
+frames can result in an improved throughput if transferring large amounts 
+of data.
+To enable large frames, set the MTU (maximum transfer unit) of the 
+interface to the desired value (up to 9000), execute the following 
+command:
+      ifconfig eth0 mtu 9000
+This will only work if you have two adapters connected back-to-back
+or if you use a switch that supports large frames. When using a switch, 
+it should be configured to allow large frames and auto-negotiation should  
+be set to OFF. The setting must be configured on all adapters that can be 
+reached by the large frames. If one adapter is not set to receive large 
+frames, it will simply drop them.
+
+You can switch back to the standard ethernet frame size by executing the 
+following command:
+      ifconfig eth0 mtu 1500
+
+To permanently configure this setting, add a script with the 'ifconfig' 
+line to the system startup sequence (named something like "S99sk98lin" 
+in /etc/rc.d/rc2.d).
+***
+
+
+6  VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
+==================================================================
+
+The Marvell Yukon/SysKonnect Linux drivers are able to support VLAN and 
+Link Aggregation according to IEEE standards 802.1, 802.1q, and 802.3ad. 
+These features are only available after installation of open source 
+modules available on the Internet:
+For VLAN go to: http://www.candelatech.com/~greear/vlan.html
+For Link Aggregation go to: http://www.st.rim.or.jp/~yumo
+
+NOTE: SysKonnect GmbH does not offer any support for these open source 
+      modules and does not take the responsibility for any kind of 
+      failures or problems arising in connection with these modules.
+
+NOTE: Configuring Link Aggregation on a SysKonnect dual link adapter may 
+      cause problems when unloading the driver.
+
+
+7  Troubleshooting
+==================
+
+If any problems occur during the installation process, check the 
+following list:
+
+
+Problem:  The SK-98xx adapter can not be found by the driver.
+Solution: In /proc/pci search for the following entry:
+             'Ethernet controller: SysKonnect SK-98xx ...'
+          If this entry exists, the SK-98xx or SK-98xx V2.0 adapter has 
+          been found by the system and should be operational.
+          If this entry does not exist or if the file '/proc/pci' is not 
+          found, there may be a hardware problem or the PCI support may 
+          not be enabled in your kernel.
+          The adapter can be checked using the diagnostics program which 
+          is available on the SysKonnect web site:
+          www.syskonnect.com
+          
+          Some COMPAQ machines have problems dealing with PCI under Linux.
+          Linux. This problem is described in the 'PCI howto' document
+          (included in some distributions or available from the
+          web, e.g. at 'www.linux.org'). 
+
+
+Problem:  Programs such as 'ifconfig' or 'route' can not be found or the 
+          error message 'Operation not permitted' is displayed.
+Reason:   You are not logged in as user 'root'.
+Solution: Logout and login as 'root' or change to 'root' via 'su'.
+
+
+Problem:  Upon use of the command 'ping <address>' the message
+          "ping: sendto: Network is unreachable" is displayed.
+Reason:   Your route is not set correctly.
+Solution: If you are using RedHat, you probably forgot to set up the 
+          route in the 'network configuration'.
+          Check the existing routes with the 'route' command and check 
+          if an entry for 'eth0' exists, and if so, if it is set correctly.
+
+
+Problem:  The driver can be started, the adapter is connected to the 
+          network, but you cannot receive or transmit any packets; 
+          e.g. 'ping' does not work.
+Reason:   There is an incorrect route in your routing table.
+Solution: Check the routing table with the command 'route' and read the 
+          manual help pages dealing with routes (enter 'man route').
+
+NOTE: Although the 2.2.x kernel versions generate the routing entry 
+      automatically, problems of this kind may occur here as well. We've 
+      come across a situation in which the driver started correctly at 
+      system start, but after the driver has been removed and reloaded,
+      the route of the adapter's network pointed to the 'dummy0'device 
+      and had to be corrected manually.
+
+
+Problem:  Your computer should act as a router between multiple 
+          IP subnetworks (using multiple adapters), but computers in 
+          other subnetworks cannot be reached.
+Reason:   Either the router's kernel is not configured for IP forwarding 
+          or the routing table and gateway configuration of at least one 
+          computer is not working.
+
+Problem:  Upon driver start, the following error message is displayed:
+          "eth0: -- ERROR --
+          Class: internal Software error
+          Nr:    0xcc
+          Msg:   SkGeInitPort() cannot init running ports"
+Reason:   You are using a driver compiled for single processor machines 
+          on a multiprocessor machine with SMP (Symmetric MultiProcessor) 
+          kernel.
+Solution: Configure your kernel appropriately and recompile the kernel or
+          the modules.
+
+
+
+If your problem is not listed here, please contact SysKonnect's technical
+support for help (linux@syskonnect.de).
+When contacting our technical support, please ensure that the following 
+information is available:
+- System Manufacturer and HW Informations (CPU, Memory... )
+- PCI-Boards in your system
+- Distribution
+- Kernel version
+- Driver version
+***
+
+
+
+***End of Readme File***
diff --git a/Documentation/networking/skfp.txt b/Documentation/networking/skfp.txt
new file mode 100644
index 00000000000..3a419ed42f8
--- /dev/null
+++ b/Documentation/networking/skfp.txt
@@ -0,0 +1,220 @@
+(C)Copyright 1998-2000 SysKonnect,
+===========================================================================
+
+skfp.txt created 11-May-2000
+
+Readme File for skfp.o v2.06
+
+
+This file contains
+(1) OVERVIEW
+(2) SUPPORTED ADAPTERS
+(3) GENERAL INFORMATION
+(4) INSTALLATION
+(5) INCLUSION OF THE ADAPTER IN SYSTEM START
+(6) TROUBLESHOOTING
+(7) FUNCTION OF THE ADAPTER LEDS
+(8) HISTORY
+
+===========================================================================
+
+
+
+(1) OVERVIEW
+============
+
+This README explains how to use the driver 'skfp' for Linux with your
+network adapter.
+
+Chapter 2: Contains a list of all network adapters that are supported by
+           this driver.
+
+Chapter 3: Gives some general information.
+
+Chapter 4: Describes common problems and solutions.
+
+Chapter 5: Shows the changed functionality of the adapter LEDs.
+
+Chapter 6: History of development.
+
+***
+
+
+(2) SUPPORTED ADAPTERS
+======================
+
+The network driver 'skfp' supports the following network adapters:
+SysKonnect adapters:
+  - SK-5521 (SK-NET FDDI-UP)
+  - SK-5522 (SK-NET FDDI-UP DAS)
+  - SK-5541 (SK-NET FDDI-FP)
+  - SK-5543 (SK-NET FDDI-LP)
+  - SK-5544 (SK-NET FDDI-LP DAS)
+  - SK-5821 (SK-NET FDDI-UP64)
+  - SK-5822 (SK-NET FDDI-UP64 DAS)
+  - SK-5841 (SK-NET FDDI-FP64)
+  - SK-5843 (SK-NET FDDI-LP64)
+  - SK-5844 (SK-NET FDDI-LP64 DAS)
+Compaq adapters (not tested):
+  - Netelligent 100 FDDI DAS Fibre SC
+  - Netelligent 100 FDDI SAS Fibre SC
+  - Netelligent 100 FDDI DAS UTP
+  - Netelligent 100 FDDI SAS UTP
+  - Netelligent 100 FDDI SAS Fibre MIC
+***
+
+
+(3) GENERAL INFORMATION
+=======================
+
+From v2.01 on, the driver is integrated in the linux kernel sources.
+Therefor, the installation is the same as for any other adapter
+supported by the kernel.
+Refer to the manual of your distribution about the installation
+of network adapters.
+Makes my life much easier :-)
+***
+
+
+(4) TROUBLESHOOTING
+===================
+
+If you run into problems during installation, check those items:
+
+Problem:  The FDDI adapter can not be found by the driver.
+Reason:   Look in /proc/pci for the following entry:
+             'FDDI network controller: SysKonnect SK-FDDI-PCI ...'
+          If this entry exists, then the FDDI adapter has been
+          found by the system and should be able to be used.
+          If this entry does not exist or if the file '/proc/pci'
+          is not there, then you may have a hardware problem or PCI
+          support may not be enabled in your kernel.
+          The adapter can be checked using the diagnostic program
+          which is available from the SysKonnect web site:
+              www.syskonnect.de
+          Some COMPAQ machines have a problem with PCI under
+          Linux. This is described in the 'PCI howto' document
+          (included in some distributions or available from the
+          www, e.g. at 'www.linux.org') and no workaround is available.
+
+Problem:  You want to use your computer as a router between
+          multiple IP subnetworks (using multiple adapters), but
+          you can not reach computers in other subnetworks.
+Reason:   Either the router's kernel is not configured for IP
+          forwarding or there is a problem with the routing table
+          and gateway configuration in at least one of the
+          computers.
+
+If your problem is not listed here, please contact our
+technical support for help. 
+You can send email to:
+  linux@syskonnect.de
+When contacting our technical support,
+please ensure that the following information is available:
+- System Manufacturer and Model
+- Boards in your system
+- Distribution
+- Kernel version
+
+***
+
+
+(5) FUNCTION OF THE ADAPTER LEDS
+================================
+
+        The functionality of the LED's on the FDDI network adapters was
+        changed in SMT version v2.82. With this new SMT version, the yellow
+        LED works as a ring operational indicator. An active yellow LED
+        indicates that the ring is down. The green LED on the adapter now
+        works as a link indicator where an active GREEN LED indicates that
+        the respective port has a physical connection.
+
+        With versions of SMT prior to v2.82 a ring up was indicated if the
+        yellow LED was off while the green LED(s) showed the connection
+        status of the adapter. During a ring down the green LED was off and
+        the yellow LED was on.
+
+        All implementations indicate that a driver is not loaded if
+        all LEDs are off.
+
+***
+
+
+(6) HISTORY
+===========
+
+v2.06 (20000511) (In-Kernel version)
+    New features:
+        - 64 bit support
+        - new pci dma interface
+        - in kernel 2.3.99
+
+v2.05 (20000217) (In-Kernel version)
+    New features:
+        - Changes for 2.3.45 kernel
+
+v2.04 (20000207) (Standalone version)
+    New features:
+        - Added rx/tx byte counter
+
+v2.03 (20000111) (Standalone version)
+    Problems fixed:
+        - Fixed printk statements from v2.02
+
+v2.02 (991215) (Standalone version)
+    Problems fixed:
+        - Removed unnecessary output
+        - Fixed path for "printver.sh" in makefile
+
+v2.01 (991122) (In-Kernel version)
+    New features:
+        - Integration in Linux kernel sources
+        - Support for memory mapped I/O.
+
+v2.00 (991112)
+    New features:
+        - Full source released under GPL
+
+v1.05 (991023)
+    Problems fixed:
+        - Compilation with kernel version 2.2.13 failed
+
+v1.04 (990427)
+    Changes:
+        - New SMT module included, changing LED functionality
+    Problems fixed:
+        - Synchronization on SMP machines was buggy
+
+v1.03 (990325)
+    Problems fixed:
+        - Interrupt routing on SMP machines could be incorrect
+
+v1.02 (990310)
+    New features:
+        - Support for kernel versions 2.2.x added
+        - Kernel patch instead of private duplicate of kernel functions
+
+v1.01 (980812)
+    Problems fixed:
+        Connection hangup with telnet
+        Slow telnet connection
+
+v1.00 beta 01 (980507)
+    New features:
+        None.
+    Problems fixed:
+        None.
+    Known limitations:
+        - tar archive instead of standard package format (rpm).
+        - FDDI statistic is empty.
+        - not tested with 2.1.xx kernels
+        - integration in kernel not tested
+        - not tested simultaneously with FDDI adapters from other vendors.
+        - only X86 processors supported.
+        - SBA (Synchronous Bandwidth Allocator) parameters can
+          not be configured.
+        - does not work on some COMPAQ machines. See the PCI howto
+          document for details about this problem.
+        - data corruption with kernel versions below 2.0.33.
+
+*** End of information file ***
diff --git a/Documentation/networking/slicecom.hun b/Documentation/networking/slicecom.hun
new file mode 100644
index 00000000000..5acf1918694
--- /dev/null
+++ b/Documentation/networking/slicecom.hun
@@ -0,0 +1,371 @@
+
+SliceCOM adapter felhasznaloi dokumentacioja - 0.51 verziohoz
+
+Bartók István <bartoki@itc.hu>
+Utolso modositas: Wed Aug 29 17:26:58 CEST 2001
+
+-----------------------------------------------------------------
+
+Hasznalata:
+
+Forditas:
+
+Code maturity level options
+        [*] Prompt for development and/or incomplete code/drivers
+
+Network device support
+        Wan interfaces
+                <M> MultiGate (COMX) synchronous
+                        <M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
+                        <M> Support for HDLC and syncPPP...
+
+
+A modulok betoltese:
+
+modprobe comx
+
+modprobe comx-proto-ppp         # a Cisco-HDLC es a SyncPPP protokollt is
+                                # ez a modul adja
+
+modprobe comx-hw-munich         # a modul betoltodeskor azonnal jelent a
+                                # syslogba a detektalt kartyakrol
+
+
+Konfiguralas:
+
+# Ezen az interfeszen Cisco-HDLC vonali protokoll fog futni
+# Az interfeszhez rendelt idoszeletek: 1,2 (128 kbit/sec-es vonal)
+# (a G.703 keretben az elso adatot vivo idoszelet az 1-es)
+#
+mkdir /proc/comx/comx0.1/
+echo slicecom   >/proc/comx/comx0.1/boardtype
+echo hdlc       >/proc/comx/comx0.1/protocol
+echo 1 2        >/proc/comx/comx0.1/timeslots
+
+
+# Ezen az interfeszen SyncPPP vonali protokoll fog futni
+# Az interfeszhez rendelt idoszelet: 3 (64 kbit/sec-es vonal)
+#
+mkdir /proc/comx/comx0.2/
+echo slicecom   >/proc/comx/comx0.2/boardtype
+echo ppp        >/proc/comx/comx0.2/protocol
+echo 3          >/proc/comx/comx0.2/timeslots
+
+...
+
+ifconfig comx0.1 up
+ifconfig comx0.2 up
+
+-----------------------------------------------------------------
+
+A COMX driverek default 20 csomagnyi transmit queue-t rendelnek a halozati
+interfeszekhez. WAN halozatokban ennel hosszabbat is szokas hasznalni
+(20 es 100 kozott), hogy a vonal kihasznaltsaga nagy terheles eseten jobb
+legyen (bar ezzel megno a varhato kesleltetes a csomagok sorban allasa miatt):
+
+# ifconfig comx0 txqueuelen 50
+
+Ezt a beallitasi lehetoseget csak az ujabb disztribuciok ifconfig parancsa
+tamogatja (amik mar a 2.2 kernelekhez keszultek, mint a RedHat 6.1 vagy a
+Debian 2.2).
+
+A 2.1-es Debian disztribuciohoz a http://www.debian.org/~rcw/2.2/netbase/
+cimrol toltheto le ujabb netbase csomag, ami mar ilyet tamogato ifconfig
+parancsot tartalmaz. Bovebben a 2.2 kernel hasznalatarol Debian 2.1 alatt:
+http://www.debian.org/releases/stable/running-kernel-2.2
+
+-----------------------------------------------------------------
+
+A kartya LED-jeinek jelentese:
+
+piros   - eg, ha Remote Alarm-ot kuld a tuloldal
+zold    - eg, ha a vett jelben megtalalja a keretszinkront
+
+Reszletesebben:
+
+piros:  zold:   jelentes:
+
+-       -       nincs keretszinkron (nincs jel, vagy rossz a jel)
+-       eg      "minden rendben"
+eg      eg      a vetel OK, de a tuloldal Remote Alarm-ot kuld
+eg      -       ez nincs ertelmezve, egyelore funkcio nelkul
+
+-----------------------------------------------------------------
+
+Reszletesebb leiras a hardver beallitasi lehetosegeirol:
+
+Az altalanos,- es a protokoll-retegek beallitasi lehetosegeirol a 'comx.txt'
+fajlban leirtak SliceCOM kartyanal is ervenyesek, itt csak a hardver-specifikus
+beallitasi lehetosegek vannak osszefoglalva:
+
+Konfiguralasi interfesz a /proc/comx/ alatt:
+
+Minden timeslot-csoportnak kulon comx* interfeszt kell letrehozni mkdir-rel:
+comx0, comx1, .. stb. Itt beallithato, hogy az adott interfesz hanyadik kartya
+melyik timeslotja(i)bol alljon ossze. A Cisco-fele serial3:1 elnevezesek
+(serial3:1 = a 3. kartyaban az 1-es idoszelet-csoport) Linuxon aliasing-ot
+jelentenenek, ezert mi nem tudunk ilyen elnevezest hasznalni.
+
+Tobb kartya eseten a comx0.1, comx0.2, ... vagy slice0.1, slice0.2 nevek
+hasznalhatoak.
+
+Tobb SliceCOM kartya is lehet egy gepben, de sajat interrupt kell mindegyiknek,
+nem tud meg megosztott interruptot kezelni.
+
+Az egesz kartyat erinto beallitasok:
+
+Az ioport es irq beallitas nincs: amit a PCI BIOS kioszt a rendszernek,
+azt hasznalja a driver.
+
+
+comx0/boardnum  - hanyadik SliceCOM kartya a gepben (a 'termeszetes' PCI
+                sorrendben ertve: ahogyan a /proc/pci-ban vagy az 'lspci'
+                kimeneteben megjelenik, altalaban az alaplapi PCI meghajto
+                aramkorokhoz kozelebb eso kartyak a kisebb sorszamuak)
+
+                Default: 0 (0-tol kezdodik a szamolas)
+
+
+Bar a kovetkezoket csak egy-egy interfeszen allitjuk at, megis az egesz kartya
+mukodeset egyszerre allitjak. A megkotes hogy csak UP-ban levo interfeszen
+hasznalhatoak, azert van, mert kulonben nem vart eredmenyekre vezetne egy ilyen
+paranccsorozat:
+
+        echo 0        >boardnum
+        echo internal >clock_source
+        echo 1        >boardnum
+
+- Ez a 0-s board clock_source-at allitana at.
+
+Ezek a beallitasok megmaradnak az osszes interfesz torlesekor, de torlodnek
+a driver modul ki/betoltesekor.
+
+
+comx0/clock_source - A Tx orajelforrasa, a Cisco-val hasonlatosra keszult.
+        Hasznalata:
+
+        papaya:# echo line     >/proc/comx/comx0/clock_source
+        papaya:# echo internal >/proc/comx/comx0/clock_source
+
+        line     - A Tx orajelet a vett adatfolyambol dekodolja, igyekszik
+                igazodni hozza. Ha nem lat orajelet az inputon, akkor
+                atall a sajat orajelgeneratorara.
+        internal - A Tx orajelet a sajat orajelgeneratora szolgaltatja.
+
+        Default: line
+
+        Normal osszeallitas eseten a tavkozlesi szolgaltato eszkoze
+        (pl. HDSL modem) adja az orajelet, ezert ez a default.
+
+
+comx0/framing   - A CRC4 ki/be kapcsolasa
+
+        A CRC4: 16 PCM keretet (A PCM keret az, amibe a 32 darab 64
+        kilobites csatorna van bemultiplexalva. Nem osszetevesztendo a HDLC
+        kerettel.) 2x8 -as csoportokra osztanak, es azokhoz 4-4 bites CRC-t
+        szamolnak. Elsosorban a vonal minosegenek a monitorozasara szolgal.
+
+        papaya:~# echo crc4     >/proc/comx/comx0/framing
+        papaya:~# echo no-crc4  >/proc/comx/comx0/framing
+
+        Default a 'crc4', a MATAV vonalak altalaban igy futnak. De ha nem
+        egyforma is a beallitas a vonal ket vegen, attol a forgalom altalaban
+        at tud menni.
+
+
+comx0/linecode  - A vonali kodolas beallitasa
+
+        papaya:~# echo hdb3     >/proc/comx/comx0/linecode
+        papaya:~# echo ami      >/proc/comx/comx0/linecode
+
+        Default a 'hdb3', a MATAV vonalak igy futnak.
+        
+        (az AMI kodolas igen ritka E1-es vonalaknal). Ha ez a beallitas nem
+        egyezik a vonal ket vegen, akkor elofordulhat hogy a keretszinkron
+        osszejon, de CRC4-hibak es a vonalakon atvitt adatokban is hibak
+        keletkeznek (amit a HDLC/SyncPPP szinten CRC-hibaval jelez)
+
+
+comx0/reg       - a kartya aramkoreinek, a MUNICH (reg) es a FALC (lbireg)
+comx0/lbireg    regisztereinek kozvetlen elerese. Hasznalata:
+
+                echo >reg 0x04 0x0      - a 4-es regiszterbe 0-t ir
+                echo >reg 0x104         - printk()-val kiirja a 4-es regiszter
+                                        tartalmat a syslogba.
+
+                WARNING: ezek csak a fejleszteshez keszultek, sok galibat
+                lehet veluk okozni!
+
+
+comx0/loopback - A kartya G.703 jelenek a visszahurkolasara is van lehetoseg:
+
+        papaya:# echo none   >/proc/comx/comx0/loopback
+        papaya:# echo local  >/proc/comx/comx0/loopback
+        papaya:# echo remote >/proc/comx/comx0/loopback
+
+        none   - nincs visszahurkolas, normal mukodes
+        local  - a kartya a sajat maga altal adott jelet kapja vissza
+        remote - a kartya a kivulrol vett jelet adja kifele
+
+        Default: none
+
+-----------------------------------------------------------------
+
+Az interfeszhez (Cisco terminologiaban 'channel-group') kapcsolodo beallitasok:
+
+comx0/timeslots - mely timeslotok (idoszeletek) tartoznak az adott interfeszhez.
+
+        papaya:~# cat /proc/comx/comx0/timeslots
+        1 3 4 5 6
+        papaya:~#
+
+        Egy timeslot megkeresese (hanyas interfeszbe tartozik nalunk):
+
+        papaya:~# grep ' 4' /proc/comx/comx*/timeslots
+        /proc/comx/comx0/timeslots:1 3 4 5 6
+        papaya:~#
+
+        Beallitasa:
+        papaya:~# echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
+        
+        A timeslotok sorrendje nem szamit, '1 3 2' ugyanaz mint az '1 2 3'.
+
+        Beallitashoz az adott interfesznek DOWN-ban kell lennie
+        (ifconfig comx0 down), de ugyanannak a kartyanak a tobbi interfesze
+        uzemelhet kozben.
+
+        Beallitaskor leellenorzi, hogy az uj timeslotok nem utkoznek-e egy
+        masik interfesz timeslotjaival. Ha utkoznek, akkor nem allitja at.
+
+        Mindig 10-es szamrendszerben tortenik a timeslotok ertelmezese, nehogy
+        a 08, 09 alaku felirast rosszul ertelmezze.
+
+-----------------------------------------------------------------
+
+Az interfeszek es a kartya allapotanak lekerdezese:
+
+- A ' '-szel kezdodo sorok az eredeti kimenetet, a //-rel kezdodo sorok a
+magyarazatot jelzik.
+
+ papaya:~$ cat /proc/comx/comx1/status
+ Interface administrative status is UP, modem status is UP, protocol is UP
+ Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
+ Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
+               (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
+ Debug flags: none
+ RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
+            buffer overrun: 0, pbuffer overrun: 0
+ TX errors: underrun: 0
+ Line keepalive (value: 10) status UP [0]
+
+// Itt kezdodik a hardver-specifikus resz:
+ Controller status:
+         No alarms
+
+// Alarm: hibajelzes:
+//
+// No alarms - minden rendben
+//
+// LOS  - Loss Of Signal - nem erzekel jelet a bemeneten.
+// AIS  - Alarm Indication Signal - csak egymas utani 1-esek jonnek
+//      a bemeneten, a tuloldal igy is jelezheti hogy meghibasodott vagy
+//      nincs inicializalva.
+// AUXP - Auxiliary Pattern Indication - 01010101.. sorozat jon a bemeneten.
+// LFA  - Loss of Frame Alignment - nincs keretszinkron
+// RRA  - Receive Remote Alarm - a tuloldal el, de hibat jelez.
+// LMFA - Loss of CRC4 Multiframe Alignment - nincs CRC4-multikeret-szinkron
+// NMF  - No Multiframe alignment Found after 400 msec - ilyen alarm a no-crc4
+//      es crc4 keretezesek eseten nincs, lasd lentebb
+//
+// Egyeb lehetseges hibajelzesek:
+//
+// Transmit Line Short - a kartya ugy erzi hogy az adasi kimenete rovidre
+//      van zarva, ezert kikapcsolta az adast. (nem feltetlenul veszi eszre
+//      a kulso rovidzarat)
+
+// A veteli oldal csomagjainak lancolt listai, debug celokra:
+
+ Rx ring:
+         rafutott: 0
+         lastcheck: 50845731, jiffies: 51314281
+         base: 017b1858
+         rx_desc_ptr: 0
+         rx_desc_ptr: 017b1858
+         hw_curr_ptr: 017b1858
+         06040000 017b1868 017b1898 c016ff00
+         06040000 017b1878 017b1e9c c016ff00
+         46040000 017b1888 017b24a0 c016ff00
+         06040000 017b1858 017b2aa4 c016ff00
+
+// A kartyat hasznalo tobbi interfesz: a 0-s channel-group a comx1 interfesz,
+// es az 1,2,...,16 timeslotok tartoznak hozza:
+
+ Interfaces using this board: (channel-group, interface, timeslots)
+          0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+          1 comx2: 17
+          2 comx3: 18
+          3 comx4: 19
+          4 comx5: 20
+          5 comx6: 21
+          6 comx7: 22
+          7 comx8: 23
+          8 comx9: 24
+          9 comx10: 25
+         10 comx11: 26
+         11 comx12: 27
+         12 comx13: 28
+         13 comx14: 29
+         14 comx15: 30
+         15 comx16: 31
+
+// Hany esemenyt kezelt le a driver egy-egy hardver-interrupt kiszolgalasanal:
+
+ Interrupt work histogram:
+ hist[ 0]:        0 hist[ 1]:        2 hist[ 2]:    18574 hist[ 3]:       79
+ hist[ 4]:       14 hist[ 5]:        1 hist[ 6]:        0 hist[ 7]:        1
+ hist[ 8]:        0 hist[ 9]:        7
+
+// Hany kikuldendo csomag volt mar a Tx-ringben amikor ujabb lett irva bele:
+
+ Tx ring histogram:
+ hist[ 0]:     2329 hist[ 1]:        0 hist[ 2]:        0 hist[ 3]:        0
+
+// Az E1-interfesz hiba-szamlaloi, az rfc2495-nek megfeleloen:
+// (kb. a Cisco routerek "show controllers e1" formatumaban: http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
+
+Data in current interval (91 seconds elapsed):
+   9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
+   0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
+Data in Interval 1 (15 minutes):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+Data in last 4 intervals (1 hour):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+Data in last 96 intervals (24 hours):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+
+-----------------------------------------------------------------
+
+Nehany kulonlegesebb beallitasi lehetoseg (idovel beepulhetnek majd a driverbe):
+Ezekkel sok galibat lehet okozni, nagyon ovatosan kell oket hasznalni!
+
+        modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
+        devices: (lasd page 107 es g706 Annex B)
+                lbireg[ 0x1b ] |= 0x08
+                lbireg[ 0x1c ] |= 0xc0
+        - ilyenkor ertelmezett az NMF - 'No Multiframe alignment Found after
+        400 msec' alarm.
+
+        FALC - a vonali meghajto IC
+        local loop - a sajat adasomat halljam vissza
+        remote loop - a kivulrol jovo adast adom vissza
+
+        Egy hibakeresesre hasznalhato dolog:
+                - 1-es timeslot local loop a FALC-ban:  echo >lbireg 0x1d 0x21
+                - local loop kikapcsolasa:              echo >lbireg 0x1d 0x00
diff --git a/Documentation/networking/slicecom.txt b/Documentation/networking/slicecom.txt
new file mode 100644
index 00000000000..59cfd95121f
--- /dev/null
+++ b/Documentation/networking/slicecom.txt
@@ -0,0 +1,369 @@
+
+SliceCOM adapter user's documentation - for the 0.51 driver version
+
+Written by Bartók István <bartoki@itc.hu>
+
+English translation: Lakatos György <gyuri@itc.hu>
+Mon Dec 11 15:28:42 CET 2000
+
+Last modified: Wed Aug 29 17:25:37 CEST 2001
+
+-----------------------------------------------------------------
+
+Usage:
+
+Compiling the kernel:
+
+Code maturity level options
+        [*] Prompt for development and/or incomplete code/drivers
+
+Network device support
+        Wan interfaces
+                <M> MultiGate (COMX) synchronous
+                        <M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
+                        <M> Support for HDLC and syncPPP...
+
+
+Loading the modules:
+
+modprobe comx
+
+modprobe comx-proto-ppp         # module for  Cisco-HDLC and SyncPPP protocols
+
+modprobe comx-hw-munich         # the module logs information by the kernel
+                                # about the detected boards
+
+
+Configuring the board:
+
+# This interface will use the Cisco-HDLC line protocol,
+# the timeslices assigned are 1,2 (128 KiBit line speed)
+# (the first data timeslice in the G.703 frame is no. 1)
+#
+mkdir /proc/comx/comx0.1/
+echo slicecom   >/proc/comx/comx0.1/boardtype
+echo hdlc       >/proc/comx/comx0.1/protocol
+echo 1 2        >/proc/comx/comx0.1/timeslots
+
+
+# This interface uses SyncPPP line protocol, the assigned 
+# is no. 3 (64 KiBit line speed)
+#
+mkdir /proc/comx/comx0.2/
+echo slicecom   >/proc/comx/comx0.2/boardtype
+echo ppp        >/proc/comx/comx0.2/protocol
+echo 3          >/proc/comx/comx0.2/timeslots
+
+...
+
+ifconfig comx0.1 up
+ifconfig comx0.2 up
+
+-----------------------------------------------------------------
+
+The COMX interfaces use a 10 packet transmit queue by default, however WAN
+networks sometimes use bigger values (20 to 100), to utilize the line better
+by large traffic (though the line delay increases because of more packets
+join the queue).
+
+# ifconfig comx0 txqueuelen 50
+
+This option is only supported by the ifconfig command of the later 
+distributions, which came with 2.2 kernels, such as RedHat 6.1 or Debian 2.2.
+
+You can download a newer netbase packet from 
+http://www.debian.org/~rcw/2.2/netbase/ for Debian 2.1, which has a new
+ifconfig. You can get further information about using 2.2 kernel with
+Debian 2.1 from http://www.debian.org/releases/stable/running-kernel-2.2
+
+-----------------------------------------------------------------
+
+The SliceCom LEDs:
+
+red     - on, if the interface is unconfigured, or it gets Remote Alarm-s
+green   - on, if the board finds frame-sync in the received signal      
+
+A bit more detailed:
+
+red:    green:  meaning:
+
+-       -       no frame-sync, no signal received, or signal SNAFU.
+-       on      "Everything is OK"
+on      on      Recepion is ok, but the remote end sends Remote Alarm
+on      -       The interface is unconfigured
+
+-----------------------------------------------------------------
+
+A more detailed description of the hardware setting options:
+
+The general and the protocol layer options described in the 'comx.txt' file
+apply to the SliceCom as well, I only summarize the SliceCom hardware specific
+settings below.
+
+The '/proc/comx' configuring interface:
+
+An interface directory should be created for every timeslot group with
+'mkdir', e,g: 'comx0', 'comx1' etc. The timeslots can be assigned here to the
+specific interface. The Cisco-like naming convention (serial3:1 - first
+timeslot group of the 3rd. board) can't be used here, because these mean IP
+aliasing in Linux.
+
+You can give any meaningful name to keep the configuration clear; 
+e.g: 'comx0.1', 'comx0.2', 'comx1.1', comx1.2', if you have two boards
+with two interfaces each.
+
+Settings, which apply to the board:
+
+Neither 'io' nor 'irq' settings required, the driver uses the resources
+given by the PCI BIOS.
+
+comx0/boardnum  - board number of the SliceCom in the PC (using the 'natural'
+                PCI order) as listed in '/proc/pci' or the output of the
+                'lspci' command, generally the slots nearer to the motherboard
+                PCI driver chips have the lower numbers.
+                
+                Default: 0 (the counting starts with 0)
+
+Though the options below are to be set on a single interface, they apply to the
+whole board. The restriction, to use them on 'UP' interfaces, is because the 
+command sequence below could lead to unpredicable results.
+
+        # echo 0        >boardnum
+        # echo internal >clock_source
+        # echo 1        >boardnum
+
+The sequence would set the clock source of board 0.
+
+These settings will persist after all the interfaces are cleared, but are
+cleared when the driver module is unloaded and loaded again.
+
+comx0/clock_source - source of the transmit clock
+        Usage:
+
+        # echo line     >/proc/comx/comx0/clock_source
+        # echo internal >/proc/comx/comx0/clock_source
+
+        line    - The Tx clock is being decoded if the input data stream,
+                if no clock seen on the input, then the board will use it's
+                own clock generator.
+
+        internal - The Tx clock is supplied by the builtin clock generator.     
+
+        Default: line
+
+        Normally, the telecommunication company's end device (the HDSL
+        modem) provides the Tx clock, that's why 'line' is the default.
+
+comx0/framing   - Switching CRC4 off/on
+
+        CRC4: 16 PCM frames (The 32 64Kibit channels are multiplexed into a
+        PCM frame, nothing to do with HDLC frames) are divided into 2x8
+        groups, each group has a 4 bit CRC.
+
+        # echo crc4     >/proc/comx/comx0/framing
+        # echo no-crc4  >/proc/comx/comx0/framing
+
+        Default is 'crc4', the Hungarian MATAV lines behave like this. 
+        The traffic generally passes if this setting on both ends don't match.
+
+comx0/linecode  - Setting the line coding
+
+        # echo hdb3     >/proc/comx/comx0/linecode
+        # echo ami      >/proc/comx/comx0/linecode
+
+        Default a 'hdb3', MATAV lines use this.
+        
+        (AMI coding is rarely used with E1 lines). Frame sync may occur, if
+        this setting doesn't match the other end's, but CRC4 and data errors
+        will come, which will result in CRC errors on HDLC/SyncPPP level. 
+
+comx0/reg       - direct access to the board's MUNICH (reg) and FALC (lbireg)
+comx0/lbireg    circuit's registers  
+
+        # echo >reg 0x04 0x0    - write 0 to register 4
+        # echo >reg 0x104       - write the contents of register 4 with
+                                printk() to syslog
+
+WARNING! These are only for development purposes, messing with this will
+        result much trouble!
+
+comx0/loopback - Places a loop to the board's G.703 signals
+
+        # echo none   >/proc/comx/comx0/loopback
+        # echo local  >/proc/comx/comx0/loopback
+        # echo remote >/proc/comx/comx0/loopback
+
+        none   - normal operation, no loop
+        local  - the board receives it's own output
+        remote - the board sends the received data to the remote side
+
+        Default: none
+
+-----------------------------------------------------------------
+
+Interface (channel group in Cisco terms) settings: 
+
+comx0/timeslots - which timeslots belong to the given interface
+
+        Setting:
+
+        # echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
+
+        # cat /proc/comx/comx0/timeslots
+        1 2 5 6 7 8 
+        #
+
+        Finding a timeslot: 
+
+        # grep ' 4' /proc/comx/comx*/timeslots
+        /proc/comx/comx0/timeslots:1 3 4 5 6
+        #
+
+        The timeslots can be in any order, '1 2 3' is the same as '1 3 2'.
+
+        The interface has to be DOWN during the setting ('ifconfig comx0
+        down'), but the other interfaces could operate normally.
+
+        The driver checks if the assigned timeslots are vacant, if not, then
+        the setting won't be applied.
+
+        The timeslot values are treated as decimal numbers, not to misunderstand
+        values of 08, 09 form.
+
+-----------------------------------------------------------------
+
+Checking the interface and board status:
+
+- Lines beginning with ' ' (space) belong to the original output, the lines
+which begin with '//' are the comments.
+
+ papaya:~$ cat /proc/comx/comx1/status
+ Interface administrative status is UP, modem status is UP, protocol is UP
+ Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
+ Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
+               (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
+ Debug flags: none
+ RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
+            buffer overrun: 0, pbuffer overrun: 0
+ TX errors: underrun: 0
+ Line keepalive (value: 10) status UP [0]
+
+// The hardware specific part starts here:
+ Controller status:
+         No alarms
+
+// Alarm: 
+//
+// No alarms - Everything OK
+//
+// LOS  - Loss Of Signal - No signal sensed on the input
+// AIS  - Alarm Indication Signal - The remot side sends '11111111'-s, 
+//      it tells, that there's an error condition, or it's not
+//      initialised.
+// AUXP - Auxiliary Pattern Indication - 01010101.. received.
+// LFA  - Loss of Frame Alignment - no frame sync received.
+// RRA  - Receive Remote Alarm - the remote end's OK, but singnals error cond.
+// LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync.
+// NMF  - No Multiframe alignment Found after 400 msec - no such alarm using
+//      no-crc4 or crc4 framing, see below.
+//
+// Other possible error messages:
+//
+// Transmit Line Short - the board felt, that it's output is short-circuited,
+//      so it switched the transmission off. (The board can't definitely tell,
+//      that it's output is short-circuited.)
+
+// Chained list of the received packets, for debug purposes:
+
+ Rx ring:
+         rafutott: 0
+         lastcheck: 50845731, jiffies: 51314281
+         base: 017b1858
+         rx_desc_ptr: 0
+         rx_desc_ptr: 017b1858
+         hw_curr_ptr: 017b1858
+         06040000 017b1868 017b1898 c016ff00
+         06040000 017b1878 017b1e9c c016ff00
+         46040000 017b1888 017b24a0 c016ff00
+         06040000 017b1858 017b2aa4 c016ff00
+
+// All the interfaces using the board: comx1, using the 1,2,...16 timeslots,
+// comx2, using timeslot 17, etc.
+
+ Interfaces using this board: (channel-group, interface, timeslots)
+          0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+          1 comx2: 17
+          2 comx3: 18
+          3 comx4: 19
+          4 comx5: 20
+          5 comx6: 21
+          6 comx7: 22
+          7 comx8: 23
+          8 comx9: 24
+          9 comx10: 25
+         10 comx11: 26
+         11 comx12: 27
+         12 comx13: 28
+         13 comx14: 29
+         14 comx15: 30
+         15 comx16: 31
+
+// The number of events handled by the driver during an interrupt cycle:
+
+ Interrupt work histogram:
+ hist[ 0]:        0 hist[ 1]:        2 hist[ 2]:    18574 hist[ 3]:       79
+ hist[ 4]:       14 hist[ 5]:        1 hist[ 6]:        0 hist[ 7]:        1
+ hist[ 8]:        0 hist[ 9]:        7
+
+// The number of packets to send in the Tx ring, when a new one arrived:
+
+ Tx ring histogram:
+ hist[ 0]:     2329 hist[ 1]:        0 hist[ 2]:        0 hist[ 3]:        0
+
+// The error counters of the E1 interface, according to the RFC2495,
+// (similar to the Cisco "show controllers e1" command's output:
+// http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
+
+Data in current interval (91 seconds elapsed):
+   9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
+   0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
+Data in Interval 1 (15 minutes):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+Data in last 4 intervals (1 hour):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+Data in last 96 intervals (24 hours):
+   0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
+   0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
+   0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
+
+-----------------------------------------------------------------
+
+Some unique options, (may get into the driver later):
+Treat them very carefully, these can cause much trouble!
+
+        modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
+        devices: (see page 107 and g706 Annex B)
+                lbireg[ 0x1b ] |= 0x08
+                lbireg[ 0x1c ] |= 0xc0
+
+        - The NMF - 'No Multiframe alignment Found after 400 msec' alarm 
+        comes into account.
+
+        FALC - the line driver chip.
+        local loop - I hear my transmission back.
+        remote loop - I echo the remote transmission back.
+
+        Something useful for finding errors:
+        
+                - local loop for timeslot 1 in the FALC chip:
+
+        # echo >lbireg 0x1d 0x21
+
+                - Swithing the loop off:
+
+        # echo >lbireg 0x1d 0x00
diff --git a/Documentation/networking/smc9.txt b/Documentation/networking/smc9.txt
new file mode 100644
index 00000000000..d1e15074e43
--- /dev/null
+++ b/Documentation/networking/smc9.txt
@@ -0,0 +1,42 @@
+
+SMC 9xxxx Driver 
+Revision 0.12 
+3/5/96
+Copyright 1996  Erik Stahlman 
+Released under terms of the GNU General Public License. 
+
+This file contains the instructions and caveats for my SMC9xxx driver.  You
+should not be using the driver without reading this file.  
+
+Things to note about installation:
+
+  1. The driver should work on all kernels from 1.2.13 until 1.3.71.
+        (A kernel patch is supplied for 1.3.71 )
+
+  2. If you include this into the kernel, you might need to change some
+        options, such as for forcing IRQ.   
+
+ 
+  3.  To compile as a module, run 'make' .   
+        Make will give you the appropriate options for various kernel support.
+ 
+  4.  Loading the driver as a module :
+
+        use:   insmod smc9194.o 
+        optional parameters:
+                io=xxxx    : your base address
+                irq=xx     : your irq 
+                ifport=x   :    0 for whatever is default
+                                1 for twisted pair
+                                2 for AUI  ( or BNC on some cards )
+
+How to obtain the latest version? 
+        
+FTP:  
+        ftp://fenris.campus.vt.edu/smc9/smc9-12.tar.gz
+        ftp://sfbox.vt.edu/filebox/F/fenris/smc9/smc9-12.tar.gz 
+   
+
+Contacting me:
+    erik@mail.vt.edu
+ 
diff --git a/Documentation/networking/smctr.txt b/Documentation/networking/smctr.txt
new file mode 100644
index 00000000000..4c866f5a0ee
--- /dev/null
+++ b/Documentation/networking/smctr.txt
@@ -0,0 +1,66 @@
+Text File for the SMC TokenCard TokenRing Linux driver (smctr.c).
+        By Jay Schulist <jschlst@samba.org>
+
+The Linux SMC Token Ring driver works with the SMC TokenCard Elite (8115T) 
+ISA and SMC TokenCard Elite/A (8115T/A) MCA adapters.
+
+Latest information on this driver can be obtained on the Linux-SNA WWW site.
+Please point your browser to: http://www.linux-sna.org
+
+This driver is rather simple to use. Select Y to Token Ring adapter support
+in the kernel configuration. A choice for SMC Token Ring adapters will
+appear. This drives supports all SMC ISA/MCA adapters. Choose this
+option. I personally recommend compiling the driver as a module (M), but if you
+you would like to compile it staticly answer Y instead.
+
+This driver supports multiple adapters without the need to load multiple copies
+of the driver. You should be able to load up to 7 adapters without any kernel
+modifications, if you are in need of more please contact the maintainer of this
+driver.
+
+Load the driver either by lilo/loadlin or as a module. When a module using the
+following command will suffice for most:
+
+# modprobe smctr
+smctr.c: v1.00 12/6/99 by jschlst@samba.org
+tr0: SMC TokenCard 8115T at Io 0x300, Irq 10, Rom 0xd8000, Ram 0xcc000.
+
+Now just setup the device via ifconfig and set and routes you may have. After
+this you are ready to start sending some tokens.
+
+Errata:
+1). For anyone wondering where to pick up the SMC adapters please browse
+    to http://www.smc.com
+
+2). If you are the first/only Token Ring Client on a Token Ring LAN, please
+    specify the ringspeed with the ringspeed=[4/16] module option. If no
+    ringspeed is specified the driver will attempt to autodetect the ring
+    speed and/or if the adapter is the first/only station on the ring take
+    the appropriate actions. 
+
+    NOTE: Default ring speed is 16MB UTP.
+
+3). PnP support for this adapter sucks. I recommend hard setting the 
+    IO/MEM/IRQ by the jumpers on the adapter. If this is not possible
+    load the module with the following io=[ioaddr] mem=[mem_addr]
+    irq=[irq_num].
+
+    The following IRQ, IO, and MEM settings are supported.
+
+    IO ports:
+    0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0, 0x300,
+    0x320, 0x340, 0x360, 0x380.
+
+    IRQs:
+    2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15
+
+    Memory addresses:
+    0xA0000, 0xA4000, 0xA8000, 0xAC000, 0xB0000, 0xB4000,
+    0xB8000, 0xBC000, 0xC0000, 0xC4000, 0xC8000, 0xCC000,
+    0xD0000, 0xD4000, 0xD8000, 0xDC000, 0xE0000, 0xE4000,
+    0xE8000, 0xEC000, 0xF0000, 0xF4000, 0xF8000, 0xFC000
+
+This driver is under the GNU General Public License. Its Firmware image is
+included as an initialized C-array and is licensed by SMC to the Linux
+users of this driver. However no warranty about its fitness is expressed or
+implied by SMC.
diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt
new file mode 100644
index 00000000000..71749007091
--- /dev/null
+++ b/Documentation/networking/tcp.txt
@@ -0,0 +1,39 @@
+How the new TCP output machine [nyi] works.
+
+
+Data is kept on a single queue. The skb->users flag tells us if the frame is
+one that has been queued already. To add a frame we throw it on the end. Ack
+walks down the list from the start.
+
+We keep a set of control flags
+
+
+        sk->tcp_pend_event
+
+                TCP_PEND_ACK                    Ack needed
+                TCP_ACK_NOW                     Needed now
+                TCP_WINDOW                      Window update check
+                TCP_WINZERO                     Zero probing
+
+
+        sk->transmit_queue              The transmission frame begin
+        sk->transmit_new                First new frame pointer
+        sk->transmit_end                Where to add frames
+
+        sk->tcp_last_tx_ack             Last ack seen
+        sk->tcp_dup_ack                 Dup ack count for fast retransmit
+
+
+Frames are queued for output by tcp_write. We do our best to send the frames
+off immediately if possible, but otherwise queue and compute the body
+checksum in the copy. 
+
+When a write is done we try to clear any pending events and piggy back them.
+If the window is full we queue full sized frames. On the first timeout in
+zero window we split this.
+
+On a timer we walk the retransmit list to send any retransmits, update the
+backoff timers etc. A change of route table stamp causes a change of header
+and recompute. We add any new tcp level headers and refinish the checksum
+before sending. 
+
diff --git a/Documentation/networking/tlan.txt b/Documentation/networking/tlan.txt
new file mode 100644
index 00000000000..7e6aa5b20c3
--- /dev/null
+++ b/Documentation/networking/tlan.txt
@@ -0,0 +1,117 @@
+(C) 1997-1998 Caldera, Inc.
+(C) 1998 James Banks
+(C) 1999-2001 Torben Mathiasen <tmm@image.dk, torben.mathiasen@compaq.com>
+
+For driver information/updates visit http://opensource.compaq.com
+
+
+TLAN driver for Linux, version 1.14a
+README
+
+
+I.  Supported Devices.
+
+    Only PCI devices will work with this driver.
+
+    Supported:
+    Vendor ID   Device ID       Name
+    0e11        ae32            Compaq Netelligent 10/100 TX PCI UTP
+    0e11        ae34            Compaq Netelligent 10 T PCI UTP
+    0e11        ae35            Compaq Integrated NetFlex 3/P
+    0e11        ae40            Compaq Netelligent Dual 10/100 TX PCI UTP
+    0e11        ae43            Compaq Netelligent Integrated 10/100 TX UTP
+    0e11        b011            Compaq Netelligent 10/100 TX Embedded UTP
+    0e11        b012            Compaq Netelligent 10 T/2 PCI UTP/Coax
+    0e11        b030            Compaq Netelligent 10/100 TX UTP
+    0e11        f130            Compaq NetFlex 3/P
+    0e11        f150            Compaq NetFlex 3/P
+    108d        0012            Olicom OC-2325  
+    108d        0013            Olicom OC-2183
+    108d        0014            Olicom OC-2326  
+
+
+    Caveats:
+    
+    I am not sure if 100BaseTX daughterboards (for those cards which
+    support such things) will work.  I haven't had any solid evidence
+    either way.
+
+    However, if a card supports 100BaseTx without requiring an add
+    on daughterboard, it should work with 100BaseTx.
+
+    The "Netelligent 10 T/2 PCI UTP/Coax" (b012) device is untested,
+    but I do not expect any problems.
+    
+
+II.   Driver Options
+        1. You can append debug=x to the end of the insmod line to get
+           debug messages, where x is a bit field where the bits mean
+           the following:
+           
+           0x01         Turn on general debugging messages.
+           0x02         Turn on receive debugging messages.
+           0x04         Turn on transmit debugging messages.
+           0x08         Turn on list debugging messages.
+
+        2. You can append aui=1 to the end of the insmod line to cause
+           the adapter to use the AUI interface instead of the 10 Base T
+           interface.  This is also what to do if you want to use the BNC
+           connector on a TLAN based device.  (Setting this option on a
+           device that does not have an AUI/BNC connector will probably
+           cause it to not function correctly.)
+
+        3. You can set duplex=1 to force half duplex, and duplex=2 to
+           force full duplex.
+
+        4. You can set speed=10 to force 10Mbs operation, and speed=100
+           to force 100Mbs operation. (I'm not sure what will happen
+           if a card which only supports 10Mbs is forced into 100Mbs
+           mode.)
+
+        5. You have to use speed=X duplex=Y together now. If you just
+           do "insmod tlan.o speed=100" the driver will do Auto-Neg.
+           To force a 10Mbps Half-Duplex link do "insmod tlan.o speed=10 
+           duplex=1".
+
+        6. If the driver is built into the kernel, you can use the 3rd
+           and 4th parameters to set aui and debug respectively.  For
+           example:
+
+           ether=0,0,0x1,0x7,eth0
+
+           This sets aui to 0x1 and debug to 0x7, assuming eth0 is a
+           supported TLAN device.
+
+           The bits in the third byte are assigned as follows:
+
+                0x01 = aui
+                0x02 = use half duplex
+                0x04 = use full duplex
+                0x08 = use 10BaseT
+                0x10 = use 100BaseTx
+
+           You also need to set both speed and duplex settings when forcing
+           speeds with kernel-parameters. 
+           ether=0,0,0x12,0,eth0 will force link to 100Mbps Half-Duplex.
+
+        7. If you have more than one tlan adapter in your system, you can
+           use the above options on a per adapter basis. To force a 100Mbit/HD
+           link with your eth1 adapter use:
+           
+           insmod tlan speed=0,100 duplex=0,1
+
+           Now eth0 will use auto-neg and eth1 will be forced to 100Mbit/HD.
+           Note that the tlan driver supports a maximum of 8 adapters.
+
+
+III.  Things to try if you have problems.
+        1. Make sure your card's PCI id is among those listed in
+           section I, above.
+        2. Make sure routing is correct.
+        3. Try forcing different speed/duplex settings
+
+
+There is also a tlan mailing list which you can join by sending "subscribe tlan"
+in the body of an email to majordomo@vuser.vu.union.edu.
+There is also a tlan website at http://opensource.compaq.com
+
diff --git a/Documentation/networking/tms380tr.txt b/Documentation/networking/tms380tr.txt
new file mode 100644
index 00000000000..179e527b9da
--- /dev/null
+++ b/Documentation/networking/tms380tr.txt
@@ -0,0 +1,147 @@
+Text file for the Linux SysKonnect Token Ring ISA/PCI Adapter Driver.
+        Text file by: Jay Schulist <jschlst@samba.org>
+
+The Linux SysKonnect Token Ring driver works with the SysKonnect TR4/16(+) ISA,
+SysKonnect TR4/16(+) PCI, SysKonnect TR4/16 PCI, and older revisions of the
+SK NET TR4/16 ISA card.
+
+Latest information on this driver can be obtained on the Linux-SNA WWW site.
+Please point your browser to: 
+http://www.linux-sna.org
+
+Many thanks to Christoph Goos for his excellent work on this driver and
+SysKonnect for donating the adapters to Linux-SNA for the testing and 
+maintenance of this device driver.
+
+Important information to be noted:
+1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be 
+   patient.
+2. This driver works very well when autoprobing for adapters. Why even 
+   think about those nasty io/int/dma settings of modprobe when the driver 
+   will do it all for you!
+
+This driver is rather simple to use. Select Y to Token Ring adapter support
+in the kernel configuration. A choice for SysKonnect Token Ring adapters will
+appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this
+option. I personally recommend compiling the driver as a module (M), but if you
+you would like to compile it staticly answer Y instead.
+
+This driver supports multiple adapters without the need to load multiple copies
+of the driver. You should be able to load up to 7 adapters without any kernel
+modifications, if you are in need of more please contact the maintainer of this
+driver.
+
+Load the driver either by lilo/loadlin or as a module. When a module using the
+following command will suffice for most:
+
+# modprobe sktr
+
+This will produce output similar to the following: (Output is user specific)
+
+sktr.c: v1.01 08/29/97 by Christoph Goos
+tr0: SK NET TR 4/16 PCI found at 0x6100, using IRQ 17.
+tr1: SK NET TR 4/16 PCI found at 0x6200, using IRQ 16.
+tr2: SK NET TR 4/16 ISA found at 0xa20, using IRQ 10 and DMA 5.
+
+Now just setup the device via ifconfig and set and routes you may have. After
+this you are ready to start sending some tokens.
+
+Errata:
+For anyone wondering where to pick up the SysKonnect adapters please browse
+to http://www.syskonnect.com
+
+This driver is under the GNU General Public License. Its Firmware image is 
+included as an initialized C-array and is licensed by SysKonnect to the Linux 
+users of this driver. However no warranty about its fitness is expressed or 
+implied by SysKonnect.
+
+Below find attached the setting for the SK NET TR 4/16 ISA adapters
+-------------------------------------------------------------------
+
+                    ***************************
+                    ***   C O N T E N T S   ***
+                    ***************************
+
+                1) Location of DIP-Switch W1
+                2) Default settings
+                3) DIP-Switch W1 description
+
+
+  ==============================================================
+  CHAPTER 1     LOCATION OF DIP-SWITCH
+  ==============================================================
+
+UÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+þUÄÄÄÄÄÄ¿                         UÄÄÄÄÄ¿            UÄÄÄ¿         þ
+þAÄÄÄÄÄÄU                      W1 AÄÄÄÄÄU     UÄÄÄÄ¿ þ   þ         þ
+þUÄÄÄÄÄÄ¿                                     þ    þ þ   þ      UÄÄÅ¿
+þAÄÄÄÄÄÄU              UÄÄÄÄÄÄÄÄÄÄÄ¿          AÄÄÄÄU þ   þ      þ  þþ
+þUÄÄÄÄÄÄ¿              þ           þ          UÄÄÄ¿  AÄÄÄU      AÄÄÅU
+þAÄÄÄÄÄÄU              þ TMS380C26 þ          þ   þ                þ
+þUÄÄÄÄÄÄ¿              þ           þ          AÄÄÄU                AÄ¿
+þAÄÄÄÄÄÄU              þ           þ                               þ þ
+þ                      AÄÄÄÄÄÄÄÄÄÄÄU                               þ þ
+þ                                                                  þ þ
+þ                                                                  AÄU
+þ                                                                  þ
+þ                                                                  þ
+þ                                                                  þ
+þ                                                                  þ
+AÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄU
+             AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU  AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU
+
+  ==============================================================
+  CHAPTER 2     DEFAULT SETTINGS
+  ==============================================================
+
+          W1    1  2  3  4  5  6  7  8
+        +------------------------------+
+        | ON    X                      |
+        | OFF      X  X  X  X  X  X  X |
+        +------------------------------+
+
+        W1.1 = ON               Adapter drives address lines SA17..19
+        W1.2 - 1.5 = OFF        BootROM disabled
+        W1.6 - 1.8 = OFF        I/O address 0A20h
+
+  ==============================================================
+  CHAPTER 3     DIP SWITCH W1 DESCRIPTION
+  ==============================================================
+
+      UÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄ¿  ON
+      þ 1 þ 2 þ 3 þ 4 þ 5 þ 6 þ 7 þ 8 þ
+      AÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄU  OFF
+      |AD | BootROM Addr. |  I/O      |
+      +-+-+-------+-------+-----+-----+
+        |         |             |
+        |         |             +------ 6     7     8
+        |         |                     ON    ON    ON       1900h
+        |         |                     ON    ON    OFF      0900h
+        |         |                     ON    OFF   ON       1980h
+        |         |                     ON    OFF   OFF      0980h
+        |         |                     OFF   ON    ON       1b20h
+        |         |                     OFF   ON    OFF      0b20h
+        |         |                     OFF   OFF   ON       1a20h
+        |         |                     OFF   OFF   OFF      0a20h    (+)
+        |         |
+        |         |
+        |         +-------- 2     3     4     5
+        |                   OFF   x     x     x       disabled  (+)
+        |                   ON    ON    ON    ON      C0000
+        |                   ON    ON    ON    OFF     C4000
+        |                   ON    ON    OFF   ON      C8000
+        |                   ON    ON    OFF   OFF     CC000
+        |                   ON    OFF   ON    ON      D0000
+        |                   ON    OFF   ON    OFF     D4000
+        |                   ON    OFF   OFF   ON      D8000
+        |                   ON    OFF   OFF   OFF     DC000
+        |
+        |
+        +----- 1
+               OFF    adapter does NOT drive SA<17..19>
+               ON     adapter drives SA<17..19>  (+)
+
+
+        (+) means default setting
+
+                       ********************************
diff --git a/Documentation/networking/tuntap.txt b/Documentation/networking/tuntap.txt
new file mode 100644
index 00000000000..ec3d109d787
--- /dev/null
+++ b/Documentation/networking/tuntap.txt
@@ -0,0 +1,147 @@
+Universal TUN/TAP device driver.
+Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
+
+  Linux, Solaris drivers 
+  Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
+
+  FreeBSD TAP driver 
+  Copyright (c) 1999-2000 Maksim Yevmenkin <m_evmenkin@yahoo.com>
+
+  Revision of this document 2002 by Florian Thiel <florian.thiel@gmx.net>
+
+1. Description
+  TUN/TAP provides packet reception and transmission for user space programs. 
+  It can be seen as a simple Point-to-Point or Ethernet device, which,
+  instead of receiving packets from physical media, receives them from 
+  user space program and instead of sending packets via physical media 
+  writes them to the user space program. 
+
+  In order to use the driver a program has to open /dev/net/tun and issue a
+  corresponding ioctl() to register a network device with the kernel. A network
+  device will appear as tunXX or tapXX, depending on the options chosen. When
+  the program closes the file descriptor, the network device and all
+  corresponding routes will disappear.
+
+  Depending on the type of device chosen the userspace program has to read/write
+  IP packets (with tun) or ethernet frames (with tap). Which one is being used
+  depends on the flags given with the ioctl().
+
+  The package from http://vtun.sourceforge.net/tun contains two simple examples
+  for how to use tun and tap devices. Both programs work like a bridge between
+  two network interfaces.
+  br_select.c - bridge based on select system call.
+  br_sigio.c  - bridge based on async io and SIGIO signal.
+  However, the best example is VTun http://vtun.sourceforge.net :))
+
+2. Configuration 
+  Create device node:
+     mkdir /dev/net (if it doesn't exist already)
+     mknod /dev/net/tun c 10 200
+  
+  Set permissions:
+     e.g. chmod 0700 /dev/net/tun
+     if you want the device only accessible by root. Giving regular users the
+     right to assign network devices is NOT a good idea. Users could assign
+     bogus network interfaces to trick firewalls or administrators.
+
+  Driver module autoloading
+
+     Make sure that "Kernel module loader" - module auto-loading
+     support is enabled in your kernel.  The kernel should load it on
+     first access.
+  
+  Manual loading 
+     insert the module by hand:
+        modprobe tun
+
+  If you do it the latter way, you have to load the module every time you
+  need it, if you do it the other way it will be automatically loaded when
+  /dev/net/tun is being opened.
+
+3. Program interface 
+  3.1 Network device allocation:
+
+  char *dev should be the name of the device with a format string (e.g.
+  "tun%d"), but (as far as I can see) this can be any valid network device name.
+  Note that the character pointer becomes overwritten with the real device name
+  (e.g. "tun0")
+
+  #include <linux/if.h>
+  #include <linux/if_tun.h>
+
+  int tun_alloc(char *dev)
+  {
+      struct ifreq ifr;
+      int fd, err;
+
+      if( (fd = open("/dev/net/tun", O_RDWR)) < 0 )
+         return tun_alloc_old(dev);
+
+      memset(&ifr, 0, sizeof(ifr));
+
+      /* Flags: IFF_TUN   - TUN device (no Ethernet headers) 
+       *        IFF_TAP   - TAP device  
+       *
+       *        IFF_NO_PI - Do not provide packet information  
+       */ 
+      ifr.ifr_flags = IFF_TUN; 
+      if( *dev )
+         strncpy(ifr.ifr_name, dev, IFNAMSIZ);
+
+      if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
+         close(fd);
+         return err;
+      }
+      strcpy(dev, ifr.ifr_name);
+      return fd;
+  }              
+ 
+  3.2 Frame format:
+  If flag IFF_NO_PI is not set each frame format is: 
+     Flags [2 bytes]
+     Proto [2 bytes]
+     Raw protocol(IP, IPv6, etc) frame.
+
+Universal TUN/TAP device driver Frequently Asked Question.
+   
+1. What platforms are supported by TUN/TAP driver ?
+Currently driver has been written for 3 Unices:
+   Linux kernels 2.2.x, 2.4.x 
+   FreeBSD 3.x, 4.x, 5.x
+   Solaris 2.6, 7.0, 8.0
+
+2. What is TUN/TAP driver used for?
+As mentioned above, main purpose of TUN/TAP driver is tunneling. 
+It is used by VTun (http://vtun.sourceforge.net).
+
+Another interesting application using TUN/TAP is pipsecd
+(http://perso.enst.fr/~beyssac/pipsec/), an userspace IPSec
+implementation that can use complete kernel routing (unlike FreeS/WAN).
+
+3. How does Virtual network device actually work ? 
+Virtual network device can be viewed as a simple Point-to-Point or
+Ethernet device, which instead of receiving packets from a physical 
+media, receives them from user space program and instead of sending 
+packets via physical media sends them to the user space program. 
+
+Let's say that you configured IPX on the tap0, then whenever 
+the kernel sends an IPX packet to tap0, it is passed to the application
+(VTun for example). The application encrypts, compresses and sends it to 
+the other side over TCP or UDP. The application on the other side decompresses
+and decrypts the data received and writes the packet to the TAP device, 
+the kernel handles the packet like it came from real physical device.
+
+4. What is the difference between TUN driver and TAP driver?
+TUN works with IP frames. TAP works with Ethernet frames.
+
+This means that you have to read/write IP packets when you are using tun and
+ethernet frames when using tap.
+
+5. What is the difference between BPF and TUN/TAP driver?
+BFP is an advanced packet filter. It can be attached to existing
+network interface. It does not provide a virtual network interface.
+A TUN/TAP driver does provide a virtual network interface and it is possible
+to attach BPF to this interface.
+
+6. Does TAP driver support kernel Ethernet bridging?
+Yes. Linux and FreeBSD drivers support Ethernet bridging. 
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
new file mode 100644
index 00000000000..fa12a9e4abd
--- /dev/null
+++ b/Documentation/networking/vortex.txt
@@ -0,0 +1,450 @@
+Documentation/networking/vortex.txt
+Andrew Morton <andrewm@uow.edu.au>
+30 April 2000
+
+
+This document describes the usage and errata of the 3Com "Vortex" device
+driver for Linux, 3c59x.c.
+
+The driver was written by Donald Becker <becker@scyld.com>
+
+Don is no longer the prime maintainer of this version of the driver. 
+Please report problems to one or more of:
+
+  Andrew Morton <andrewm@uow.edu.au>
+  Netdev mailing list <netdev@oss.sgi.com>
+  Linux kernel mailing list <linux-kernel@vger.kernel.org>
+
+Please note the 'Reporting and Diagnosing Problems' section at the end
+of this file.
+
+
+Since kernel 2.3.99-pre6, this driver incorporates the support for the
+3c575-series Cardbus cards which used to be handled by 3c575_cb.c.
+
+This driver supports the following hardware:
+
+   3c590 Vortex 10Mbps
+   3c592 EISA 10mbps Demon/Vortex
+   3c597 EISA Fast Demon/Vortex
+   3c595 Vortex 100baseTx
+   3c595 Vortex 100baseT4
+   3c595 Vortex 100base-MII
+   3Com Vortex
+   3c900 Boomerang 10baseT
+   3c900 Boomerang 10Mbps Combo
+   3c900 Cyclone 10Mbps TPO
+   3c900B Cyclone 10Mbps T
+   3c900 Cyclone 10Mbps Combo
+   3c900 Cyclone 10Mbps TPC
+   3c900B-FL Cyclone 10base-FL
+   3c905 Boomerang 100baseTx
+   3c905 Boomerang 100baseT4
+   3c905B Cyclone 100baseTx
+   3c905B Cyclone 10/100/BNC
+   3c905B-FX Cyclone 100baseFx
+   3c905C Tornado
+   3c980 Cyclone
+   3cSOHO100-TX Hurricane
+   3c555 Laptop Hurricane
+   3c575 Boomerang CardBus
+   3CCFE575 Cyclone CardBus
+   3CCFE575CT Cyclone CardBus
+   3CCFE656 Cyclone CardBus
+   3CCFEM656 Cyclone CardBus
+   3c450 Cyclone/unknown
+
+
+Module parameters
+=================
+
+There are several parameters which may be provided to the driver when
+its module is loaded.  These are usually placed in /etc/modprobe.conf
+(/etc/modules.conf in 2.4).  Example:
+
+options 3c59x debug=3 rx_copybreak=300
+
+If you are using the PCMCIA tools (cardmgr) then the options may be
+placed in /etc/pcmcia/config.opts:
+
+module "3c59x" opts "debug=3 rx_copybreak=300"
+
+
+The supported parameters are:
+
+debug=N
+
+  Where N is a number from 0 to 7.  Anything above 3 produces a lot
+  of output in your system logs.  debug=1 is default.
+
+options=N1,N2,N3,...
+
+  Each number in the list provides an option to the corresponding
+  network card.  So if you have two 3c905's and you wish to provide
+  them with option 0x204 you would use:
+
+    options=0x204,0x204
+
+  The individual options are composed of a number of bitfields which
+  have the following meanings:
+
+  Possible media type settings
+        0       10baseT
+        1       10Mbs AUI
+        2       undefined
+        3       10base2 (BNC)
+        4       100base-TX
+        5       100base-FX
+        6       MII (Media Independent Interface)
+        7       Use default setting from EEPROM
+        8       Autonegotiate
+        9       External MII
+        10      Use default setting from EEPROM
+
+  When generating a value for the 'options' setting, the above media
+  selection values may be OR'ed (or added to) the following:
+
+  0x8000  Set driver debugging level to 7
+  0x4000  Set driver debugging level to 2
+  0x0400  Enable Wake-on-LAN
+  0x0200  Force full duplex mode.
+  0x0010  Bus-master enable bit (Old Vortex cards only)
+
+  For example:
+
+    insmod 3c59x options=0x204
+
+  will force full-duplex 100base-TX, rather than allowing the usual
+  autonegotiation.
+
+global_options=N
+
+  Sets the `options' parameter for all 3c59x NICs in the machine. 
+  Entries in the `options' array above will override any setting of
+  this.
+
+full_duplex=N1,N2,N3...
+
+  Similar to bit 9 of 'options'.  Forces the corresponding card into
+  full-duplex mode.  Please use this in preference to the `options'
+  parameter.
+
+  In fact, please don't use this at all! You're better off getting
+  autonegotiation working properly.
+
+global_full_duplex=N1
+
+  Sets full duplex mode for all 3c59x NICs in the machine.  Entries
+  in the `full_duplex' array above will override any setting of this.
+
+flow_ctrl=N1,N2,N3...
+
+  Use 802.3x MAC-layer flow control.  The 3com cards only support the
+  PAUSE command, which means that they will stop sending packets for a
+  short period if they receive a PAUSE frame from the link partner. 
+
+  The driver only allows flow control on a link which is operating in
+  full duplex mode.
+
+  This feature does not appear to work on the 3c905 - only 3c905B and
+  3c905C have been tested.
+
+  The 3com cards appear to only respond to PAUSE frames which are
+  sent to the reserved destination address of 01:80:c2:00:00:01.  They
+  do not honour PAUSE frames which are sent to the station MAC address.
+
+rx_copybreak=M
+
+  The driver preallocates 32 full-sized (1536 byte) network buffers
+  for receiving.  When a packet arrives, the driver has to decide
+  whether to leave the packet in its full-sized buffer, or to allocate
+  a smaller buffer and copy the packet across into it.
+
+  This is a speed/space tradeoff.
+
+  The value of rx_copybreak is used to decide when to make the copy. 
+  If the packet size is less than rx_copybreak, the packet is copied. 
+  The default value for rx_copybreak is 200 bytes.
+
+max_interrupt_work=N
+
+  The driver's interrupt service routine can handle many receive and
+  transmit packets in a single invocation.  It does this in a loop. 
+  The value of max_interrupt_work governs how mnay times the interrupt
+  service routine will loop.  The default value is 32 loops.  If this
+  is exceeded the interrupt service routine gives up and generates a
+  warning message "eth0: Too much work in interrupt".
+
+hw_checksums=N1,N2,N3,...
+
+  Recent 3com NICs are able to generate IPv4, TCP and UDP checksums
+  in hardware.  Linux has used the Rx checksumming for a long time. 
+  The "zero copy" patch which is planned for the 2.4 kernel series
+  allows you to make use of the NIC's DMA scatter/gather and transmit
+  checksumming as well.
+
+  The driver is set up so that, when the zerocopy patch is applied,
+  all Tornado and Cyclone devices will use S/G and Tx checksums.
+
+  This module parameter has been provided so you can override this
+  decision.  If you think that Tx checksums are causing a problem, you
+  may disable the feature with `hw_checksums=0'.
+
+  If you think your NIC should be performing Tx checksumming and the
+  driver isn't enabling it, you can force the use of hardware Tx
+  checksumming with `hw_checksums=1'.
+
+  The driver drops a message in the logfiles to indicate whether or
+  not it is using hardware scatter/gather and hardware Tx checksums.
+
+  Scatter/gather and hardware checksums provide considerable
+  performance improvement for the sendfile() system call, but a small
+  decrease in throughput for send().  There is no effect upon receive
+  efficiency.
+
+compaq_ioaddr=N
+compaq_irq=N
+compaq_device_id=N
+
+  "Variables to work-around the Compaq PCI BIOS32 problem"....
+
+watchdog=N
+
+  Sets the time duration (in milliseconds) after which the kernel
+  decides that the transmitter has become stuck and needs to be reset. 
+  This is mainly for debugging purposes, although it may be advantageous
+  to increase this value on LANs which have very high collision rates.
+  The default value is 5000 (5.0 seconds).
+
+enable_wol=N1,N2,N3,...
+
+  Enable Wake-on-LAN support for the relevant interface.  Donald
+  Becker's `ether-wake' application may be used to wake suspended
+  machines.
+
+  Also enables the NIC's power management support.
+
+global_enable_wol=N
+
+  Sets enable_wol mode for all 3c59x NICs in the machine.  Entries in
+  the `enable_wol' array above will override any setting of this.
+
+Media selection
+---------------
+
+A number of the older NICs such as the 3c590 and 3c900 series have
+10base2 and AUI interfaces.
+
+Prior to January, 2001 this driver would autoeselect the 10base2 or AUI
+port if it didn't detect activity on the 10baseT port.  It would then
+get stuck on the 10base2 port and a driver reload was necessary to
+switch back to 10baseT.  This behaviour could not be prevented with a
+module option override.
+
+Later (current) versions of the driver _do_ support locking of the
+media type.  So if you load the driver module with
+
+        modprobe 3c59x options=0
+
+it will permanently select the 10baseT port.  Automatic selection of
+other media types does not occur.
+
+
+Transmit error, Tx status register 82
+-------------------------------------
+
+This is a common error which is almost always caused by another host on
+the same network being in full-duplex mode, while this host is in
+half-duplex mode.  You need to find that other host and make it run in
+half-duplex mode or fix this host to run in full-duplex mode.
+
+As a last resort, you can force the 3c59x driver into full-duplex mode
+with
+
+        options 3c59x full_duplex=1
+
+but this has to be viewed as a workaround for broken network gear and
+should only really be used for equipment which cannot autonegotiate.
+
+
+Additional resources
+--------------------
+
+Details of the device driver implementation are at the top of the source file.
+
+Additional documentation is available at Don Becker's Linux Drivers site:
+
+  http://www.scyld.com/network/vortex.html
+
+Donald Becker's driver development site:
+
+     http://www.scyld.com/network
+
+Donald's vortex-diag program is useful for inspecting the NIC's state:
+
+     http://www.scyld.com/diag/#pci-diags
+
+Donald's mii-diag program may be used for inspecting and manipulating
+the NIC's Media Independent Interface subsystem:
+
+     http://www.scyld.com/diag/#mii-diag
+
+Donald's wake-on-LAN page:
+
+     http://www.scyld.com/expert/wake-on-lan.html
+
+3Com's documentation for many NICs, including the ones supported by
+this driver is available at 
+
+     http://support.3com.com/partners/developer/developer_form.html
+
+3Com's DOS-based application for setting up the NICs EEPROMs:
+
+        ftp://ftp.3com.com/pub/nic/3c90x/3c90xx2.exe
+
+Driver updates and a detailed changelog for the modifications which
+were made for the 2.3/2,4 series kernel is available at
+
+     http://www.uow.edu.au/~andrewm/linux/#3c59x-2.3
+
+
+Autonegotiation notes
+---------------------
+
+  The driver uses a one-minute heartbeat for adapting to changes in
+  the external LAN environment.  This means that when, for example, a
+  machine is unplugged from a hubbed 10baseT LAN plugged into a
+  switched 100baseT LAN, the throughput will be quite dreadful for up
+  to sixty seconds.  Be patient.
+
+  Cisco interoperability note from Walter Wong <wcw+@CMU.EDU>:
+
+  On a side note, adding HAS_NWAY seems to share a problem with the
+  Cisco 6509 switch.  Specifically, you need to change the spanning
+  tree parameter for the port the machine is plugged into to 'portfast'
+  mode.  Otherwise, the negotiation fails.  This has been an issue
+  we've noticed for a while but haven't had the time to track down.
+
+  Cisco switches    (Jeff Busch <jbusch@deja.com>)
+
+    My "standard config" for ports to which PC's/servers connect directly:
+
+        interface FastEthernet0/N
+        description machinename
+        load-interval 30
+        spanning-tree portfast
+
+    If autonegotiation is a problem, you may need to specify "speed
+    100" and "duplex full" as well (or "speed 10" and "duplex half").
+
+    WARNING: DO NOT hook up hubs/switches/bridges to these
+    specially-configured ports! The switch will become very confused.
+
+
+Reporting and diagnosing problems
+---------------------------------
+
+Maintainers find that accurate and complete problem reports are
+invaluable in resolving driver problems.  We are frequently not able to
+reproduce problems and must rely on your patience and efforts to get to
+the bottom of the problem.
+
+If you believe you have a driver problem here are some of the
+steps you should take:
+
+- Is it really a driver problem?
+
+   Eliminate some variables: try different cards, different
+   computers, different cables, different ports on the switch/hub,
+   different versions of the kernel or ofthe driver, etc.
+
+- OK, it's a driver problem.
+
+   You need to generate a report.  Typically this is an email to the
+   maintainer and/or linux-net@vger.kernel.org.  The maintainer's
+   email address will be inthe driver source or in the MAINTAINERS file.
+
+- The contents of your report will vary a lot depending upon the
+  problem.  If it's a kernel crash then you should refer to the
+  REPORTING-BUGS file.
+
+  But for most problems it is useful to provide the following:
+
+   o Kernel version, driver version
+
+   o A copy of the banner message which the driver generates when
+     it is initialised.  For example:
+
+     eth0: 3Com PCI 3c905C Tornado at 0xa400,  00:50:da:6a:88:f0, IRQ 19
+     8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
+     MII transceiver found at address 24, status 782d.
+     Enabling bus-master transmits and whole-frame receives.
+
+     NOTE: You must provide the `debug=2' modprobe option to generate
+     a full detection message.  Please do this:
+
+        modprobe 3c59x debug=2
+
+   o If it is a PCI device, the relevant output from 'lspci -vx', eg:
+
+     00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
+             Subsystem: 3Com Corporation: Unknown device 9200
+             Flags: bus master, medium devsel, latency 32, IRQ 19
+             I/O ports at a400 [size=128]
+             Memory at db000000 (32-bit, non-prefetchable) [size=128]
+             Expansion ROM at <unassigned> [disabled] [size=128K]
+             Capabilities: [dc] Power Management version 2
+     00: b7 10 00 92 07 00 10 02 74 00 00 02 08 20 00 00
+     10: 01 a4 00 00 00 00 00 db 00 00 00 00 00 00 00 00
+     20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10
+     30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 0a 0a
+
+   o A description of the environment: 10baseT? 100baseT?
+     full/half duplex? switched or hubbed?
+
+   o Any additional module parameters which you may be providing to the driver.
+
+   o Any kernel logs which are produced.  The more the merrier. 
+     If this is a large file and you are sending your report to a
+     mailing list, mention that you have the logfile, but don't send
+     it.  If you're reporting direct to the maintainer then just send
+     it.
+
+     To ensure that all kernel logs are available, add the
+     following line to /etc/syslog.conf:
+
+         kern.* /var/log/messages
+
+     Then restart syslogd with:
+
+         /etc/rc.d/init.d/syslog restart
+
+     (The above may vary, depending upon which Linux distribution you use).
+
+    o If your problem is reproducible then that's great.  Try the
+      following:
+
+      1) Increase the debug level.  Usually this is done via:
+
+         a) modprobe driver debug=7
+         b) In /etc/modprobe.conf (or /etc/modules.conf for 2.4):
+            options driver debug=7
+
+      2) Recreate the problem with the higher debug level,
+         send all logs to the maintainer.
+
+      3) Download you card's diagnostic tool from Donald
+         Backer's website http://www.scyld.com/diag.  Download
+         mii-diag.c as well.  Build these.
+
+         a) Run 'vortex-diag -aaee' and 'mii-diag -v' when the card is
+            working correctly.  Save the output.
+
+         b) Run the above commands when the card is malfunctioning.  Send
+            both sets of output.
+
+Finally, please be patient and be prepared to do some work.  You may end up working on
+this problem for a week or more as the maintainer asks more questions, asks for more
+tests, asks for patches to be applied, etc.  At the end of it all, the problem may even
+remain unresolved.
+
diff --git a/Documentation/networking/wan-router.txt b/Documentation/networking/wan-router.txt
new file mode 100644
index 00000000000..aea20cd2a56
--- /dev/null
+++ b/Documentation/networking/wan-router.txt
@@ -0,0 +1,622 @@
+------------------------------------------------------------------------------
+Linux WAN Router Utilities Package
+------------------------------------------------------------------------------
+Version 2.2.1 
+Mar 28, 2001
+Author: Nenad Corbic <ncorbic@sangoma.com>
+Copyright (c) 1995-2001 Sangoma Technologies Inc.
+------------------------------------------------------------------------------
+
+INTRODUCTION
+
+Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs)
+and/or stand-alone hosts over vast distances with data transfer rates
+significantly higher than those achievable with commonly used dial-up
+connections.
+
+Usually an external device called `WAN router' sitting on your local network
+or connected to your machine's serial port provides physical connection to
+WAN.  Although router's job may be as simple as taking your local network
+traffic, converting it to WAN format and piping it through the WAN link, these
+devices are notoriously expensive, with prices as much as 2 - 5 times higher
+then the price of a typical PC box.
+
+Alternatively, considering robustness and multitasking capabilities of Linux,
+an internal router can be built (most routers use some sort of stripped down
+Unix-like operating system anyway). With a number of relatively inexpensive WAN
+interface cards available on the market, a perfectly usable router can be
+built for less than half a price of an external router.  Yet a Linux box
+acting as a router can still be used for other purposes, such as fire-walling,
+running FTP, WWW or DNS server, etc.
+
+This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux
+operating system and provides generic hardware-independent services for such
+drivers.  Why can existing Linux network device interface not be used for
+this purpose?  Well, it can.  However, there are a few key differences between
+a typical network interface (e.g. Ethernet) and a WAN link.
+
+Many WAN protocols, such as X.25 and frame relay, allow for multiple logical
+connections (known as `virtual circuits' in X.25 terminology) over a single
+physical link.  Each such virtual circuit may (and almost always does) lead
+to a different geographical location and, therefore, different network.  As a
+result, it is the virtual circuit, not the physical link, that represents a
+route and, therefore, a network interface in Linux terms.
+
+To further complicate things, virtual circuits are usually volatile in nature
+(excluding so called `permanent' virtual circuits or PVCs).  With almost no
+time required to set up and tear down a virtual circuit, it is highly desirable
+to implement on-demand connections in order to minimize network charges.  So
+unlike a typical network driver, the WAN driver must be able to handle multiple
+network interfaces and cope as multiple virtual circuits come into existence
+and go away dynamically.
+ 
+Last, but not least, WAN configuration is much more complex than that of say
+Ethernet and may well amount to several dozens of parameters.  Some of them
+are "link-wide"  while others are virtual circuit-specific.  The same holds
+true for WAN statistics which is by far more extensive and extremely useful
+when troubleshooting WAN connections.  Extending the ifconfig utility to suit
+these needs may be possible, but does not seem quite reasonable.  Therefore, a
+WAN configuration utility and corresponding application programmer's interface
+is needed for this purpose.
+
+Most of these problems are taken care of by this module.  Its goal is to
+provide a user with more-or-less standard look and feel for all WAN devices and
+assist a WAN device driver writer by providing common services, such as:
+
+ o User-level interface via /proc file system
+ o Centralized configuration
+ o Device management (setup, shutdown, etc.)
+ o Network interface management (dynamic creation/destruction)
+ o Protocol encapsulation/decapsulation
+
+To ba able to use the Linux WAN Router you will also need a WAN Tools package
+available from
+
+        ftp.sangoma.com/pub/linux/current_wanpipe/wanpipe-X.Y.Z.tgz
+
+where vX.Y.Z represent the wanpipe version number.
+
+For technical questions and/or comments please e-mail to ncorbic@sangoma.com.
+For general inquiries please contact Sangoma Technologies Inc. by
+
+        Hotline:        1-800-388-2475  (USA and Canada, toll free)
+        Phone:          (905) 474-1990  ext: 106
+        Fax:            (905) 474-9223
+        E-mail:         dm@sangoma.com  (David Mandelstam)
+        WWW:            http://www.sangoma.com
+
+
+INSTALLATION
+
+Please read the WanpipeForLinux.pdf manual on how to 
+install the WANPIPE tools and drivers properly. 
+
+
+After installing wanpipe package: /usr/local/wanrouter/doc. 
+On the ftp.sangoma.com : /linux/current_wanpipe/doc
+
+
+COPYRIGHT AND LICENSING INFORMATION
+
+This program is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free Software
+Foundation; either version 2, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License along with
+this program; if not, write to the Free Software Foundation, Inc., 675 Mass
+Ave, Cambridge, MA 02139, USA.
+
+
+
+ACKNOWLEDGEMENTS
+
+This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed
+by Sangoma Technologies Inc. for Linux 2.0.x and 2.2.x.  Success of the WANPIPE
+together with the next major release of Linux kernel in summer 1996 commanded
+adequate changes to the WANPIPE code to take full advantage of new Linux
+features.
+
+Instead of continuing developing proprietary interface tied to Sangoma WAN
+cards, we decided to separate all hardware-independent code into a separate
+module and defined two levels of interfaces - one for user-level applications
+and another for kernel-level WAN drivers.  WANPIPE is now implemented as a
+WAN driver compliant with the WAN Link Driver interface.  Also a general
+purpose WAN configuration utility and a set of shell scripts was developed to 
+support WAN router at the user level.
+
+Many useful ideas concerning hardware-independent interface implementation
+were given by Mike McLagan <mike.mclagan@linux.org> and his implementation
+of the Frame Relay router and drivers for Sangoma cards (dlci/sdla).
+
+With the new implementation of the APIs being incorporated into the WANPIPE,
+a special thank goes to Alan Cox in providing insight into BSD sockets.
+
+Special thanks to all the WANPIPE users who performed field-testing, reported
+bugs and made valuable comments and suggestions that help us to improve this
+product.
+
+
+
+NEW IN THIS RELEASE
+
+        o Updated the WANCFG utility
+                Calls the pppconfig to configure the PPPD
+                for async connections.
+
+        o Added the PPPCONFIG utility
+                Used to configure the PPPD dameon for the
+                WANPIPE Async PPP and standard serial port.
+                The wancfg calls the pppconfig to configure
+                the pppd.
+
+        o Fixed the PCI autodetect feature.  
+                The SLOT 0 was used as an autodetect option
+                however, some high end PC's slot numbers start
+                from 0. 
+
+        o This release has been tested with the new backupd
+          daemon release.
+        
+
+PRODUCT COMPONENTS AND RELATED FILES
+
+/etc: (or user defined)
+        wanpipe1.conf   default router configuration file
+
+/lib/modules/X.Y.Z/misc:
+        wanrouter.o     router kernel loadable module
+        af_wanpipe.o    wanpipe api socket module
+
+/lib/modules/X.Y.Z/net:
+        sdladrv.o       Sangoma SDLA support module
+        wanpipe.o       Sangoma WANPIPE(tm) driver module
+
+/proc/net/wanrouter
+        Config          reads current router configuration
+        Status          reads current router status
+        {name}          reads WAN driver statistics
+
+/usr/sbin:
+        wanrouter       wanrouter start-up script
+        wanconfig       wanrouter configuration utility
+        sdladump        WANPIPE adapter memory dump utility
+        fpipemon        Monitor for Frame Relay
+        cpipemon        Monitor for Cisco HDLC
+        ppipemon        Monitor for PPP
+        xpipemon        Monitor for X25
+        wpkbdmon        WANPIPE keyboard led monitor/debugger
+
+/usr/local/wanrouter:
+        README          this file
+        COPYING         GNU General Public License
+        Setup           installation script
+        Filelist        distribution definition file
+        wanrouter.rc    meta-configuration file 
+                        (used by the Setup and wanrouter script)
+
+/usr/local/wanrouter/doc:
+        wanpipeForLinux.pdf     WAN Router User's Manual
+
+/usr/local/wanrouter/patches:
+        wanrouter-v2213.gz      patch for Linux kernels 2.2.11 up to 2.2.13.
+        wanrouter-v2214.gz      patch for Linux kernel 2.2.14. 
+        wanrouter-v2215.gz      patch for Linux kernels 2.2.15 to 2.2.17.
+        wanrouter-v2218.gz      patch for Linux kernels 2.2.18 and up.
+        wanrouter-v240.gz       patch for Linux kernel 2.4.0.  
+        wanrouter-v242.gz       patch for Linux kernel 2.4.2 and up.
+        wanrouter-v2034.gz      patch for Linux kernel 2.0.34
+        wanrouter-v2036.gz      patch for Linux kernel 2.0.36 and up. 
+
+/usr/local/wanrouter/patches/kdrivers:
+        Sources of the latest WANPIPE device drivers.
+        These are used to UPGRADE the linux kernel to the newest
+        version if the kernel source has already been pathced with
+        WANPIPE drivers.
+
+/usr/local/wanrouter/samples:
+        interface       sample interface configuration file
+        wanpipe1.cpri   CHDLC primary port
+        wanpipe2.csec   CHDLC secondary port
+        wanpipe1.fr     Frame Relay protocol
+        wanpipe1.ppp    PPP protocol ) 
+        wanpipe1.asy    CHDLC ASYNC protocol
+        wanpipe1.x25    X25 protocol
+        wanpipe1.stty   Sync TTY driver (Used by Kernel PPPD daemon)
+        wanpipe1.atty   Async TTY driver (Used by Kernel PPPD daemon)
+        wanrouter.rc    sample meta-configuration file
+
+/usr/local/wanrouter/util:
+        *               wan-tools utilities source code
+
+/usr/local/wanrouter/api/x25:
+        *               x25 api sample programs.
+/usr/local/wanrouter/api/chdlc:
+        *               chdlc api sample programs.
+/usr/local/wanrouter/api/fr:
+        *               fr api sample programs.
+/usr/local/wanrouter/config/wancfg:
+        wancfg          WANPIPE GUI configuration program.
+                        Creates wanpipe#.conf files. 
+/usr/local/wanrouter/config/cfgft1:
+        cfgft1          GUI CSU/DSU configuration program.
+
+/usr/include/linux:
+        wanrouter.h     router API definitions
+        wanpipe.h       WANPIPE API definitions
+        sdladrv.h       SDLA support module API definitions
+        sdlasfm.h       SDLA firmware module definitions
+        if_wanpipe.h    WANPIPE Socket definitions
+        if_wanpipe_common.h     WANPIPE Socket/Driver common definitions.
+        sdlapci.h       WANPIPE PCI definitions
+        
+
+/usr/src/linux/net/wanrouter:
+        *               wanrouter source code
+
+/var/log:
+        wanrouter       wanrouter start-up log (created by the Setup script)
+
+/var/lock:  (or /var/lock/subsys for RedHat)
+        wanrouter       wanrouter lock file (created by the Setup script)
+
+/usr/local/wanrouter/firmware:
+        fr514.sfm       Frame relay firmware for Sangoma S508/S514 card
+        cdual514.sfm    Dual Port Cisco HDLC firmware for Sangoma S508/S514 card
+        ppp514.sfm      PPP Firmware for Sangoma S508 and S514 cards
+        x25_508.sfm     X25 Firmware for Sangoma S508 card.
+
+
+REVISION HISTORY
+
+1.0.0   December 31, 1996       Initial version
+
+1.0.1   January 30, 1997        Status and statistics can be read via /proc
+                                filesystem entries.
+
+1.0.2   April 30, 1997          Added UDP management via monitors.
+
+1.0.3   June 3, 1997            UDP management for multiple boards using Frame
+                                Relay and PPP
+                                Enabled continuous transmission of Configure 
+                                Request Packet for PPP (for 508 only)
+                                Connection Timeout for PPP changed from 900 to 0
+                                Flow Control Problem fixed for Frame Relay
+
+1.0.4   July 10, 1997           S508/FT1 monitoring capability in fpipemon and
+                                ppipemon utilities.
+                                Configurable TTL for UDP packets.
+                                Multicast and Broadcast IP source addresses are
+                                silently discarded.
+
+1.0.5   July 28, 1997           Configurable T391,T392,N391,N392,N393 for Frame
+                                Relay in router.conf.
+                                Configurable Memory Address through router.conf 
+                                for Frame Relay, PPP and X.25. (commenting this
+                                out enables auto-detection).
+                                Fixed freeing up received buffers using kfree()
+                                for Frame Relay and X.25.
+                                Protect sdla_peek() by calling save_flags(),
+                                cli() and restore_flags().
+                                Changed number of Trace elements from 32 to 20
+                                Added DLCI specific data monitoring in FPIPEMON. 
+2.0.0   Nov 07, 1997            Implemented protection of RACE conditions by 
+                                critical flags for FRAME RELAY and PPP.
+                                DLCI List interrupt mode implemented.
+                                IPX support in FRAME RELAY and PPP.
+                                IPX Server Support (MARS)
+                                More driver specific stats included in FPIPEMON
+                                and PIPEMON.
+
+2.0.1   Nov 28, 1997            Bug Fixes for version 2.0.0.
+                                Protection of "enable_irq()" while 
+                                "disable_irq()" has been enabled from any other
+                                routine (for Frame Relay, PPP and X25).
+                                Added additional Stats for Fpipemon and Ppipemon
+                                Improved Load Sharing for multiple boards
+
+2.0.2   Dec 09, 1997            Support for PAP and CHAP for ppp has been
+                                implemented.
+
+2.0.3   Aug 15, 1998            New release supporting Cisco HDLC, CIR for Frame
+                                relay, Dynamic IP assignment for PPP and Inverse
+                                Arp support for Frame-relay.  Man Pages are 
+                                included for better support and a new utility
+                                for configuring FT1 cards.
+
+2.0.4   Dec 09, 1998            Dual Port support for Cisco HDLC.
+                                Support for HDLC (LAPB) API.
+                                Supports BiSync Streaming code for S502E 
+                                and S503 cards.
+                                Support for Streaming HDLC API.
+                                Provides a BSD socket interface for 
+                                creating applications using BiSync
+                                streaming.        
+
+2.0.5   Aug 04, 1999            CHDLC initializatin bug fix.
+                                PPP interrupt driven driver: 
+                                Fix to the PPP line hangup problem.
+                                New PPP firmware
+                                Added comments to the startup SYSTEM ERROR messages
+                                Xpipemon debugging application for the X25 protocol
+                                New USER_MANUAL.txt
+                                Fixed the odd boundary 4byte writes to the board.
+                                BiSync Streaming code has been taken out.  
+                                 Available as a patch.
+                                Streaming HDLC API has been taken out.  
+                                 Available as a patch.                 
+
+2.0.6   Aug 17, 1999            Increased debugging in statup scripts
+                                Fixed insallation bugs from 2.0.5
+                                Kernel patch works for both 2.2.10 and 2.2.11 kernels.
+                                There is no functional difference between the two packages         
+
+2.0.7   Aug 26, 1999            o  Merged X25API code into WANPIPE.
+                                o  Fixed a memeory leak for X25API
+                                o  Updated the X25API code for 2.2.X kernels.
+                                o  Improved NEM handling.   
+
+2.1.0   Oct 25, 1999            o New code for S514 PCI Card
+                                o New CHDLC and Frame Relay drivers
+                                o PPP and X25 are not supported in this release    
+
+2.1.1   Nov 30, 1999            o PPP support for S514 PCI Cards
+
+2.1.3   Apr 06, 2000            o Socket based x25api 
+                                o Socket based chdlc api
+                                o Socket based fr api
+                                o Dual Port Receive only CHDLC support.
+                                o Asynchronous CHDLC support (Secondary Port)
+                                o cfgft1 GUI csu/dsu configurator
+                                o wancfg GUI configuration file 
+                                  configurator.
+                                o Architectual directory changes.
+
+beta-2.1.4 Jul 2000             o Dynamic interface configuration:
+                                        Network interfaces reflect the state
+                                        of protocol layer.  If the protocol becomes
+                                        disconnected, driver will bring down
+                                        the interface.  Once the protocol reconnects
+                                        the interface will be brought up. 
+                                        
+                                        Note: This option is turned off by default.
+
+                                o Dynamic wanrouter setup using 'wanconfig':
+                                        wanconfig utility can be used to
+                                        shutdown,restart,start or reconfigure 
+                                        a virtual circuit dynamically.
+                                     
+                                        Frame Relay:  Each DLCI can be: 
+                                                      created,stopped,restarted and reconfigured
+                                                      dynamically using wanconfig.
+                                        
+                                                      ex: wanconfig card wanpipe1 dev wp1_fr16 up
+                                  
+                                o Wanrouter startup via command line arguments:
+                                        wanconfig also supports wanrouter startup via command line
+                                        arguments.  Thus, there is no need to create a wanpipe#.conf
+                                        configuration file.  
+
+                                o Socket based x25api update/bug fixes.
+                                        Added support for LCN numbers greater than 255.
+                                        Option to pass up modem messages.
+                                        Provided a PCI IRQ check, so a single S514
+                                        card is guaranteed to have a non-sharing interrupt.
+
+                                o Fixes to the wancfg utility.
+                                o New FT1 debugging support via *pipemon utilities.
+                                o Frame Relay ARP support Enabled.
+
+beta3-2.1.4 Jul 2000            o X25 M_BIT Problem fix.
+                                o Added the Multi-Port PPP
+                                  Updated utilites for the Multi-Port PPP.
+
+2.1.4   Aut 2000
+                                o In X25API:
+                                        Maximum packet an application can send
+                                        to the driver has been extended to 4096 bytes.
+
+                                        Fixed the x25 startup bug. Enable 
+                                        communications only after all interfaces
+                                        come up.  HIGH SVC/PVC is used to calculate
+                                        the number of channels.
+                                        Enable protocol only after all interfaces
+                                        are enabled.
+
+                                o Added an extra state to the FT1 config, kernel module.
+                                o Updated the pipemon debuggers.
+
+                                o Blocked the Multi-Port PPP from running on kernels
+                                  2.2.16 or greater, due to syncppp kernel module
+                                  change. 
+          
+beta1-2.1.5     Nov 15 2000
+                                o Fixed the MulitPort PPP Support for kernels 2.2.16 and above.
+                                  2.2.X kernels only
+
+                                o Secured the driver UDP debugging calls
+                                        - All illegal netowrk debugging calls are reported to
+                                          the log.
+                                        - Defined a set of allowed commands, all other denied.
+                                        
+                                o Cpipemon
+                                        - Added set FT1 commands to the cpipemon. Thus CSU/DSU
+                                          configuraiton can be performed using cpipemon.
+                                          All systems that cannot run cfgft1 GUI utility should
+                                          use cpipemon to configure the on board CSU/DSU.
+
+
+                                o Keyboard Led Monitor/Debugger
+                                        - A new utilty /usr/sbin/wpkbdmon uses keyboard leds
+                                          to convey operatinal statistic information of the 
+                                          Sangoma WANPIPE cards.
+                                        NUM_LOCK    = Line State  (On=connected,    Off=disconnected)
+                                        CAPS_LOCK   = Tx data     (On=transmitting, Off=no tx data)
+                                        SCROLL_LOCK = Rx data     (On=receiving,    Off=no rx data
+                                        
+                                o Hardware probe on module load and dynamic device allocation
+                                        - During WANPIPE module load, all Sangoma cards are probed
+                                          and found information is printed in the /var/log/messages.
+                                        - If no cards are found, the module load fails.
+                                        - Appropriate number of devices are dynamically loaded 
+                                          based on the number of Sangoma cards found.
+
+                                          Note: The kernel configuraiton option 
+                                                CONFIG_WANPIPE_CARDS has been taken out.
+                                        
+                                o Fixed the Frame Relay and Chdlc network interfaces so they are
+                                  compatible with libpcap libraries.  Meaning, tcpdump, snort,
+                                  ethereal, and all other packet sniffers and debuggers work on
+                                  all WANPIPE netowrk interfaces.
+                                        - Set the network interface encoding type to ARPHRD_PPP.
+                                          This tell the sniffers that data obtained from the
+                                          network interface is in pure IP format.
+                                  Fix for 2.2.X kernels only.
+                                
+                                o True interface encoding option for Frame Relay and CHDLC
+                                        - The above fix sets the network interface encoding
+                                          type to ARPHRD_PPP, however some customers use
+                                          the encoding interface type to determine the
+                                          protocol running.  Therefore, the TURE ENCODING
+                                          option will set the interface type back to the
+                                          original value.  
+
+                                          NOTE: If this option is used with Frame Relay and CHDLC
+                                                libpcap library support will be broken.  
+                                                i.e. tcpdump will not work.
+                                        Fix for 2.2.x Kernels only.
+                                                
+                                o Ethernet Bridgind over Frame Relay
+                                        - The Frame Relay bridging has been developed by 
+                                          Kristian Hoffmann and Mark Wells.  
+                                        - The Linux kernel bridge is used to send ethernet 
+                                          data over the frame relay links.
+                                        For 2.2.X Kernels only.
+
+                                o Added extensive 2.0.X support. Most new features of
+                                  2.1.5 for protocols Frame Relay, PPP and CHDLC are
+                                  supported under 2.0.X kernels. 
+
+beta1-2.2.0     Dec 30 2000
+                                o Updated drivers for 2.4.X kernels.
+                                o Updated drivers for SMP support.
+                                o X25API is now able to share PCI interrupts.
+                                o Took out a general polling routine that was used
+                                  only by X25API. 
+                                o Added appropriate locks to the dynamic reconfiguration
+                                  code.
+                                o Fixed a bug in the keyboard debug monitor.
+
+beta2-2.2.0     Jan 8 2001
+                                o Patches for 2.4.0 kernel
+                                o Patches for 2.2.18 kernel
+                                o Minor updates to PPP and CHLDC drivers.
+                                  Note: No functinal difference. 
+
+beta3-2.2.9     Jan 10 2001
+                                o I missed the 2.2.18 kernel patches in beta2-2.2.0
+                                  release.  They are included in this release.
+
+Stable Release
+2.2.0           Feb 01 2001
+                                o Bug fix in wancfg GUI configurator.
+                                        The edit function didn't work properly.
+
+
+bata1-2.2.1     Feb 09 2001
+                        o WANPIPE TTY Driver emulation. 
+                          Two modes of operation Sync and Async.
+                                Sync: Using the PPPD daemon, kernel SyncPPP layer
+                                      and the Wanpipe sync TTY driver: a PPP protocol 
+                                      connection can be established via Sangoma adapter, over
+                                      a T1 leased line.
+                        
+                                      The 2.4.0 kernel PPP layer supports MULTILINK
+                                      protocol, that can be used to bundle any number of Sangoma
+                                      adapters (T1 lines) into one, under a single IP address.
+                                      Thus, efficiently obtaining multiple T1 throughput. 
+
+                                      NOTE: The remote side must also implement MULTILINK PPP
+                                            protocol.
+
+                                Async:Using the PPPD daemon, kernel AsyncPPP layer
+                                      and the WANPIPE async TTY driver: a PPP protocol
+                                      connection can be established via Sangoma adapter and
+                                      a modem, over a telephone line.
+
+                                      Thus, the WANPIPE async TTY driver simulates a serial
+                                      TTY driver that would normally be used to interface the 
+                                      MODEM to the linux kernel.
+                                
+                        o WANPIPE PPP Backup Utility
+                                This utility will monitor the state of the PPP T1 line.
+                                In case of failure, a dial up connection will be established
+                                via pppd daemon, ether via a serial tty driver (serial port), 
+                                or a WANPIPE async TTY driver (in case serial port is unavailable).
+                                
+                                Furthermore, while in dial up mode, the primary PPP T1 link
+                                will be monitored for signs of life.  
+
+                                If the PPP T1 link comes back to life, the dial up connection
+                                will be shutdown and T1 line re-established.
+                        
+
+                        o New Setup installation script.
+                                Option to UPGRADE device drivers if the kernel source has
+                                already been patched with WANPIPE.
+
+                                Option to COMPILE WANPIPE modules against the currently 
+                                running kernel, thus no need for manual kernel and module
+                                re-compilatin.
+                        
+                        o Updates and Bug Fixes to wancfg utility.
+
+bata2-2.2.1     Feb 20 2001
+
+                        o Bug fixes to the CHDLC device drivers.
+                                The driver had compilation problems under kernels
+                                2.2.14 or lower.
+
+                        o Bug fixes to the Setup installation script.
+                                The device drivers compilation options didn't work
+                                properly.
+
+                        o Update to the wpbackupd daemon.  
+                                Optimized the cross-over times, between the primary
+                                link and the backup dialup.
+
+beta3-2.2.1     Mar 02 2001
+                        o Patches for 2.4.2 kernel.
+
+                        o Bug fixes to util/ make files.
+                        o Bug fixes to the Setup installation script.
+
+                        o Took out the backupd support and made it into
+                          as separate package.
+                          
+beta4-2.2.1     Mar 12 2001
+
+                o Fix to the Frame Relay Device driver.
+                        IPSAC sends a packet of zero length
+                        header to the frame relay driver.  The
+                        driver tries to push its own 2 byte header
+                        into the packet, which causes the driver to
+                        crash.
+
+                o Fix the WANPIPE re-configuration code.
+                        Bug was found by trying to run  the cfgft1 while the
+                        interface was already running.  
+
+                o Updates to cfgft1.
+                        Writes a wanpipe#.cfgft1 configuration file
+                        once the CSU/DSU is configured. This file can
+                        holds the current CSU/DSU configuration.
+
+
+
+>>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
+
+
diff --git a/Documentation/networking/wanpipe.txt b/Documentation/networking/wanpipe.txt
new file mode 100644
index 00000000000..aea20cd2a56
--- /dev/null
+++ b/Documentation/networking/wanpipe.txt
@@ -0,0 +1,622 @@
+------------------------------------------------------------------------------
+Linux WAN Router Utilities Package
+------------------------------------------------------------------------------
+Version 2.2.1 
+Mar 28, 2001
+Author: Nenad Corbic <ncorbic@sangoma.com>
+Copyright (c) 1995-2001 Sangoma Technologies Inc.
+------------------------------------------------------------------------------
+
+INTRODUCTION
+
+Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs)
+and/or stand-alone hosts over vast distances with data transfer rates
+significantly higher than those achievable with commonly used dial-up
+connections.
+
+Usually an external device called `WAN router' sitting on your local network
+or connected to your machine's serial port provides physical connection to
+WAN.  Although router's job may be as simple as taking your local network
+traffic, converting it to WAN format and piping it through the WAN link, these
+devices are notoriously expensive, with prices as much as 2 - 5 times higher
+then the price of a typical PC box.
+
+Alternatively, considering robustness and multitasking capabilities of Linux,
+an internal router can be built (most routers use some sort of stripped down
+Unix-like operating system anyway). With a number of relatively inexpensive WAN
+interface cards available on the market, a perfectly usable router can be
+built for less than half a price of an external router.  Yet a Linux box
+acting as a router can still be used for other purposes, such as fire-walling,
+running FTP, WWW or DNS server, etc.
+
+This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux
+operating system and provides generic hardware-independent services for such
+drivers.  Why can existing Linux network device interface not be used for
+this purpose?  Well, it can.  However, there are a few key differences between
+a typical network interface (e.g. Ethernet) and a WAN link.
+
+Many WAN protocols, such as X.25 and frame relay, allow for multiple logical
+connections (known as `virtual circuits' in X.25 terminology) over a single
+physical link.  Each such virtual circuit may (and almost always does) lead
+to a different geographical location and, therefore, different network.  As a
+result, it is the virtual circuit, not the physical link, that represents a
+route and, therefore, a network interface in Linux terms.
+
+To further complicate things, virtual circuits are usually volatile in nature
+(excluding so called `permanent' virtual circuits or PVCs).  With almost no
+time required to set up and tear down a virtual circuit, it is highly desirable
+to implement on-demand connections in order to minimize network charges.  So
+unlike a typical network driver, the WAN driver must be able to handle multiple
+network interfaces and cope as multiple virtual circuits come into existence
+and go away dynamically.
+ 
+Last, but not least, WAN configuration is much more complex than that of say
+Ethernet and may well amount to several dozens of parameters.  Some of them
+are "link-wide"  while others are virtual circuit-specific.  The same holds
+true for WAN statistics which is by far more extensive and extremely useful
+when troubleshooting WAN connections.  Extending the ifconfig utility to suit
+these needs may be possible, but does not seem quite reasonable.  Therefore, a
+WAN configuration utility and corresponding application programmer's interface
+is needed for this purpose.
+
+Most of these problems are taken care of by this module.  Its goal is to
+provide a user with more-or-less standard look and feel for all WAN devices and
+assist a WAN device driver writer by providing common services, such as:
+
+ o User-level interface via /proc file system
+ o Centralized configuration
+ o Device management (setup, shutdown, etc.)
+ o Network interface management (dynamic creation/destruction)
+ o Protocol encapsulation/decapsulation
+
+To ba able to use the Linux WAN Router you will also need a WAN Tools package
+available from
+
+        ftp.sangoma.com/pub/linux/current_wanpipe/wanpipe-X.Y.Z.tgz
+
+where vX.Y.Z represent the wanpipe version number.
+
+For technical questions and/or comments please e-mail to ncorbic@sangoma.com.
+For general inquiries please contact Sangoma Technologies Inc. by
+
+        Hotline:        1-800-388-2475  (USA and Canada, toll free)
+        Phone:          (905) 474-1990  ext: 106
+        Fax:            (905) 474-9223
+        E-mail:         dm@sangoma.com  (David Mandelstam)
+        WWW:            http://www.sangoma.com
+
+
+INSTALLATION
+
+Please read the WanpipeForLinux.pdf manual on how to 
+install the WANPIPE tools and drivers properly. 
+
+
+After installing wanpipe package: /usr/local/wanrouter/doc. 
+On the ftp.sangoma.com : /linux/current_wanpipe/doc
+
+
+COPYRIGHT AND LICENSING INFORMATION
+
+This program is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free Software
+Foundation; either version 2, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License along with
+this program; if not, write to the Free Software Foundation, Inc., 675 Mass
+Ave, Cambridge, MA 02139, USA.
+
+
+
+ACKNOWLEDGEMENTS
+
+This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed
+by Sangoma Technologies Inc. for Linux 2.0.x and 2.2.x.  Success of the WANPIPE
+together with the next major release of Linux kernel in summer 1996 commanded
+adequate changes to the WANPIPE code to take full advantage of new Linux
+features.
+
+Instead of continuing developing proprietary interface tied to Sangoma WAN
+cards, we decided to separate all hardware-independent code into a separate
+module and defined two levels of interfaces - one for user-level applications
+and another for kernel-level WAN drivers.  WANPIPE is now implemented as a
+WAN driver compliant with the WAN Link Driver interface.  Also a general
+purpose WAN configuration utility and a set of shell scripts was developed to 
+support WAN router at the user level.
+
+Many useful ideas concerning hardware-independent interface implementation
+were given by Mike McLagan <mike.mclagan@linux.org> and his implementation
+of the Frame Relay router and drivers for Sangoma cards (dlci/sdla).
+
+With the new implementation of the APIs being incorporated into the WANPIPE,
+a special thank goes to Alan Cox in providing insight into BSD sockets.
+
+Special thanks to all the WANPIPE users who performed field-testing, reported
+bugs and made valuable comments and suggestions that help us to improve this
+product.
+
+
+
+NEW IN THIS RELEASE
+
+        o Updated the WANCFG utility
+                Calls the pppconfig to configure the PPPD
+                for async connections.
+
+        o Added the PPPCONFIG utility
+                Used to configure the PPPD dameon for the
+                WANPIPE Async PPP and standard serial port.
+                The wancfg calls the pppconfig to configure
+                the pppd.
+
+        o Fixed the PCI autodetect feature.  
+                The SLOT 0 was used as an autodetect option
+                however, some high end PC's slot numbers start
+                from 0. 
+
+        o This release has been tested with the new backupd
+          daemon release.
+        
+
+PRODUCT COMPONENTS AND RELATED FILES
+
+/etc: (or user defined)
+        wanpipe1.conf   default router configuration file
+
+/lib/modules/X.Y.Z/misc:
+        wanrouter.o     router kernel loadable module
+        af_wanpipe.o    wanpipe api socket module
+
+/lib/modules/X.Y.Z/net:
+        sdladrv.o       Sangoma SDLA support module
+        wanpipe.o       Sangoma WANPIPE(tm) driver module
+
+/proc/net/wanrouter
+        Config          reads current router configuration
+        Status          reads current router status
+        {name}          reads WAN driver statistics
+
+/usr/sbin:
+        wanrouter       wanrouter start-up script
+        wanconfig       wanrouter configuration utility
+        sdladump        WANPIPE adapter memory dump utility
+        fpipemon        Monitor for Frame Relay
+        cpipemon        Monitor for Cisco HDLC
+        ppipemon        Monitor for PPP
+        xpipemon        Monitor for X25
+        wpkbdmon        WANPIPE keyboard led monitor/debugger
+
+/usr/local/wanrouter:
+        README          this file
+        COPYING         GNU General Public License
+        Setup           installation script
+        Filelist        distribution definition file
+        wanrouter.rc    meta-configuration file 
+                        (used by the Setup and wanrouter script)
+
+/usr/local/wanrouter/doc:
+        wanpipeForLinux.pdf     WAN Router User's Manual
+
+/usr/local/wanrouter/patches:
+        wanrouter-v2213.gz      patch for Linux kernels 2.2.11 up to 2.2.13.
+        wanrouter-v2214.gz      patch for Linux kernel 2.2.14. 
+        wanrouter-v2215.gz      patch for Linux kernels 2.2.15 to 2.2.17.
+        wanrouter-v2218.gz      patch for Linux kernels 2.2.18 and up.
+        wanrouter-v240.gz       patch for Linux kernel 2.4.0.  
+        wanrouter-v242.gz       patch for Linux kernel 2.4.2 and up.
+        wanrouter-v2034.gz      patch for Linux kernel 2.0.34
+        wanrouter-v2036.gz      patch for Linux kernel 2.0.36 and up. 
+
+/usr/local/wanrouter/patches/kdrivers:
+        Sources of the latest WANPIPE device drivers.
+        These are used to UPGRADE the linux kernel to the newest
+        version if the kernel source has already been pathced with
+        WANPIPE drivers.
+
+/usr/local/wanrouter/samples:
+        interface       sample interface configuration file
+        wanpipe1.cpri   CHDLC primary port
+        wanpipe2.csec   CHDLC secondary port
+        wanpipe1.fr     Frame Relay protocol
+        wanpipe1.ppp    PPP protocol ) 
+        wanpipe1.asy    CHDLC ASYNC protocol
+        wanpipe1.x25    X25 protocol
+        wanpipe1.stty   Sync TTY driver (Used by Kernel PPPD daemon)
+        wanpipe1.atty   Async TTY driver (Used by Kernel PPPD daemon)
+        wanrouter.rc    sample meta-configuration file
+
+/usr/local/wanrouter/util:
+        *               wan-tools utilities source code
+
+/usr/local/wanrouter/api/x25:
+        *               x25 api sample programs.
+/usr/local/wanrouter/api/chdlc:
+        *               chdlc api sample programs.
+/usr/local/wanrouter/api/fr:
+        *               fr api sample programs.
+/usr/local/wanrouter/config/wancfg:
+        wancfg          WANPIPE GUI configuration program.
+                        Creates wanpipe#.conf files. 
+/usr/local/wanrouter/config/cfgft1:
+        cfgft1          GUI CSU/DSU configuration program.
+
+/usr/include/linux:
+        wanrouter.h     router API definitions
+        wanpipe.h       WANPIPE API definitions
+        sdladrv.h       SDLA support module API definitions
+        sdlasfm.h       SDLA firmware module definitions
+        if_wanpipe.h    WANPIPE Socket definitions
+        if_wanpipe_common.h     WANPIPE Socket/Driver common definitions.
+        sdlapci.h       WANPIPE PCI definitions
+        
+
+/usr/src/linux/net/wanrouter:
+        *               wanrouter source code
+
+/var/log:
+        wanrouter       wanrouter start-up log (created by the Setup script)
+
+/var/lock:  (or /var/lock/subsys for RedHat)
+        wanrouter       wanrouter lock file (created by the Setup script)
+
+/usr/local/wanrouter/firmware:
+        fr514.sfm       Frame relay firmware for Sangoma S508/S514 card
+        cdual514.sfm    Dual Port Cisco HDLC firmware for Sangoma S508/S514 card
+        ppp514.sfm      PPP Firmware for Sangoma S508 and S514 cards
+        x25_508.sfm     X25 Firmware for Sangoma S508 card.
+
+
+REVISION HISTORY
+
+1.0.0   December 31, 1996       Initial version
+
+1.0.1   January 30, 1997        Status and statistics can be read via /proc
+                                filesystem entries.
+
+1.0.2   April 30, 1997          Added UDP management via monitors.
+
+1.0.3   June 3, 1997            UDP management for multiple boards using Frame
+                                Relay and PPP
+                                Enabled continuous transmission of Configure 
+                                Request Packet for PPP (for 508 only)
+                                Connection Timeout for PPP changed from 900 to 0
+                                Flow Control Problem fixed for Frame Relay
+
+1.0.4   July 10, 1997           S508/FT1 monitoring capability in fpipemon and
+                                ppipemon utilities.
+                                Configurable TTL for UDP packets.
+                                Multicast and Broadcast IP source addresses are
+                                silently discarded.
+
+1.0.5   July 28, 1997           Configurable T391,T392,N391,N392,N393 for Frame
+                                Relay in router.conf.
+                                Configurable Memory Address through router.conf 
+                                for Frame Relay, PPP and X.25. (commenting this
+                                out enables auto-detection).
+                                Fixed freeing up received buffers using kfree()
+                                for Frame Relay and X.25.
+                                Protect sdla_peek() by calling save_flags(),
+                                cli() and restore_flags().
+                                Changed number of Trace elements from 32 to 20
+                                Added DLCI specific data monitoring in FPIPEMON. 
+2.0.0   Nov 07, 1997            Implemented protection of RACE conditions by 
+                                critical flags for FRAME RELAY and PPP.
+                                DLCI List interrupt mode implemented.
+                                IPX support in FRAME RELAY and PPP.
+                                IPX Server Support (MARS)
+                                More driver specific stats included in FPIPEMON
+                                and PIPEMON.
+
+2.0.1   Nov 28, 1997            Bug Fixes for version 2.0.0.
+                                Protection of "enable_irq()" while 
+                                "disable_irq()" has been enabled from any other
+                                routine (for Frame Relay, PPP and X25).
+                                Added additional Stats for Fpipemon and Ppipemon
+                                Improved Load Sharing for multiple boards
+
+2.0.2   Dec 09, 1997            Support for PAP and CHAP for ppp has been
+                                implemented.
+
+2.0.3   Aug 15, 1998            New release supporting Cisco HDLC, CIR for Frame
+                                relay, Dynamic IP assignment for PPP and Inverse
+                                Arp support for Frame-relay.  Man Pages are 
+                                included for better support and a new utility
+                                for configuring FT1 cards.
+
+2.0.4   Dec 09, 1998            Dual Port support for Cisco HDLC.
+                                Support for HDLC (LAPB) API.
+                                Supports BiSync Streaming code for S502E 
+                                and S503 cards.
+                                Support for Streaming HDLC API.
+                                Provides a BSD socket interface for 
+                                creating applications using BiSync
+                                streaming.        
+
+2.0.5   Aug 04, 1999            CHDLC initializatin bug fix.
+                                PPP interrupt driven driver: 
+                                Fix to the PPP line hangup problem.
+                                New PPP firmware
+                                Added comments to the startup SYSTEM ERROR messages
+                                Xpipemon debugging application for the X25 protocol
+                                New USER_MANUAL.txt
+                                Fixed the odd boundary 4byte writes to the board.
+                                BiSync Streaming code has been taken out.  
+                                 Available as a patch.
+                                Streaming HDLC API has been taken out.  
+                                 Available as a patch.                 
+
+2.0.6   Aug 17, 1999            Increased debugging in statup scripts
+                                Fixed insallation bugs from 2.0.5
+                                Kernel patch works for both 2.2.10 and 2.2.11 kernels.
+                                There is no functional difference between the two packages         
+
+2.0.7   Aug 26, 1999            o  Merged X25API code into WANPIPE.
+                                o  Fixed a memeory leak for X25API
+                                o  Updated the X25API code for 2.2.X kernels.
+                                o  Improved NEM handling.   
+
+2.1.0   Oct 25, 1999            o New code for S514 PCI Card
+                                o New CHDLC and Frame Relay drivers
+                                o PPP and X25 are not supported in this release    
+
+2.1.1   Nov 30, 1999            o PPP support for S514 PCI Cards
+
+2.1.3   Apr 06, 2000            o Socket based x25api 
+                                o Socket based chdlc api
+                                o Socket based fr api
+                                o Dual Port Receive only CHDLC support.
+                                o Asynchronous CHDLC support (Secondary Port)
+                                o cfgft1 GUI csu/dsu configurator
+                                o wancfg GUI configuration file 
+                                  configurator.
+                                o Architectual directory changes.
+
+beta-2.1.4 Jul 2000             o Dynamic interface configuration:
+                                        Network interfaces reflect the state
+                                        of protocol layer.  If the protocol becomes
+                                        disconnected, driver will bring down
+                                        the interface.  Once the protocol reconnects
+                                        the interface will be brought up. 
+                                        
+                                        Note: This option is turned off by default.
+
+                                o Dynamic wanrouter setup using 'wanconfig':
+                                        wanconfig utility can be used to
+                                        shutdown,restart,start or reconfigure 
+                                        a virtual circuit dynamically.
+                                     
+                                        Frame Relay:  Each DLCI can be: 
+                                                      created,stopped,restarted and reconfigured
+                                                      dynamically using wanconfig.
+                                        
+                                                      ex: wanconfig card wanpipe1 dev wp1_fr16 up
+                                  
+                                o Wanrouter startup via command line arguments:
+                                        wanconfig also supports wanrouter startup via command line
+                                        arguments.  Thus, there is no need to create a wanpipe#.conf
+                                        configuration file.  
+
+                                o Socket based x25api update/bug fixes.
+                                        Added support for LCN numbers greater than 255.
+                                        Option to pass up modem messages.
+                                        Provided a PCI IRQ check, so a single S514
+                                        card is guaranteed to have a non-sharing interrupt.
+
+                                o Fixes to the wancfg utility.
+                                o New FT1 debugging support via *pipemon utilities.
+                                o Frame Relay ARP support Enabled.
+
+beta3-2.1.4 Jul 2000            o X25 M_BIT Problem fix.
+                                o Added the Multi-Port PPP
+                                  Updated utilites for the Multi-Port PPP.
+
+2.1.4   Aut 2000
+                                o In X25API:
+                                        Maximum packet an application can send
+                                        to the driver has been extended to 4096 bytes.
+
+                                        Fixed the x25 startup bug. Enable 
+                                        communications only after all interfaces
+                                        come up.  HIGH SVC/PVC is used to calculate
+                                        the number of channels.
+                                        Enable protocol only after all interfaces
+                                        are enabled.
+
+                                o Added an extra state to the FT1 config, kernel module.
+                                o Updated the pipemon debuggers.
+
+                                o Blocked the Multi-Port PPP from running on kernels
+                                  2.2.16 or greater, due to syncppp kernel module
+                                  change. 
+          
+beta1-2.1.5     Nov 15 2000
+                                o Fixed the MulitPort PPP Support for kernels 2.2.16 and above.
+                                  2.2.X kernels only
+
+                                o Secured the driver UDP debugging calls
+                                        - All illegal netowrk debugging calls are reported to
+                                          the log.
+                                        - Defined a set of allowed commands, all other denied.
+                                        
+                                o Cpipemon
+                                        - Added set FT1 commands to the cpipemon. Thus CSU/DSU
+                                          configuraiton can be performed using cpipemon.
+                                          All systems that cannot run cfgft1 GUI utility should
+                                          use cpipemon to configure the on board CSU/DSU.
+
+
+                                o Keyboard Led Monitor/Debugger
+                                        - A new utilty /usr/sbin/wpkbdmon uses keyboard leds
+                                          to convey operatinal statistic information of the 
+                                          Sangoma WANPIPE cards.
+                                        NUM_LOCK    = Line State  (On=connected,    Off=disconnected)
+                                        CAPS_LOCK   = Tx data     (On=transmitting, Off=no tx data)
+                                        SCROLL_LOCK = Rx data     (On=receiving,    Off=no rx data
+                                        
+                                o Hardware probe on module load and dynamic device allocation
+                                        - During WANPIPE module load, all Sangoma cards are probed
+                                          and found information is printed in the /var/log/messages.
+                                        - If no cards are found, the module load fails.
+                                        - Appropriate number of devices are dynamically loaded 
+                                          based on the number of Sangoma cards found.
+
+                                          Note: The kernel configuraiton option 
+                                                CONFIG_WANPIPE_CARDS has been taken out.
+                                        
+                                o Fixed the Frame Relay and Chdlc network interfaces so they are
+                                  compatible with libpcap libraries.  Meaning, tcpdump, snort,
+                                  ethereal, and all other packet sniffers and debuggers work on
+                                  all WANPIPE netowrk interfaces.
+                                        - Set the network interface encoding type to ARPHRD_PPP.
+                                          This tell the sniffers that data obtained from the
+                                          network interface is in pure IP format.
+                                  Fix for 2.2.X kernels only.
+                                
+                                o True interface encoding option for Frame Relay and CHDLC
+                                        - The above fix sets the network interface encoding
+                                          type to ARPHRD_PPP, however some customers use
+                                          the encoding interface type to determine the
+                                          protocol running.  Therefore, the TURE ENCODING
+                                          option will set the interface type back to the
+                                          original value.  
+
+                                          NOTE: If this option is used with Frame Relay and CHDLC
+                                                libpcap library support will be broken.  
+                                                i.e. tcpdump will not work.
+                                        Fix for 2.2.x Kernels only.
+                                                
+                                o Ethernet Bridgind over Frame Relay
+                                        - The Frame Relay bridging has been developed by 
+                                          Kristian Hoffmann and Mark Wells.  
+                                        - The Linux kernel bridge is used to send ethernet 
+                                          data over the frame relay links.
+                                        For 2.2.X Kernels only.
+
+                                o Added extensive 2.0.X support. Most new features of
+                                  2.1.5 for protocols Frame Relay, PPP and CHDLC are
+                                  supported under 2.0.X kernels. 
+
+beta1-2.2.0     Dec 30 2000
+                                o Updated drivers for 2.4.X kernels.
+                                o Updated drivers for SMP support.
+                                o X25API is now able to share PCI interrupts.
+                                o Took out a general polling routine that was used
+                                  only by X25API. 
+                                o Added appropriate locks to the dynamic reconfiguration
+                                  code.
+                                o Fixed a bug in the keyboard debug monitor.
+
+beta2-2.2.0     Jan 8 2001
+                                o Patches for 2.4.0 kernel
+                                o Patches for 2.2.18 kernel
+                                o Minor updates to PPP and CHLDC drivers.
+                                  Note: No functinal difference. 
+
+beta3-2.2.9     Jan 10 2001
+                                o I missed the 2.2.18 kernel patches in beta2-2.2.0
+                                  release.  They are included in this release.
+
+Stable Release
+2.2.0           Feb 01 2001
+                                o Bug fix in wancfg GUI configurator.
+                                        The edit function didn't work properly.
+
+
+bata1-2.2.1     Feb 09 2001
+                        o WANPIPE TTY Driver emulation. 
+                          Two modes of operation Sync and Async.
+                                Sync: Using the PPPD daemon, kernel SyncPPP layer
+                                      and the Wanpipe sync TTY driver: a PPP protocol 
+                                      connection can be established via Sangoma adapter, over
+                                      a T1 leased line.
+                        
+                                      The 2.4.0 kernel PPP layer supports MULTILINK
+                                      protocol, that can be used to bundle any number of Sangoma
+                                      adapters (T1 lines) into one, under a single IP address.
+                                      Thus, efficiently obtaining multiple T1 throughput. 
+
+                                      NOTE: The remote side must also implement MULTILINK PPP
+                                            protocol.
+
+                                Async:Using the PPPD daemon, kernel AsyncPPP layer
+                                      and the WANPIPE async TTY driver: a PPP protocol
+                                      connection can be established via Sangoma adapter and
+                                      a modem, over a telephone line.
+
+                                      Thus, the WANPIPE async TTY driver simulates a serial
+                                      TTY driver that would normally be used to interface the 
+                                      MODEM to the linux kernel.
+                                
+                        o WANPIPE PPP Backup Utility
+                                This utility will monitor the state of the PPP T1 line.
+                                In case of failure, a dial up connection will be established
+                                via pppd daemon, ether via a serial tty driver (serial port), 
+                                or a WANPIPE async TTY driver (in case serial port is unavailable).
+                                
+                                Furthermore, while in dial up mode, the primary PPP T1 link
+                                will be monitored for signs of life.  
+
+                                If the PPP T1 link comes back to life, the dial up connection
+                                will be shutdown and T1 line re-established.
+                        
+
+                        o New Setup installation script.
+                                Option to UPGRADE device drivers if the kernel source has
+                                already been patched with WANPIPE.
+
+                                Option to COMPILE WANPIPE modules against the currently 
+                                running kernel, thus no need for manual kernel and module
+                                re-compilatin.
+                        
+                        o Updates and Bug Fixes to wancfg utility.
+
+bata2-2.2.1     Feb 20 2001
+
+                        o Bug fixes to the CHDLC device drivers.
+                                The driver had compilation problems under kernels
+                                2.2.14 or lower.
+
+                        o Bug fixes to the Setup installation script.
+                                The device drivers compilation options didn't work
+                                properly.
+
+                        o Update to the wpbackupd daemon.  
+                                Optimized the cross-over times, between the primary
+                                link and the backup dialup.
+
+beta3-2.2.1     Mar 02 2001
+                        o Patches for 2.4.2 kernel.
+
+                        o Bug fixes to util/ make files.
+                        o Bug fixes to the Setup installation script.
+
+                        o Took out the backupd support and made it into
+                          as separate package.
+                          
+beta4-2.2.1     Mar 12 2001
+
+                o Fix to the Frame Relay Device driver.
+                        IPSAC sends a packet of zero length
+                        header to the frame relay driver.  The
+                        driver tries to push its own 2 byte header
+                        into the packet, which causes the driver to
+                        crash.
+
+                o Fix the WANPIPE re-configuration code.
+                        Bug was found by trying to run  the cfgft1 while the
+                        interface was already running.  
+
+                o Updates to cfgft1.
+                        Writes a wanpipe#.cfgft1 configuration file
+                        once the CSU/DSU is configured. This file can
+                        holds the current CSU/DSU configuration.
+
+
+
+>>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
+
+
diff --git a/Documentation/networking/wavelan.txt b/Documentation/networking/wavelan.txt
new file mode 100644
index 00000000000..c1acf5eb371
--- /dev/null
+++ b/Documentation/networking/wavelan.txt
@@ -0,0 +1,73 @@
+        The Wavelan drivers saga
+        ------------------------
+
+        By Jean Tourrilhes <jt@hpl.hp.com>
+
+        The Wavelan is a Radio network adapter designed by
+Lucent. Under this generic name is hidden quite a variety of hardware,
+and many Linux driver to support it.
+        The get the full story on Wireless LANs, please consult :
+                http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/
+
+"wavelan" driver (old ISA Wavelan)
+----------------
+        o Config :      Network device -> Wireless LAN -> AT&T WaveLAN
+        o Location :    .../drivers/net/wavelan*
+        o in-line doc : .../drivers/net/wavelan.p.h
+        o on-line doc :
+            http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html
+
+        This is the driver for the ISA version of the first generation
+of the Wavelan, now discontinued. The device is 2 Mb/s, composed of a
+Intel 82586 controller and a Lucent Modem, and is NOT 802.11 compliant.
+        The driver has been tested with the following hardware :
+        o Wavelan ISA 915 MHz (full length ISA card) 
+        o Wavelan ISA 915 MHz 2.0 (half length ISA card) 
+        o Wavelan ISA 2.4 GHz (full length ISA card, fixed frequency) 
+        o Wavelan ISA 2.4 GHz 2.0 (half length ISA card, frequency selectable) 
+        o Above cards with the optional DES encryption feature 
+
+"wavelan_cs" driver (old Pcmcia Wavelan)
+-------------------
+        o Config :      Network device -> PCMCIA network ->
+                                Pcmcia Wireless LAN -> AT&T/Lucent WaveLAN
+        o Location :    .../drivers/net/pcmcia/wavelan*
+        o in-line doc : .../drivers/net/pcmcia/wavelan_cs.h
+        o on-line doc :
+            http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html
+
+        This is the driver for the PCMCIA version of the first
+generation of the Wavelan, now discontinued. The device is 2 Mb/s,
+composed of a Intel 82593 controller (totally different from the 82586)
+and a Lucent Modem, and NOT 802.11 compatible.
+        The driver has been tested with the following hardware :
+        o Wavelan Pcmcia 915 MHz 2.0 (Pcmcia card + separate
+                                        modem/antenna block) 
+        o Wavelan Pcmcia 2.4 GHz 2.0 (Pcmcia card + separate
+                                        modem/antenna block) 
+
+"wvlan_cs" driver (Wavelan IEEE, GPL)
+-----------------
+        o Config :      Not yet in kernel
+        o Location :    Pcmcia package 3.1.10+
+        o on-line doc : http://www.fasta.fh-dortmund.de/users/andy/wvlan/
+
+        This is the driver for the current generation of Wavelan IEEE,
+which is 802.11 compatible. Depending on version, it is 2 Mb/s or 11
+Mb/s, with or without encryption, all implemented in Lucent specific
+DSP (the Hermes).
+        This is a GPL full source PCMCIA driver (ISA is just a Pcmcia
+card with ISA-Pcmcia bridge).
+
+"wavelan2_cs" driver (Wavelan IEEE, binary)
+--------------------
+        o Config :      Not yet in kernel
+        o Location :    ftp://sourceforge.org/pcmcia/contrib/
+
+        This driver support exactly the same hardware as the previous
+driver, the main difference is that it is based on a binary library
+and supported by Lucent.
+
+        I hope it clears the confusion ;-)
+
+        Jean
diff --git a/Documentation/networking/x25-iface.txt b/Documentation/networking/x25-iface.txt
new file mode 100644
index 00000000000..975cc87ebdd
--- /dev/null
+++ b/Documentation/networking/x25-iface.txt
@@ -0,0 +1,123 @@
+                        X.25 Device Driver Interface 1.1
+
+                           Jonathan Naylor 26.12.96
+
+This is a description of the messages to be passed between the X.25 Packet
+Layer and the X.25 device driver. They are designed to allow for the easy
+setting of the LAPB mode from within the Packet Layer.
+
+The X.25 device driver will be coded normally as per the Linux device driver
+standards. Most X.25 device drivers will be moderately similar to the
+already existing Ethernet device drivers. However unlike those drivers, the
+X.25 device driver has a state associated with it, and this information
+needs to be passed to and from the Packet Layer for proper operation.
+
+All messages are held in sk_buff's just like real data to be transmitted
+over the LAPB link. The first byte of the skbuff indicates the meaning of
+the rest of the skbuff, if any more information does exist.
+
+
+Packet Layer to Device Driver
+-----------------------------
+
+First Byte = 0x00
+
+This indicates that the rest of the skbuff contains data to be transmitted
+over the LAPB link. The LAPB link should already exist before any data is
+passed down.
+
+First Byte = 0x01
+
+Establish the LAPB link. If the link is already established then the connect
+confirmation message should be returned as soon as possible.
+
+First Byte = 0x02
+
+Terminate the LAPB link. If it is already disconnected then the disconnect
+confirmation message should be returned as soon as possible.
+
+First Byte = 0x03
+
+LAPB parameters. To be defined.
+
+
+Device Driver to Packet Layer
+-----------------------------
+
+First Byte = 0x00
+
+This indicates that the rest of the skbuff contains data that has been
+received over the LAPB link.
+
+First Byte = 0x01
+
+LAPB link has been established. The same message is used for both a LAPB
+link connect_confirmation and a connect_indication.
+
+First Byte = 0x02
+
+LAPB link has been terminated. This same message is used for both a LAPB
+link disconnect_confirmation and a disconnect_indication.
+
+First Byte = 0x03
+
+LAPB parameters. To be defined.
+
+
+
+Possible Problems
+=================
+
+(Henner Eisen, 2000-10-28)
+
+The X.25 packet layer protocol depends on a reliable datalink service.
+The LAPB protocol provides such reliable service. But this reliability
+is not preserved by the Linux network device driver interface:
+
+- With Linux 2.4.x (and above) SMP kernels, packet ordering is not
+  preserved. Even if a device driver calls netif_rx(skb1) and later
+  netif_rx(skb2), skb2 might be delivered to the network layer
+  earlier that skb1.
+- Data passed upstream by means of netif_rx() might be dropped by the
+  kernel if the backlog queue is congested.
+
+The X.25 packet layer protocol will detect this and reset the virtual
+call in question. But many upper layer protocols are not designed to
+handle such N-Reset events gracefully. And frequent N-Reset events
+will always degrade performance.
+
+Thus, driver authors should make netif_rx() as reliable as possible:
+
+SMP re-ordering will not occur if the driver's interrupt handler is
+always executed on the same CPU. Thus,
+
+- Driver authors should use irq affinity for the interrupt handler.
+
+The probability of packet loss due to backlog congestion can be
+reduced by the following measures or a combination thereof:
+
+(1) Drivers for kernel versions 2.4.x and above should always check the
+    return value of netif_rx(). If it returns NET_RX_DROP, the
+    driver's LAPB protocol must not confirm reception of the frame
+    to the peer. 
+    This will reliably suppress packet loss. The LAPB protocol will
+    automatically cause the peer to re-transmit the dropped packet
+    later.
+    The lapb module interface was modified to support this. Its
+    data_indication() method should now transparently pass the
+    netif_rx() return value to the (lapb mopdule) caller.
+(2) Drivers for kernel versions 2.2.x should always check the global
+    variable netdev_dropping when a new frame is received. The driver
+    should only call netif_rx() if netdev_dropping is zero. Otherwise
+    the driver should not confirm delivery of the frame and drop it.
+    Alternatively, the driver can queue the frame internally and call
+    netif_rx() later when netif_dropping is 0 again. In that case, delivery
+    confirmation should also be deferred such that the internal queue
+    cannot grow to much.
+    This will not reliably avoid packet loss, but the probability
+    of packet loss in netif_rx() path will be significantly reduced.
+(3) Additionally, driver authors might consider to support
+    CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up
+    when a previously congested backlog queue becomes empty again.
+    The driver could uses this for flow-controlling the peer by means
+    of the LAPB protocol's flow-control service.
diff --git a/Documentation/networking/x25.txt b/Documentation/networking/x25.txt
new file mode 100644
index 00000000000..c91c6d7159f
--- /dev/null
+++ b/Documentation/networking/x25.txt
@@ -0,0 +1,44 @@
+Linux X.25 Project
+
+As my third year dissertation at University I have taken it upon myself to
+write an X.25 implementation for Linux. My aim is to provide a complete X.25
+Packet Layer and a LAPB module to allow for "normal" X.25 to be run using
+Linux. There are two sorts of X.25 cards available, intelligent ones that
+implement LAPB on the card itself, and unintelligent ones that simply do
+framing, bit-stuffing and checksumming. These both need to be handled by the
+system.
+
+I therefore decided to write the implementation such that as far as the
+Packet Layer is concerned, the link layer was being performed by a lower
+layer of the Linux kernel and therefore it did not concern itself with
+implementation of LAPB. Therefore the LAPB modules would be called by
+unintelligent X.25 card drivers and not by intelligent ones, this would
+provide a uniform device driver interface, and simplify configuration.
+
+To confuse matters a little, an 802.2 LLC implementation for Linux is being
+written which will allow X.25 to be run over an Ethernet (or Token Ring) and
+conform with the JNT "Pink Book", this will have a different interface to
+the Packet Layer but there will be no confusion since the class of device
+being served by the LLC will be completely separate from LAPB. The LLC
+implementation is being done as part of another protocol project (SNA) and
+by a different author.
+
+Just when you thought that it could not become more confusing, another
+option appeared, XOT. This allows X.25 Packet Layer frames to operate over
+the Internet using TCP/IP as a reliable link layer. RFC1613 specifies the
+format and behaviour of the protocol. If time permits this option will also
+be actively considered.
+
+A linux-x25 mailing list has been created at vger.kernel.org to support the
+development and use of Linux X.25. It is early days yet, but interested
+parties are welcome to subscribe to it. Just send a message to
+majordomo@vger.kernel.org with the following in the message body:
+
+subscribe linux-x25
+end
+
+The contents of the Subject line are ignored.
+
+Jonathan
+
+g4klx@g4klx.demon.co.uk
diff --git a/Documentation/networking/z8530drv.txt b/Documentation/networking/z8530drv.txt
new file mode 100644
index 00000000000..2206abbc3e1
--- /dev/null
+++ b/Documentation/networking/z8530drv.txt
@@ -0,0 +1,657 @@
+This is a subset of the documentation. To use this driver you MUST have the
+full package from:
+
+Internet:
+=========
+
+1. ftp://ftp.ccac.rwth-aachen.de/pub/jr/z8530drv-utils_3.0-3.tar.gz
+
+2. ftp://ftp.pspt.fi/pub/ham/linux/ax25/z8530drv-utils_3.0-3.tar.gz
+
+Please note that the information in this document may be hopelessly outdated.
+A new version of the documentation, along with links to other important
+Linux Kernel AX.25 documentation and programs, is available on
+http://yaina.de/jreuter
+
+-----------------------------------------------------------------------------
+
+
+         SCC.C - Linux driver for Z8530 based HDLC cards for AX.25      
+
+   ********************************************************************
+
+        (c) 1993,2000 by Joerg Reuter DL1BKE <jreuter@yaina.de>
+
+        portions (c) 1993 Guido ten Dolle PE1NNZ
+
+        for the complete copyright notice see >> Copying.Z8530DRV <<
+
+   ******************************************************************** 
+
+
+1. Initialization of the driver
+===============================
+
+To use the driver, 3 steps must be performed:
+
+     1. if compiled as module: loading the module
+     2. Setup of hardware, MODEM and KISS parameters with sccinit
+     3. Attach each channel to the Linux kernel AX.25 with "ifconfig"
+
+Unlike the versions below 2.4 this driver is a real network device
+driver. If you want to run xNOS instead of our fine kernel AX.25
+use a 2.x version (available from above sites) or read the
+AX.25-HOWTO on how to emulate a KISS TNC on network device drivers.
+
+
+1.1 Loading the module
+======================
+
+(If you're going to compile the driver as a part of the kernel image,
+ skip this chapter and continue with 1.2)
+
+Before you can use a module, you'll have to load it with
+
+        insmod scc.o
+
+please read 'man insmod' that comes with module-init-tools.
+
+You should include the insmod in one of the /etc/rc.d/rc.* files,
+and don't forget to insert a call of sccinit after that. It
+will read your /etc/z8530drv.conf.
+
+1.2. /etc/z8530drv.conf
+=======================
+
+To setup all parameters you must run /sbin/sccinit from one
+of your rc.*-files. This has to be done BEFORE you can
+"ifconfig" an interface. Sccinit reads the file /etc/z8530drv.conf
+and sets the hardware, MODEM and KISS parameters. A sample file is
+delivered with this package. Change it to your needs.
+
+The file itself consists of two main sections.
+
+1.2.1 configuration of hardware parameters
+==========================================
+
+The hardware setup section defines the following parameters for each
+Z8530:
+
+chip    1
+data_a  0x300                   # data port A
+ctrl_a  0x304                   # control port A
+data_b  0x301                   # data port B
+ctrl_b  0x305                   # control port B
+irq     5                       # IRQ No. 5
+pclock  4915200                 # clock
+board   BAYCOM                  # hardware type
+escc    no                      # enhanced SCC chip? (8580/85180/85280)
+vector  0                       # latch for interrupt vector
+special no                      # address of special function register
+option  0                       # option to set via sfr
+
+
+chip    - this is just a delimiter to make sccinit a bit simpler to
+          program. A parameter has no effect.
+
+data_a  - the address of the data port A of this Z8530 (needed)
+ctrl_a  - the address of the control port A (needed)
+data_b  - the address of the data port B (needed)
+ctrl_b  - the address of the control port B (needed)
+
+irq     - the used IRQ for this chip. Different chips can use different
+          IRQs or the same. If they share an interrupt, it needs to be
+          specified within one chip-definition only.
+
+pclock  - the clock at the PCLK pin of the Z8530 (option, 4915200 is
+          default), measured in Hertz
+
+board   - the "type" of the board:
+
+           SCC type                 value
+           ---------------------------------
+           PA0HZP SCC card          PA0HZP
+           EAGLE card               EAGLE
+           PC100 card               PC100
+           PRIMUS-PC (DG9BL) card   PRIMUS
+           BayCom (U)SCC card       BAYCOM
+
+escc    - if you want support for ESCC chips (8580, 85180, 85280), set
+          this to "yes" (option, defaults to "no")
+
+vector  - address of the vector latch (aka "intack port") for PA0HZP
+          cards. There can be only one vector latch for all chips!
+          (option, defaults to 0)
+
+special - address of the special function register on several cards.
+          (option, defaults to 0)
+
+option  - The value you write into that register (option, default is 0)
+
+You can specify up to four chips (8 channels). If this is not enough,
+just change
+
+        #define MAXSCC 4
+
+to a higher value.
+
+Example for the BAYCOM USCC:
+----------------------------
+
+chip    1
+data_a  0x300                   # data port A
+ctrl_a  0x304                   # control port A
+data_b  0x301                   # data port B
+ctrl_b  0x305                   # control port B
+irq     5                       # IRQ No. 5 (#)
+board   BAYCOM                  # hardware type (*)
+#
+# SCC chip 2
+#
+chip    2
+data_a  0x302
+ctrl_a  0x306
+data_b  0x303
+ctrl_b  0x307
+board   BAYCOM
+
+An example for a PA0HZP card:
+-----------------------------
+
+chip 1
+data_a 0x153
+data_b 0x151
+ctrl_a 0x152
+ctrl_b 0x150
+irq 9
+pclock 4915200
+board PA0HZP
+vector 0x168
+escc no
+#
+#
+#
+chip 2
+data_a 0x157
+data_b 0x155
+ctrl_a 0x156
+ctrl_b 0x154
+irq 9
+pclock 4915200
+board PA0HZP
+vector 0x168
+escc no
+
+A DRSI would should probably work with this:
+--------------------------------------------
+(actually: two DRSI cards...)
+
+chip 1
+data_a 0x303
+data_b 0x301
+ctrl_a 0x302
+ctrl_b 0x300
+irq 7
+pclock 4915200
+board DRSI
+escc no
+#
+#
+#
+chip 2
+data_a 0x313
+data_b 0x311
+ctrl_a 0x312
+ctrl_b 0x310
+irq 7
+pclock 4915200
+board DRSI
+escc no
+
+Note that you cannot use the on-board baudrate generator off DRSI
+cards. Use "mode dpll" for clock source (see below).
+
+This is based on information provided by Mike Bilow (and verified
+by Paul Helay)
+
+The utility "gencfg"
+--------------------
+
+If you only know the parameters for the PE1CHL driver for DOS,
+run gencfg. It will generate the correct port addresses (I hope).
+Its parameters are exactly the same as the ones you use with
+the "attach scc" command in net, except that the string "init" must 
+not appear. Example:
+
+gencfg 2 0x150 4 2 0 1 0x168 9 4915200 
+
+will print a skeleton z8530drv.conf for the OptoSCC to stdout.
+
+gencfg 2 0x300 2 4 5 -4 0 7 4915200 0x10
+
+does the same for the BAYCOM USCC card. In my opinion it is much easier
+to edit scc_config.h... 
+
+
+1.2.2 channel configuration
+===========================
+
+The channel definition is divided into three sub sections for each
+channel:
+
+An example for scc0:
+
+# DEVICE
+
+device scc0     # the device for the following params
+
+# MODEM / BUFFERS
+
+speed 1200              # the default baudrate
+clock dpll              # clock source: 
+                        #       dpll     = normal half duplex operation
+                        #       external = MODEM provides own Rx/Tx clock
+                        #       divider  = use full duplex divider if
+                        #                  installed (1)
+mode nrzi               # HDLC encoding mode
+                        #       nrzi = 1k2 MODEM, G3RUH 9k6 MODEM
+                        #       nrz  = DF9IC 9k6 MODEM
+                        #
+bufsize 384             # size of buffers. Note that this must include
+                        # the AX.25 header, not only the data field!
+                        # (optional, defaults to 384)
+
+# KISS (Layer 1)
+
+txdelay 36              # (see chapter 1.4)
+persist 64
+slot    8
+tail    8
+fulldup 0
+wait    12
+min     3
+maxkey  7
+idle    3
+maxdef  120
+group   0
+txoff   off
+softdcd on                   
+slip    off
+
+The order WITHIN these sections is unimportant. The order OF these
+sections IS important. The MODEM parameters are set with the first
+recognized KISS parameter...
+
+Please note that you can initialize the board only once after boot
+(or insmod). You can change all parameters but "mode" and "clock" 
+later with the Sccparam program or through KISS. Just to avoid 
+security holes... 
+
+(1) this divider is usually mounted on the SCC-PBC (PA0HZP) or not
+    present at all (BayCom). It feeds back the output of the DPLL 
+    (digital pll) as transmit clock. Using this mode without a divider 
+    installed will normally result in keying the transceiver until 
+    maxkey expires --- of course without sending anything (useful).
+
+2. Attachment of a channel by your AX.25 software
+=================================================
+
+2.1 Kernel AX.25
+================
+
+To set up an AX.25 device you can simply type:
+
+        ifconfig scc0 44.128.1.1 hw ax25 dl0tha-7
+
+This will create a network interface with the IP number 44.128.20.107 
+and the callsign "dl0tha". If you do not have any IP number (yet) you 
+can use any of the 44.128.0.0 network. Note that you do not need 
+axattach. The purpose of axattach (like slattach) is to create a KISS 
+network device linked to a TTY. Please read the documentation of the 
+ax25-utils and the AX.25-HOWTO to learn how to set the parameters of
+the kernel AX.25.
+
+2.2 NOS, NET and TFKISS
+=======================
+
+Since the TTY driver (aka KISS TNC emulation) is gone you need
+to emulate the old behaviour. The cost of using these programs is
+that you probably need to compile the kernel AX.25, regardless of whether
+you actually use it or not. First setup your /etc/ax25/axports,
+for example:
+
+        9k6     dl0tha-9  9600  255 4 9600 baud port (scc3)
+        axlink  dl0tha-15 38400 255 4 Link to NOS
+
+Now "ifconfig" the scc device:
+
+        ifconfig scc3 44.128.1.1 hw ax25 dl0tha-9
+
+You can now axattach a pseudo-TTY:
+
+        axattach /dev/ptys0 axlink
+
+and start your NOS and attach /dev/ptys0 there. The problem is that
+NOS is reachable only via digipeating through the kernel AX.25
+(disastrous on a DAMA controlled channel). To solve this problem,
+configure "rxecho" to echo the incoming frames from "9k6" to "axlink"
+and outgoing frames from "axlink" to "9k6" and start:
+
+        rxecho
+
+Or simply use "kissbridge" coming with z8530drv-utils:
+
+        ifconfig scc3 hw ax25 dl0tha-9
+        kissbridge scc3 /dev/ptys0
+
+
+3. Adjustment and Display of parameters
+=======================================
+
+3.1 Displaying SCC Parameters:
+==============================
+
+Once a SCC channel has been attached, the parameter settings and 
+some statistic information can be shown using the param program:
+
+dl1bke-u:~$ sccstat scc0
+
+Parameters:
+
+speed       : 1200 baud
+txdelay     : 36
+persist     : 255
+slottime    : 0
+txtail      : 8
+fulldup     : 1
+waittime    : 12
+mintime     : 3 sec
+maxkeyup    : 7 sec
+idletime    : 3 sec
+maxdefer    : 120 sec
+group       : 0x00
+txoff       : off
+softdcd     : on
+SLIP        : off
+
+Status:
+
+HDLC                  Z8530           Interrupts         Buffers
+-----------------------------------------------------------------------
+Sent       :     273  RxOver :     0  RxInts :   125074  Size    :  384
+Received   :    1095  TxUnder:     0  TxInts :     4684  NoSpace :    0
+RxErrors   :    1591                  ExInts :    11776
+TxErrors   :       0                  SpInts :     1503
+Tx State   :    idle
+
+
+The status info shown is:
+
+Sent            - number of frames transmitted
+Received        - number of frames received
+RxErrors        - number of receive errors (CRC, ABORT)
+TxErrors        - number of discarded Tx frames (due to various reasons) 
+Tx State        - status of the Tx interrupt handler: idle/busy/active/tail (2)
+RxOver          - number of receiver overruns
+TxUnder         - number of transmitter underruns
+RxInts          - number of receiver interrupts
+TxInts          - number of transmitter interrupts
+EpInts          - number of receiver special condition interrupts
+SpInts          - number of external/status interrupts
+Size            - maximum size of an AX.25 frame (*with* AX.25 headers!)
+NoSpace         - number of times a buffer could not get allocated
+
+An overrun is abnormal. If lots of these occur, the product of
+baudrate and number of interfaces is too high for the processing
+power of your computer. NoSpace errors are unlikely to be caused by the
+driver or the kernel AX.25.
+
+
+3.2 Setting Parameters
+======================
+
+
+The setting of parameters of the emulated KISS TNC is done in the 
+same way in the SCC driver. You can change parameters by using
+the kissparms program from the ax25-utils package or use the program 
+"sccparam":
+
+     sccparam <device> <paramname> <decimal-|hexadecimal value>
+
+You can change the following parameters:
+
+param       : value
+------------------------
+speed       : 1200
+txdelay     : 36
+persist     : 255
+slottime    : 0
+txtail      : 8
+fulldup     : 1
+waittime    : 12
+mintime     : 3
+maxkeyup    : 7
+idletime    : 3
+maxdefer    : 120
+group       : 0x00
+txoff       : off
+softdcd     : on
+SLIP        : off
+
+
+The parameters have the following meaning:
+
+speed:
+     The baudrate on this channel in bits/sec
+
+     Example: sccparam /dev/scc3 speed 9600
+
+txdelay:
+     The delay (in units of 10 ms) after keying of the 
+     transmitter, until the first byte is sent. This is usually 
+     called "TXDELAY" in a TNC.  When 0 is specified, the driver 
+     will just wait until the CTS signal is asserted. This 
+     assumes the presence of a timer or other circuitry in the 
+     MODEM and/or transmitter, that asserts CTS when the 
+     transmitter is ready for data.
+     A normal value of this parameter is 30-36.
+
+     Example: sccparam /dev/scc0 txd 20
+
+persist:
+     This is the probability that the transmitter will be keyed 
+     when the channel is found to be free.  It is a value from 0 
+     to 255, and the probability is (value+1)/256.  The value 
+     should be somewhere near 50-60, and should be lowered when 
+     the channel is used more heavily.
+
+     Example: sccparam /dev/scc2 persist 20
+
+slottime:
+     This is the time between samples of the channel. It is 
+     expressed in units of 10 ms.  About 200-300 ms (value 20-30) 
+     seems to be a good value.
+
+     Example: sccparam /dev/scc0 slot 20
+
+tail:
+     The time the transmitter will remain keyed after the last 
+     byte of a packet has been transferred to the SCC. This is 
+     necessary because the CRC and a flag still have to leave the 
+     SCC before the transmitter is keyed down. The value depends 
+     on the baudrate selected.  A few character times should be 
+     sufficient, e.g. 40ms at 1200 baud. (value 4)
+     The value of this parameter is in 10 ms units.
+
+     Example: sccparam /dev/scc2 4
+
+full:
+     The full-duplex mode switch. This can be one of the following 
+     values:
+
+     0:   The interface will operate in CSMA mode (the normal 
+          half-duplex packet radio operation)
+     1:   Fullduplex mode, i.e. the transmitter will be keyed at 
+          any time, without checking the received carrier.  It 
+          will be unkeyed when there are no packets to be sent.
+     2:   Like 1, but the transmitter will remain keyed, also 
+          when there are no packets to be sent.  Flags will be 
+          sent in that case, until a timeout (parameter 10) 
+          occurs.
+
+     Example: sccparam /dev/scc0 fulldup off
+
+wait:
+     The initial waittime before any transmit attempt, after the 
+     frame has been queue for transmit.  This is the length of 
+     the first slot in CSMA mode.  In full duplex modes it is
+     set to 0 for maximum performance.
+     The value of this parameter is in 10 ms units. 
+
+     Example: sccparam /dev/scc1 wait 4
+
+maxkey:
+     The maximal time the transmitter will be keyed to send 
+     packets, in seconds.  This can be useful on busy CSMA 
+     channels, to avoid "getting a bad reputation" when you are 
+     generating a lot of traffic.  After the specified time has 
+     elapsed, no new frame will be started. Instead, the trans-
+     mitter will be switched off for a specified time (parameter 
+     min), and then the selected algorithm for keyup will be 
+     started again.
+     The value 0 as well as "off" will disable this feature, 
+     and allow infinite transmission time. 
+
+     Example: sccparam /dev/scc0 maxk 20
+
+min:
+     This is the time the transmitter will be switched off when 
+     the maximum transmission time is exceeded.
+
+     Example: sccparam /dev/scc3 min 10
+
+idle
+     This parameter specifies the maximum idle time in full duplex 
+     2 mode, in seconds.  When no frames have been sent for this 
+     time, the transmitter will be keyed down.  A value of 0 is
+     has same result as the fullduplex mode 1. This parameter
+     can be disabled.
+
+     Example: sccparam /dev/scc2 idle off       # transmit forever
+
+maxdefer
+     This is the maximum time (in seconds) to wait for a free channel
+     to send. When this timer expires the transmitter will be keyed 
+     IMMEDIATELY. If you love to get trouble with other users you
+     should set this to a very low value ;-)
+
+     Example: sccparam /dev/scc0 maxdefer 240   # 2 minutes
+
+
+txoff:
+     When this parameter has the value 0, the transmission of packets
+     is enable. Otherwise it is disabled.
+
+     Example: sccparam /dev/scc2 txoff on
+
+group:
+     It is possible to build special radio equipment to use more than 
+     one frequency on the same band, e.g. using several receivers and 
+     only one transmitter that can be switched between frequencies.
+     Also, you can connect several radios that are active on the same 
+     band.  In these cases, it is not possible, or not a good idea, to 
+     transmit on more than one frequency.  The SCC driver provides a 
+     method to lock transmitters on different interfaces, using the 
+     "param <interface> group <x>" command.  This will only work when 
+     you are using CSMA mode (parameter full = 0).
+     The number <x> must be 0 if you want no group restrictions, and 
+     can be computed as follows to create restricted groups:
+     <x> is the sum of some OCTAL numbers:
+
+     200  This transmitter will only be keyed when all other 
+          transmitters in the group are off.
+     100  This transmitter will only be keyed when the carrier 
+          detect of all other interfaces in the group is off.
+     0xx  A byte that can be used to define different groups.  
+          Interfaces are in the same group, when the logical AND 
+          between their xx values is nonzero.
+
+     Examples:
+     When 2 interfaces use group 201, their transmitters will never be 
+     keyed at the same time.
+     When 2 interfaces use group 101, the transmitters will only key 
+     when both channels are clear at the same time.  When group 301, 
+     the transmitters will not be keyed at the same time.
+
+     Don't forget to convert the octal numbers into decimal before
+     you set the parameter.
+
+     Example: (to be written)
+
+softdcd:
+     use a software dcd instead of the real one... Useful for a very
+     slow squelch.
+
+     Example: sccparam /dev/scc0 soft on
+
+
+4. Problems 
+===========
+
+If you have tx-problems with your BayCom USCC card please check
+the manufacturer of the 8530. SGS chips have a slightly
+different timing. Try Zilog...  A solution is to write to register 8 
+instead to the data port, but this won't work with the ESCC chips. 
+*SIGH!*
+
+A very common problem is that the PTT locks until the maxkeyup timer
+expires, although interrupts and clock source are correct. In most
+cases compiling the driver with CONFIG_SCC_DELAY (set with
+make config) solves the problems. For more hints read the (pseudo) FAQ 
+and the documentation coming with z8530drv-utils.
+
+I got reports that the driver has problems on some 386-based systems.
+(i.e. Amstrad) Those systems have a bogus AT bus timing which will
+lead to delayed answers on interrupts. You can recognize these
+problems by looking at the output of Sccstat for the suspected
+port. If it shows under- and overruns you own such a system.
+
+Delayed processing of received data: This depends on
+
+- the kernel version
+
+- kernel profiling compiled or not
+
+- a high interrupt load
+
+- a high load of the machine --- running X, Xmorph, XV and Povray,
+  while compiling the kernel... hmm ... even with 32 MB RAM ...  ;-)
+  Or running a named for the whole .ampr.org domain on an 8 MB
+  box...
+
+- using information from rxecho or kissbridge.
+
+Kernel panics: please read /linux/README and find out if it
+really occurred within the scc driver.
+
+If you cannot solve a problem, send me
+
+- a description of the problem,
+- information on your hardware (computer system, scc board, modem)
+- your kernel version
+- the output of cat /proc/net/z8530
+
+4. Thor RLC100
+==============
+
+Mysteriously this board seems not to work with the driver. Anyone
+got it up-and-running?
+
+
+Many thanks to Linus Torvalds and Alan Cox for including the driver
+in the Linux standard distribution and their support.
+
+Joerg Reuter    ampr-net: dl1bke@db0pra.ampr.org
+                AX-25   : DL1BKE @ DB0ABH.#BAY.DEU.EU
+                Internet: jreuter@yaina.de
+                WWW     : http://yaina.de/jreuter