summaryrefslogtreecommitdiffstats
path: root/Documentation/networking
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/networking')
-rw-r--r--Documentation/networking/.gitignore1
-rw-r--r--Documentation/networking/00-INDEX218
-rw-r--r--Documentation/networking/3c505.txt45
-rw-r--r--Documentation/networking/3c509.txt213
-rw-r--r--Documentation/networking/6pack.txt175
-rw-r--r--Documentation/networking/DLINK.txt203
-rw-r--r--Documentation/networking/LICENSE.qla3xxx46
-rw-r--r--Documentation/networking/LICENSE.qlcnic288
-rw-r--r--Documentation/networking/LICENSE.qlge288
-rw-r--r--Documentation/networking/Makefile12
-rw-r--r--Documentation/networking/PLIP.txt215
-rw-r--r--Documentation/networking/README.ipw2100293
-rw-r--r--Documentation/networking/README.ipw2200472
-rw-r--r--Documentation/networking/README.sb1000207
-rw-r--r--Documentation/networking/alias.txt40
-rw-r--r--Documentation/networking/arcnet-hardware.txt3133
-rw-r--r--Documentation/networking/arcnet.txt555
-rw-r--r--Documentation/networking/atm.txt8
-rw-r--r--Documentation/networking/ax25.txt10
-rw-r--r--Documentation/networking/batman-adv.txt242
-rw-r--r--Documentation/networking/baycom.txt158
-rw-r--r--Documentation/networking/bonding.txt2640
-rw-r--r--Documentation/networking/bridge.txt8
-rw-r--r--Documentation/networking/caif/Linux-CAIF.txt212
-rw-r--r--Documentation/networking/caif/README109
-rw-r--r--Documentation/networking/caif/spi_porting.txt208
-rw-r--r--Documentation/networking/can.txt836
-rw-r--r--Documentation/networking/cops.txt63
-rw-r--r--Documentation/networking/cs89x0.txt703
-rw-r--r--Documentation/networking/cxacru-cf.py48
-rw-r--r--Documentation/networking/cxacru.txt100
-rw-r--r--Documentation/networking/cxgb.txt352
-rw-r--r--Documentation/networking/dccp.txt207
-rw-r--r--Documentation/networking/de4x5.txt178
-rw-r--r--Documentation/networking/decnet.txt232
-rw-r--r--Documentation/networking/depca.txt92
-rw-r--r--Documentation/networking/dl2k.txt282
-rw-r--r--Documentation/networking/dm9000.txt167
-rw-r--r--Documentation/networking/dmfe.txt66
-rw-r--r--Documentation/networking/dns_resolver.txt157
-rw-r--r--Documentation/networking/driver.txt93
-rw-r--r--Documentation/networking/e100.txt197
-rw-r--r--Documentation/networking/e1000.txt461
-rw-r--r--Documentation/networking/e1000e.txt306
-rw-r--r--Documentation/networking/eql.txt528
-rw-r--r--Documentation/networking/ewrk3.txt46
-rw-r--r--Documentation/networking/fib_trie.txt145
-rw-r--r--Documentation/networking/filter.txt42
-rw-r--r--Documentation/networking/fore200e.txt64
-rw-r--r--Documentation/networking/framerelay.txt39
-rw-r--r--Documentation/networking/gen_stats.txt117
-rw-r--r--Documentation/networking/generic-hdlc.txt132
-rw-r--r--Documentation/networking/generic_netlink.txt3
-rw-r--r--Documentation/networking/gianfar.txt72
-rw-r--r--Documentation/networking/ieee802154.txt150
-rw-r--r--Documentation/networking/ifenslave.c1105
-rw-r--r--Documentation/networking/igb.txt122
-rw-r--r--Documentation/networking/igbvf.txt80
-rw-r--r--Documentation/networking/ip-sysctl.txt1533
-rw-r--r--Documentation/networking/ip_dynaddr.txt29
-rw-r--r--Documentation/networking/ipddp.txt73
-rw-r--r--Documentation/networking/iphase.txt158
-rw-r--r--Documentation/networking/ipv6.txt72
-rw-r--r--Documentation/networking/ipvs-sysctl.txt191
-rw-r--r--Documentation/networking/irda.txt10
-rw-r--r--Documentation/networking/ixgb.txt433
-rw-r--r--Documentation/networking/ixgbe.txt260
-rw-r--r--Documentation/networking/ixgbevf.txt52
-rw-r--r--Documentation/networking/l2tp.txt348
-rw-r--r--Documentation/networking/lapb-module.txt263
-rw-r--r--Documentation/networking/ltpc.txt131
-rw-r--r--Documentation/networking/mac80211-auth-assoc-deauth.txt95
-rw-r--r--Documentation/networking/mac80211-injection.txt67
-rw-r--r--Documentation/networking/mac80211_hwsim/README68
-rw-r--r--Documentation/networking/mac80211_hwsim/hostapd.conf11
-rw-r--r--Documentation/networking/mac80211_hwsim/wpa_supplicant.conf10
-rw-r--r--Documentation/networking/multicast.txt63
-rw-r--r--Documentation/networking/multiqueue.txt79
-rw-r--r--Documentation/networking/netconsole.txt157
-rw-r--r--Documentation/networking/netdev-features.txt167
-rw-r--r--Documentation/networking/netdevices.txt107
-rw-r--r--Documentation/networking/netif-msg.txt79
-rw-r--r--Documentation/networking/nfc.txt128
-rw-r--r--Documentation/networking/openvswitch.txt195
-rw-r--r--Documentation/networking/operstates.txt158
-rw-r--r--Documentation/networking/packet_mmap.txt527
-rw-r--r--Documentation/networking/phonet.txt214
-rw-r--r--Documentation/networking/phy.txt312
-rw-r--r--Documentation/networking/pktgen.txt261
-rw-r--r--Documentation/networking/policy-routing.txt150
-rw-r--r--Documentation/networking/ppp_generic.txt432
-rw-r--r--Documentation/networking/proc_net_tcp.txt48
-rw-r--r--Documentation/networking/radiotap-headers.txt152
-rw-r--r--Documentation/networking/ray_cs.txt150
-rw-r--r--Documentation/networking/rds.txt356
-rw-r--r--Documentation/networking/regulatory.txt214
-rw-r--r--Documentation/networking/rxrpc.txt866
-rw-r--r--Documentation/networking/s2io.txt151
-rw-r--r--Documentation/networking/scaling.txt378
-rw-r--r--Documentation/networking/sctp.txt38
-rw-r--r--Documentation/networking/secid.txt14
-rw-r--r--Documentation/networking/skfp.txt220
-rw-r--r--Documentation/networking/smc9.txt42
-rw-r--r--Documentation/networking/spider_net.txt204
-rw-r--r--Documentation/networking/stmmac.txt310
-rw-r--r--Documentation/networking/tc-actions-env-rules.txt30
-rw-r--r--Documentation/networking/tcp-thin.txt47
-rw-r--r--Documentation/networking/tcp.txt106
-rw-r--r--Documentation/networking/team.txt2
-rw-r--r--Documentation/networking/timestamping.txt200
-rw-r--r--Documentation/networking/timestamping/.gitignore1
-rw-r--r--Documentation/networking/timestamping/Makefile13
-rw-r--r--Documentation/networking/timestamping/timestamping.c533
-rw-r--r--Documentation/networking/tlan.txt117
-rw-r--r--Documentation/networking/tproxy.txt85
-rw-r--r--Documentation/networking/tuntap.txt150
-rw-r--r--Documentation/networking/udplite.txt278
-rw-r--r--Documentation/networking/vortex.txt448
-rw-r--r--Documentation/networking/vxge.txt100
-rw-r--r--Documentation/networking/x25-iface.txt123
-rw-r--r--Documentation/networking/x25.txt44
-rw-r--r--Documentation/networking/xfrm_proc.txt74
-rw-r--r--Documentation/networking/xfrm_sync.txt169
-rw-r--r--Documentation/networking/xfrm_sysctl.txt4
-rw-r--r--Documentation/networking/z8530drv.txt657
125 files changed, 0 insertions, 30341 deletions
diff --git a/Documentation/networking/.gitignore b/Documentation/networking/.gitignore
deleted file mode 100644
index 286a5680f49..00000000000
--- a/Documentation/networking/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-ifenslave
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
deleted file mode 100644
index 2cc3c7733a2..00000000000
--- a/Documentation/networking/00-INDEX
+++ /dev/null
@@ -1,218 +0,0 @@
-00-INDEX
- - this file
-3c505.txt
- - information on the 3Com EtherLink Plus (3c505) driver.
-3c509.txt
- - information on the 3Com Etherlink III Series Ethernet cards.
-6pack.txt
- - info on the 6pack protocol, an alternative to KISS for AX.25
-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.ipw2100
- - README for the Intel PRO/Wireless 2100 driver.
-README.ipw2200
- - README for the Intel PRO/Wireless 2915ABG and 2200BG 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
-batman-adv.txt
- - B.A.T.M.A.N routing protocol on top of layer 2 Ethernet Frames.
-baycom.txt
- - info on the driver for Baycom style amateur radio modems
-bonding.txt
- - Linux Ethernet Bonding Driver HOWTO: link aggregation in Linux.
-bridge.txt
- - where to get user space programs for ethernet bridging with Linux.
-can.txt
- - documentation on CAN protocol family.
-cops.txt
- - info on the COPS LocalTalk Linux driver
-cs89x0.txt
- - the Crystal LAN (CS8900/20-based) Ethernet ISA adapter driver
-cxacru.txt
- - Conexant AccessRunner USB ADSL Modem
-cxacru-cf.py
- - Conexant AccessRunner USB ADSL Modem configuration file parser
-cxgb.txt
- - Release Notes for the Chelsio N210 Linux device driver.
-dccp.txt
- - the Datagram Congestion Control Protocol (DCCP) (RFC 4340..42).
-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
-dl2k.txt
- - README for D-Link DL2000-based Gigabit Ethernet Adapters (dl2k.ko).
-dm9000.txt
- - README for the Simtec DM9000 Network driver.
-dmfe.txt
- - info on the Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver.
-dns_resolver.txt
- - The DNS resolver module allows kernel servies to make DNS queries.
-driver.txt
- - Softnet driver issues.
-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
-e1000e.txt
- - README for the Intel Gigabit Ethernet Driver (e1000e).
-eql.txt
- - serial IP load balancing
-ewrk3.txt
- - the Digital EtherWORKS 3 DE203/4/5 Ethernet driver
-fib_trie.txt
- - Level Compressed Trie (LC-trie) notes: a structure for routing.
-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).
-gen_stats.txt
- - Generic networking statistics for netlink users.
-generic_hdlc.txt
- - The generic High Level Data Link Control (HDLC) layer.
-generic_netlink.txt
- - info on Generic Netlink
-gianfar.txt
- - Gianfar Ethernet Driver.
-ieee802154.txt
- - Linux IEEE 802.15.4 implementation, API and drivers
-ifenslave.c
- - Configure network interfaces for parallel routing (bonding).
-igb.txt
- - README for the Intel Gigabit Ethernet Driver (igb).
-igbvf.txt
- - README for the Intel Gigabit Ethernet Driver (igbvf).
-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.
-ipv6.txt
- - Options to the ipv6 kernel module.
-ipvs-sysctl.txt
- - Per-inode explanation of the /proc/sys/net/ipv4/vs interface.
-irda.txt
- - where to get IrDA (infrared) utilities and info for Linux.
-ixgb.txt
- - README for the Intel 10 Gigabit Ethernet Driver (ixgb).
-ixgbe.txt
- - README for the Intel 10 Gigabit Ethernet Driver (ixgbe).
-ixgbevf.txt
- - README for the Intel Virtual Function (VF) Driver (ixgbevf).
-l2tp.txt
- - User guide to the L2TP tunnel protocol.
-lapb-module.txt
- - programming information of the LAPB module.
-ltpc.txt
- - the Apple or Farallon LocalTalk PC card driver
-mac80211-injection.txt
- - HOWTO use packet injection with mac80211
-multicast.txt
- - Behaviour of cards under Multicast
-multiqueue.txt
- - HOWTO for multiqueue network device support.
-netconsole.txt
- - The network console module netconsole.ko: configuration and notes.
-netdev-features.txt
- - Network interface features API description.
-netdevices.txt
- - info on network device driver functions exported to the kernel.
-netif-msg.txt
- - Design of the network interface message level setting (NETIF_MSG_*).
-nfc.txt
- - The Linux Near Field Communication (NFS) subsystem.
-openvswitch.txt
- - Open vSwitch developer documentation.
-operstates.txt
- - Overview of network interface operational states.
-packet_mmap.txt
- - User guide to memory mapped packet socket rings (PACKET_[RT]X_RING).
-phonet.txt
- - The Phonet packet protocol used in Nokia cellular modems.
-phy.txt
- - The PHY abstraction layer.
-pktgen.txt
- - User guide to the kernel packet generator (pktgen.ko).
-policy-routing.txt
- - IP policy-based routing
-ppp_generic.txt
- - Information about the generic PPP driver.
-proc_net_tcp.txt
- - Per inode overview of the /proc/net/tcp and /proc/net/tcp6 interfaces.
-radiotap-headers.txt
- - Background on radiotap headers.
-ray_cs.txt
- - Raylink Wireless LAN card driver info.
-rds.txt
- - Background on the reliable, ordered datagram delivery method RDS.
-regulatory.txt
- - Overview of the Linux wireless regulatory infrastructure.
-rxrpc.txt
- - Guide to the RxRPC protocol.
-s2io.txt
- - Release notes for Neterion Xframe I/II 10GbE driver.
-scaling.txt
- - Explanation of network scaling techniques: RSS, RPS, RFS, aRFS, XPS.
-sctp.txt
- - Notes on the Linux kernel implementation of the SCTP protocol.
-secid.txt
- - Explanation of the secid member in flow structures.
-skfp.txt
- - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info.
-smc9.txt
- - the driver for SMC's 9000 series of Ethernet cards
-spider-net.txt
- - README for the Spidernet Driver (as found in PS3 / Cell BE).
-stmmac.txt
- - README for the STMicro Synopsys Ethernet driver.
-tc-actions-env-rules.txt
- - rules for traffic control (tc) actions.
-timestamping.txt
- - overview of network packet timestamping variants.
-tcp.txt
- - short blurb on how TCP output takes place.
-tcp-thin.txt
- - kernel tuning options for low rate 'thin' TCP streams.
-tlan.txt
- - ThunderLAN (Compaq Netelligent 10/100, Olicom OC-2xxx) driver info.
-tproxy.txt
- - Transparent proxy support user guide.
-tuntap.txt
- - TUN/TAP device driver, allowing user space Rx/Tx of packets.
-udplite.txt
- - UDP-Lite protocol (RFC 3828) introduction.
-vortex.txt
- - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
-vxge.txt
- - README for the Neterion X3100 PCIe Server Adapter.
-x25.txt
- - general info on X.25 development.
-x25-iface.txt
- - description of the X.25 Packet Layer to LAPB device interface.
-xfrm_proc.txt
- - description of the statistics package for XFRM.
-xfrm_sync.txt
- - sync patches for XFRM enable migration of an SA between hosts.
-xfrm_sysctl.txt
- - description of the XFRM configuration options.
-z8530drv.txt
- - info about Linux driver for Z8530 based HDLC cards for AX.25
diff --git a/Documentation/networking/3c505.txt b/Documentation/networking/3c505.txt
deleted file mode 100644
index 72f38b13101..00000000000
--- a/Documentation/networking/3c505.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-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.
-
-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
deleted file mode 100644
index fbf722e15ac..00000000000
--- a/Documentation/networking/3c509.txt
+++ /dev/null
@@ -1,213 +0,0 @@
-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)
- 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/.
-
-
-(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 may be overridden. For example,
-setting two cards to IRQ10 and IRQ11 is done by using the irq module
-option:
-
- options 3c509 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.
-
-Full-duplex mode can be enabled using 'ethtool'.
-
-/////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.
-
-The transceiver type can be changed using 'ethtool'.
-
-
-(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 activity.
-
- - 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
deleted file mode 100644
index 8f339428fdf..00000000000
--- a/Documentation/networking/6pack.txt
+++ /dev/null
@@ -1,175 +0,0 @@
-This is the 6pack-mini-HOWTO, written by
-
-Andreas Könsgen DG3KQ
-Internet: ajk@comnets.uni-bremen.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/DLINK.txt b/Documentation/networking/DLINK.txt
deleted file mode 100644
index 55d24433d15..00000000000
--- a/Documentation/networking/DLINK.txt
+++ /dev/null
@@ -1,203 +0,0 @@
-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, 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/LICENSE.qla3xxx b/Documentation/networking/LICENSE.qla3xxx
deleted file mode 100644
index 2f2077e34d8..00000000000
--- a/Documentation/networking/LICENSE.qla3xxx
+++ /dev/null
@@ -1,46 +0,0 @@
-Copyright (c) 2003-2006 QLogic Corporation
-QLogic Linux Networking HBA Driver
-
-This program includes a device driver for Linux 2.6 that may be
-distributed with QLogic hardware specific firmware binary file.
-You may modify and redistribute the device driver code under the
-GNU General Public License as published by the Free Software
-Foundation (version 2 or a later version).
-
-You may redistribute the hardware specific firmware binary file
-under the following terms:
-
- 1. Redistribution of source code (only if applicable),
- must retain the above copyright notice, this list of
- conditions and the following disclaimer.
-
- 2. Redistribution in binary form must reproduce the above
- copyright notice, this list of conditions and the
- following disclaimer in the documentation and/or other
- materials provided with the distribution.
-
- 3. The name of QLogic Corporation may not be used to
- endorse or promote products derived from this software
- without specific prior written permission
-
-REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
-THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
-EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
-PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
-BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
-EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
-TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
-ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGE.
-
-USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
-CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
-OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
-TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
-ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
-COMBINATION WITH THIS PROGRAM.
-
diff --git a/Documentation/networking/LICENSE.qlcnic b/Documentation/networking/LICENSE.qlcnic
deleted file mode 100644
index e7fb2c6023b..00000000000
--- a/Documentation/networking/LICENSE.qlcnic
+++ /dev/null
@@ -1,288 +0,0 @@
-Copyright (c) 2009-2011 QLogic Corporation
-QLogic Linux qlcnic NIC Driver
-
-You may modify and redistribute the device driver code under the
-GNU General Public License (a copy of which is attached hereto as
-Exhibit A) published by the Free Software Foundation (version 2).
-
-
-EXHIBIT A
-
- GNU GENERAL PUBLIC LICENSE
- Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- Preamble
-
- The licenses for most software are designed to take away your
-freedom to share and change it. By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users. This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it. (Some other Free Software Foundation software is covered by
-the GNU Lesser General Public License instead.) You can apply it to
-your programs, too.
-
- When we speak of free software, we are referring to freedom, not
-price. Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
- To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
- For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have. You must make sure that they, too, receive or can get the
-source code. And you must show them these terms so they know their
-rights.
-
- We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
- Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software. If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
- Finally, any free program is threatened constantly by software
-patents. We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary. To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
- The precise terms and conditions for copying, distribution and
-modification follow.
-
- GNU GENERAL PUBLIC LICENSE
- TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
- 0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License. The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language. (Hereinafter, translation is included without limitation in
-the term "modification".) Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope. The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
- 1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
- 2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
- a) You must cause the modified files to carry prominent notices
- stating that you changed the files and the date of any change.
-
- b) You must cause any work that you distribute or publish, that in
- whole or in part contains or is derived from the Program or any
- part thereof, to be licensed as a whole at no charge to all third
- parties under the terms of this License.
-
- c) If the modified program normally reads commands interactively
- when run, you must cause it, when started running for such
- interactive use in the most ordinary way, to print or display an
- announcement including an appropriate copyright notice and a
- notice that there is no warranty (or else, saying that you provide
- a warranty) and that users may redistribute the program under
- these conditions, and telling the user how to view a copy of this
- License. (Exception: if the Program itself is interactive but
- does not normally print such an announcement, your work based on
- the Program is not required to print an announcement.)
-
-These requirements apply to the modified work as a whole. If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works. But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
- 3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
- a) Accompany it with the complete corresponding machine-readable
- source code, which must be distributed under the terms of Sections
- 1 and 2 above on a medium customarily used for software interchange; or,
-
- b) Accompany it with a written offer, valid for at least three
- years, to give any third party, for a charge no more than your
- cost of physically performing source distribution, a complete
- machine-readable copy of the corresponding source code, to be
- distributed under the terms of Sections 1 and 2 above on a medium
- customarily used for software interchange; or,
-
- c) Accompany it with the information you received as to the offer
- to distribute corresponding source code. (This alternative is
- allowed only for noncommercial distribution and only if you
- received the program in object code or executable form with such
- an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it. For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable. However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
- 4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License. Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
- 5. You are not required to accept this License, since you have not
-signed it. However, nothing else grants you permission to modify or
-distribute the Program or its derivative works. These actions are
-prohibited by law if you do not accept this License. Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
- 6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions. You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
- 7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License. If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all. For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices. Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
- 8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded. In such case, this License incorporates
-the limitation as if written in the body of this License.
-
- 9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time. Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number. If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation. If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
- 10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission. For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this. Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
- NO WARRANTY
-
- 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
- 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
diff --git a/Documentation/networking/LICENSE.qlge b/Documentation/networking/LICENSE.qlge
deleted file mode 100644
index ce64e4d15b2..00000000000
--- a/Documentation/networking/LICENSE.qlge
+++ /dev/null
@@ -1,288 +0,0 @@
-Copyright (c) 2003-2011 QLogic Corporation
-QLogic Linux qlge NIC Driver
-
-You may modify and redistribute the device driver code under the
-GNU General Public License (a copy of which is attached hereto as
-Exhibit A) published by the Free Software Foundation (version 2).
-
-
-EXHIBIT A
-
- GNU GENERAL PUBLIC LICENSE
- Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- Preamble
-
- The licenses for most software are designed to take away your
-freedom to share and change it. By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users. This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it. (Some other Free Software Foundation software is covered by
-the GNU Lesser General Public License instead.) You can apply it to
-your programs, too.
-
- When we speak of free software, we are referring to freedom, not
-price. Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
- To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
- For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have. You must make sure that they, too, receive or can get the
-source code. And you must show them these terms so they know their
-rights.
-
- We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
- Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software. If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
- Finally, any free program is threatened constantly by software
-patents. We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary. To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
- The precise terms and conditions for copying, distribution and
-modification follow.
-
- GNU GENERAL PUBLIC LICENSE
- TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
- 0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License. The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language. (Hereinafter, translation is included without limitation in
-the term "modification".) Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope. The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
- 1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
- 2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
- a) You must cause the modified files to carry prominent notices
- stating that you changed the files and the date of any change.
-
- b) You must cause any work that you distribute or publish, that in
- whole or in part contains or is derived from the Program or any
- part thereof, to be licensed as a whole at no charge to all third
- parties under the terms of this License.
-
- c) If the modified program normally reads commands interactively
- when run, you must cause it, when started running for such
- interactive use in the most ordinary way, to print or display an
- announcement including an appropriate copyright notice and a
- notice that there is no warranty (or else, saying that you provide
- a warranty) and that users may redistribute the program under
- these conditions, and telling the user how to view a copy of this
- License. (Exception: if the Program itself is interactive but
- does not normally print such an announcement, your work based on
- the Program is not required to print an announcement.)
-
-These requirements apply to the modified work as a whole. If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works. But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
- 3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
- a) Accompany it with the complete corresponding machine-readable
- source code, which must be distributed under the terms of Sections
- 1 and 2 above on a medium customarily used for software interchange; or,
-
- b) Accompany it with a written offer, valid for at least three
- years, to give any third party, for a charge no more than your
- cost of physically performing source distribution, a complete
- machine-readable copy of the corresponding source code, to be
- distributed under the terms of Sections 1 and 2 above on a medium
- customarily used for software interchange; or,
-
- c) Accompany it with the information you received as to the offer
- to distribute corresponding source code. (This alternative is
- allowed only for noncommercial distribution and only if you
- received the program in object code or executable form with such
- an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it. For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable. However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
- 4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License. Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
- 5. You are not required to accept this License, since you have not
-signed it. However, nothing else grants you permission to modify or
-distribute the Program or its derivative works. These actions are
-prohibited by law if you do not accept this License. Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
- 6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions. You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
- 7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License. If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all. For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices. Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
- 8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded. In such case, this License incorporates
-the limitation as if written in the body of this License.
-
- 9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time. Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number. If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation. If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
- 10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission. For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this. Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
- NO WARRANTY
-
- 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
- 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
diff --git a/Documentation/networking/Makefile b/Documentation/networking/Makefile
deleted file mode 100644
index 24c308dd3fd..00000000000
--- a/Documentation/networking/Makefile
+++ /dev/null
@@ -1,12 +0,0 @@
-# kbuild trick to avoid linker error. Can be omitted if a module is built.
-obj- := dummy.o
-
-# List of programs to build
-hostprogs-y := ifenslave
-
-HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-obj-m := timestamping/
diff --git a/Documentation/networking/PLIP.txt b/Documentation/networking/PLIP.txt
deleted file mode 100644
index ad7e3f7c3bb..00000000000
--- a/Documentation/networking/PLIP.txt
+++ /dev/null
@@ -1,215 +0,0 @@
-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.ipw2100 b/Documentation/networking/README.ipw2100
deleted file mode 100644
index 6f85e1d0603..00000000000
--- a/Documentation/networking/README.ipw2100
+++ /dev/null
@@ -1,293 +0,0 @@
-
-Intel(R) PRO/Wireless 2100 Driver for Linux in support of:
-
-Intel(R) PRO/Wireless 2100 Network Connection
-
-Copyright (C) 2003-2006, Intel Corporation
-
-README.ipw2100
-
-Version: git-1.1.5
-Date : January 25, 2006
-
-Index
------------------------------------------------
-0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
-1. Introduction
-2. Release git-1.1.5 Current Features
-3. Command Line Parameters
-4. Sysfs Helper Files
-5. Radio Kill Switch
-6. Dynamic Firmware
-7. Power Management
-8. Support
-9. License
-
-
-0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
------------------------------------------------
-
-Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
-
-Intel wireless LAN adapters are engineered, manufactured, tested, and
-quality checked to ensure that they meet all necessary local and
-governmental regulatory agency requirements for the regions that they
-are designated and/or marked to ship into. Since wireless LANs are
-generally unlicensed devices that share spectrum with radars,
-satellites, and other licensed and unlicensed devices, it is sometimes
-necessary to dynamically detect, avoid, and limit usage to avoid
-interference with these devices. In many instances Intel is required to
-provide test data to prove regional and local compliance to regional and
-governmental regulations before certification or approval to use the
-product is granted. Intel's wireless LAN's EEPROM, firmware, and
-software driver are designed to carefully control parameters that affect
-radio operation and to ensure electromagnetic compliance (EMC). These
-parameters include, without limitation, RF power, spectrum usage,
-channel scanning, and human exposure.
-
-For these reasons Intel cannot permit any manipulation by third parties
-of the software provided in binary format with the wireless WLAN
-adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
-patches, utilities, or code with the Intel wireless LAN adapters that
-have been manipulated by an unauthorized party (i.e., patches,
-utilities, or code (including open source code modifications) which have
-not been validated by Intel), (i) you will be solely responsible for
-ensuring the regulatory compliance of the products, (ii) Intel will bear
-no liability, under any theory of liability for any issues associated
-with the modified products, including without limitation, claims under
-the warranty and/or issues arising from regulatory non-compliance, and
-(iii) Intel will not provide or be required to assist in providing
-support to any third parties for such modified products.
-
-Note: Many regulatory agencies consider Wireless LAN adapters to be
-modules, and accordingly, condition system-level regulatory approval
-upon receipt and review of test data documenting that the antennas and
-system configuration do not cause the EMC and radio operation to be
-non-compliant.
-
-The drivers available for download from SourceForge are provided as a
-part of a development project. Conformance to local regulatory
-requirements is the responsibility of the individual developer. As
-such, if you are interested in deploying or shipping a driver as part of
-solution intended to be used for purposes other than development, please
-obtain a tested driver from Intel Customer Support at:
-
-http://www.intel.com/support/wireless/sb/CS-006408.htm
-
-1. Introduction
------------------------------------------------
-
-This document provides a brief overview of the features supported by the
-IPW2100 driver project. The main project website, where the latest
-development version of the driver can be found, is:
-
- http://ipw2100.sourceforge.net
-
-There you can find the not only the latest releases, but also information about
-potential fixes and patches, as well as links to the development mailing list
-for the driver project.
-
-
-2. Release git-1.1.5 Current Supported Features
------------------------------------------------
-- Managed (BSS) and Ad-Hoc (IBSS)
-- WEP (shared key and open)
-- Wireless Tools support
-- 802.1x (tested with XSupplicant 1.0.1)
-
-Enabled (but not supported) features:
-- Monitor/RFMon mode
-- WPA/WPA2
-
-The distinction between officially supported and enabled is a reflection
-on the amount of validation and interoperability testing that has been
-performed on a given feature.
-
-
-3. 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 command using this
-syntax:
-
- modprobe ipw2100 [<option>=<VAL1><,VAL2>...]
-
-For example, to disable the radio on driver loading, enter:
-
- modprobe ipw2100 disable=1
-
-The ipw2100 driver supports the following module parameters:
-
-Name Value Example:
-debug 0x0-0xffffffff debug=1024
-mode 0,1,2 mode=1 /* AdHoc */
-channel int channel=3 /* Only valid in AdHoc or Monitor */
-associate boolean associate=0 /* Do NOT auto associate */
-disable boolean disable=1 /* Do not power the HW */
-
-
-4. Sysfs Helper Files
----------------------------
------------------------------------------------
-
-There are several ways to control the behavior of the driver. Many of the
-general capabilities are exposed through the Wireless Tools (iwconfig). There
-are a few capabilities that are exposed through entries in the Linux Sysfs.
-
-
------ Driver Level ------
-For the driver level files, look in /sys/bus/pci/drivers/ipw2100/
-
- debug_level
-
- This controls the same global as the 'debug' module parameter. For
- information on the various debugging levels available, run the 'dvals'
- script found in the driver source directory.
-
- NOTE: 'debug_level' is only enabled if CONFIG_IPW2100_DEBUG is turn
- on.
-
------ Device Level ------
-For the device level files look in
-
- /sys/bus/pci/drivers/ipw2100/{PCI-ID}/
-
-For example:
- /sys/bus/pci/drivers/ipw2100/0000:02:01.0
-
-For the device level files, see /sys/bus/pci/drivers/ipw2100:
-
- rf_kill
- read -
- 0 = RF kill not enabled (radio on)
- 1 = SW based RF kill active (radio off)
- 2 = HW based RF kill active (radio off)
- 3 = Both HW and SW RF kill active (radio off)
- write -
- 0 = If SW based RF kill active, turn the radio back on
- 1 = If radio is on, activate SW based RF kill
-
- NOTE: If you enable the SW based RF kill and then toggle the HW
- based RF kill from ON -> OFF -> ON, the radio will NOT come back on
-
-
-5. Radio Kill Switch
------------------------------------------------
-Most laptops provide the ability for the user to physically disable the radio.
-Some vendors have implemented this as a physical switch that requires no
-software to turn the radio off and on. On other laptops, however, the switch
-is controlled through a button being pressed and a software driver then making
-calls to turn the radio off and on. This is referred to as a "software based
-RF kill switch"
-
-See the Sysfs helper file 'rf_kill' for determining the state of the RF switch
-on your system.
-
-
-6. Dynamic Firmware
------------------------------------------------
-As the firmware is licensed under a restricted use license, it can not be
-included within the kernel sources. To enable the IPW2100 you will need a
-firmware image to load into the wireless NIC's processors.
-
-You can obtain these images from <http://ipw2100.sf.net/firmware.php>.
-
-See INSTALL for instructions on installing the firmware.
-
-
-7. Power Management
------------------------------------------------
-The IPW2100 supports the configuration of the Power Save Protocol
-through a private wireless extension interface. The IPW2100 supports
-the following different modes:
-
- off No power management. Radio is always on.
- on Automatic power management
- 1-5 Different levels of power management. The higher the
- number the greater the power savings, but with an impact to
- packet latencies.
-
-Power management works by powering down the radio after a certain
-interval of time has passed where no packets are passed through the
-radio. Once powered down, the radio remains in that state for a given
-period of time. For higher power savings, the interval between last
-packet processed to sleep is shorter and the sleep period is longer.
-
-When the radio is asleep, the access point sending data to the station
-must buffer packets at the AP until the station wakes up and requests
-any buffered packets. If you have an AP that does not correctly support
-the PSP protocol you may experience packet loss or very poor performance
-while power management is enabled. If this is the case, you will need
-to try and find a firmware update for your AP, or disable power
-management (via `iwconfig eth1 power off`)
-
-To configure the power level on the IPW2100 you use a combination of
-iwconfig and iwpriv. iwconfig is used to turn power management on, off,
-and set it to auto.
-
- iwconfig eth1 power off Disables radio power down
- iwconfig eth1 power on Enables radio power management to
- last set level (defaults to AUTO)
- iwpriv eth1 set_power 0 Sets power level to AUTO and enables
- power management if not previously
- enabled.
- iwpriv eth1 set_power 1-5 Set the power level as specified,
- enabling power management if not
- previously enabled.
-
-You can view the current power level setting via:
-
- iwpriv eth1 get_power
-
-It will return the current period or timeout that is configured as a string
-in the form of xxxx/yyyy (z) where xxxx is the timeout interval (amount of
-time after packet processing), yyyy is the period to sleep (amount of time to
-wait before powering the radio and querying the access point for buffered
-packets), and z is the 'power level'. If power management is turned off the
-xxxx/yyyy will be replaced with 'off' -- the level reported will be the active
-level if `iwconfig eth1 power on` is invoked.
-
-
-8. Support
------------------------------------------------
-
-For general development information and support,
-go to:
-
- http://ipw2100.sf.net/
-
-The ipw2100 1.1.0 driver and firmware can be downloaded from:
-
- http://support.intel.com
-
-For installation support on the ipw2100 1.1.0 driver on Linux kernels
-2.6.8 or greater, email support is available from:
-
- http://supportmail.intel.com
-
-9. License
------------------------------------------------
-
- Copyright(c) 2003 - 2006 Intel Corporation. All rights reserved.
-
- This program is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License (version 2) as
- published by the Free Software Foundation.
-
- 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.
-
- The full GNU General Public License is included in this distribution in the
- file called LICENSE.
-
- License Contact Information:
- James P. Ketrenos <ipw2100-admin@linux.intel.com>
- Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
deleted file mode 100644
index b7658bed490..00000000000
--- a/Documentation/networking/README.ipw2200
+++ /dev/null
@@ -1,472 +0,0 @@
-
-Intel(R) PRO/Wireless 2915ABG Driver for Linux in support of:
-
-Intel(R) PRO/Wireless 2200BG Network Connection
-Intel(R) PRO/Wireless 2915ABG Network Connection
-
-Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)
-PRO/Wireless 2200BG Driver for Linux is a unified driver that works on
-both hardware adapters listed above. In this document the Intel(R)
-PRO/Wireless 2915ABG Driver for Linux will be used to reference the
-unified driver.
-
-Copyright (C) 2004-2006, Intel Corporation
-
-README.ipw2200
-
-Version: 1.1.2
-Date : March 30, 2006
-
-
-Index
------------------------------------------------
-0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
-1. Introduction
-1.1. Overview of features
-1.2. Module parameters
-1.3. Wireless Extension Private Methods
-1.4. Sysfs Helper Files
-1.5. Supported channels
-2. Ad-Hoc Networking
-3. Interacting with Wireless Tools
-3.1. iwconfig mode
-3.2. iwconfig sens
-4. About the Version Numbers
-5. Firmware installation
-6. Support
-7. License
-
-
-0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
------------------------------------------------
-
-Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
-
-Intel wireless LAN adapters are engineered, manufactured, tested, and
-quality checked to ensure that they meet all necessary local and
-governmental regulatory agency requirements for the regions that they
-are designated and/or marked to ship into. Since wireless LANs are
-generally unlicensed devices that share spectrum with radars,
-satellites, and other licensed and unlicensed devices, it is sometimes
-necessary to dynamically detect, avoid, and limit usage to avoid
-interference with these devices. In many instances Intel is required to
-provide test data to prove regional and local compliance to regional and
-governmental regulations before certification or approval to use the
-product is granted. Intel's wireless LAN's EEPROM, firmware, and
-software driver are designed to carefully control parameters that affect
-radio operation and to ensure electromagnetic compliance (EMC). These
-parameters include, without limitation, RF power, spectrum usage,
-channel scanning, and human exposure.
-
-For these reasons Intel cannot permit any manipulation by third parties
-of the software provided in binary format with the wireless WLAN
-adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
-patches, utilities, or code with the Intel wireless LAN adapters that
-have been manipulated by an unauthorized party (i.e., patches,
-utilities, or code (including open source code modifications) which have
-not been validated by Intel), (i) you will be solely responsible for
-ensuring the regulatory compliance of the products, (ii) Intel will bear
-no liability, under any theory of liability for any issues associated
-with the modified products, including without limitation, claims under
-the warranty and/or issues arising from regulatory non-compliance, and
-(iii) Intel will not provide or be required to assist in providing
-support to any third parties for such modified products.
-
-Note: Many regulatory agencies consider Wireless LAN adapters to be
-modules, and accordingly, condition system-level regulatory approval
-upon receipt and review of test data documenting that the antennas and
-system configuration do not cause the EMC and radio operation to be
-non-compliant.
-
-The drivers available for download from SourceForge are provided as a
-part of a development project. Conformance to local regulatory
-requirements is the responsibility of the individual developer. As
-such, if you are interested in deploying or shipping a driver as part of
-solution intended to be used for purposes other than development, please
-obtain a tested driver from Intel Customer Support at:
-
-http://support.intel.com
-
-
-1. Introduction
------------------------------------------------
-The following sections attempt to provide a brief introduction to using
-the Intel(R) PRO/Wireless 2915ABG Driver for Linux.
-
-This document is not meant to be a comprehensive manual on
-understanding or using wireless technologies, but should be sufficient
-to get you moving without wires on Linux.
-
-For information on building and installing the driver, see the INSTALL
-file.
-
-
-1.1. Overview of Features
------------------------------------------------
-The current release (1.1.2) supports the following features:
-
-+ BSS mode (Infrastructure, Managed)
-+ IBSS mode (Ad-Hoc)
-+ WEP (OPEN and SHARED KEY mode)
-+ 802.1x EAP via wpa_supplicant and xsupplicant
-+ Wireless Extension support
-+ Full B and G rate support (2200 and 2915)
-+ Full A rate support (2915 only)
-+ Transmit power control
-+ S state support (ACPI suspend/resume)
-
-The following features are currently enabled, but not officially
-supported:
-
-+ WPA
-+ long/short preamble support
-+ Monitor mode (aka RFMon)
-
-The distinction between officially supported and enabled is a reflection
-on the amount of validation and interoperability testing that has been
-performed on a given feature.
-
-
-
-1.2. Command Line Parameters
------------------------------------------------
-
-Like many modules used in the Linux kernel, the Intel(R) PRO/Wireless
-2915ABG Driver for Linux allows configuration options to be provided
-as module parameters. The most common way to specify a module parameter
-is via the command line.
-
-The general form is:
-
-% modprobe ipw2200 parameter=value
-
-Where the supported parameter are:
-
- associate
- Set to 0 to disable the auto scan-and-associate functionality of the
- driver. If disabled, the driver will not attempt to scan
- for and associate to a network until it has been configured with
- one or more properties for the target network, for example configuring
- the network SSID. Default is 0 (do not auto-associate)
-
- Example: % modprobe ipw2200 associate=0
-
- auto_create
- Set to 0 to disable the auto creation of an Ad-Hoc network
- matching the channel and network name parameters provided.
- Default is 1.
-
- channel
- channel number for association. The normal method for setting
- the channel would be to use the standard wireless tools
- (i.e. `iwconfig eth1 channel 10`), but it is useful sometimes
- to set this while debugging. Channel 0 means 'ANY'
-
- debug
- If using a debug build, this is used to control the amount of debug
- info is logged. See the 'dvals' and 'load' script for more info on
- how to use this (the dvals and load scripts are provided as part
- of the ipw2200 development snapshot releases available from the
- SourceForge project at http://ipw2200.sf.net)
-
- led
- Can be used to turn on experimental LED code.
- 0 = Off, 1 = On. Default is 1.
-
- mode
- Can be used to set the default mode of the adapter.
- 0 = Managed, 1 = Ad-Hoc, 2 = Monitor
-
-
-1.3. Wireless Extension Private Methods
------------------------------------------------
-
-As an interface designed to handle generic hardware, there are certain
-capabilities not exposed through the normal Wireless Tool interface. As
-such, a provision is provided for a driver to declare custom, or
-private, methods. The Intel(R) PRO/Wireless 2915ABG Driver for Linux
-defines several of these to configure various settings.
-
-The general form of using the private wireless methods is:
-
- % iwpriv $IFNAME method parameters
-
-Where $IFNAME is the interface name the device is registered with
-(typically eth1, customized via one of the various network interface
-name managers, such as ifrename)
-
-The supported private methods are:
-
- get_mode
- Can be used to report out which IEEE mode the driver is
- configured to support. Example:
-
- % iwpriv eth1 get_mode
- eth1 get_mode:802.11bg (6)
-
- set_mode
- Can be used to configure which IEEE mode the driver will
- support.
-
- Usage:
- % iwpriv eth1 set_mode {mode}
- Where {mode} is a number in the range 1-7:
- 1 802.11a (2915 only)
- 2 802.11b
- 3 802.11ab (2915 only)
- 4 802.11g
- 5 802.11ag (2915 only)
- 6 802.11bg
- 7 802.11abg (2915 only)
-
- get_preamble
- Can be used to report configuration of preamble length.
-
- set_preamble
- Can be used to set the configuration of preamble length:
-
- Usage:
- % iwpriv eth1 set_preamble {mode}
- Where {mode} is one of:
- 1 Long preamble only
- 0 Auto (long or short based on connection)
-
-
-1.4. Sysfs Helper Files:
------------------------------------------------
-
-The Linux kernel provides a pseudo file system that can be used to
-access various components of the operating system. The Intel(R)
-PRO/Wireless 2915ABG Driver for Linux exposes several configuration
-parameters through this mechanism.
-
-An entry in the sysfs can support reading and/or writing. You can
-typically query the contents of a sysfs entry through the use of cat,
-and can set the contents via echo. For example:
-
-% cat /sys/bus/pci/drivers/ipw2200/debug_level
-
-Will report the current debug level of the driver's logging subsystem
-(only available if CONFIG_IPW2200_DEBUG was configured when the driver
-was built).
-
-You can set the debug level via:
-
-% echo $VALUE > /sys/bus/pci/drivers/ipw2200/debug_level
-
-Where $VALUE would be a number in the case of this sysfs entry. The
-input to sysfs files does not have to be a number. For example, the
-firmware loader used by hotplug utilizes sysfs entries for transferring
-the firmware image from user space into the driver.
-
-The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries
-at two levels -- driver level, which apply to all instances of the driver
-(in the event that there are more than one device installed) and device
-level, which applies only to the single specific instance.
-
-
-1.4.1 Driver Level Sysfs Helper Files
------------------------------------------------
-
-For the driver level files, look in /sys/bus/pci/drivers/ipw2200/
-
- debug_level
-
- This controls the same global as the 'debug' module parameter
-
-
-
-1.4.2 Device Level Sysfs Helper Files
------------------------------------------------
-
-For the device level files, look in
-
- /sys/bus/pci/drivers/ipw2200/{PCI-ID}/
-
-For example:
- /sys/bus/pci/drivers/ipw2200/0000:02:01.0
-
-For the device level files, see /sys/bus/pci/drivers/ipw2200:
-
- rf_kill
- read -
- 0 = RF kill not enabled (radio on)
- 1 = SW based RF kill active (radio off)
- 2 = HW based RF kill active (radio off)
- 3 = Both HW and SW RF kill active (radio off)
- write -
- 0 = If SW based RF kill active, turn the radio back on
- 1 = If radio is on, activate SW based RF kill
-
- NOTE: If you enable the SW based RF kill and then toggle the HW
- based RF kill from ON -> OFF -> ON, the radio will NOT come back on
-
- ucode
- read-only access to the ucode version number
-
- led
- read -
- 0 = LED code disabled
- 1 = LED code enabled
- write -
- 0 = Disable LED code
- 1 = Enable LED code
-
- NOTE: The LED code has been reported to hang some systems when
- running ifconfig and is therefore disabled by default.
-
-
-1.5. Supported channels
------------------------------------------------
-
-Upon loading the Intel(R) PRO/Wireless 2915ABG Driver for Linux, a
-message stating the detected geography code and the number of 802.11
-channels supported by the card will be displayed in the log.
-
-The geography code corresponds to a regulatory domain as shown in the
-table below.
-
- Supported channels
-Code Geography 802.11bg 802.11a
-
---- Restricted 11 0
-ZZF Custom US/Canada 11 8
-ZZD Rest of World 13 0
-ZZA Custom USA & Europe & High 11 13
-ZZB Custom NA & Europe 11 13
-ZZC Custom Japan 11 4
-ZZM Custom 11 0
-ZZE Europe 13 19
-ZZJ Custom Japan 14 4
-ZZR Rest of World 14 0
-ZZH High Band 13 4
-ZZG Custom Europe 13 4
-ZZK Europe 13 24
-ZZL Europe 11 13
-
-
-2. Ad-Hoc Networking
------------------------------------------------
-
-When using a device in an Ad-Hoc network, it is useful to understand the
-sequence and requirements for the driver to be able to create, join, or
-merge networks.
-
-The following attempts to provide enough information so that you can
-have a consistent experience while using the driver as a member of an
-Ad-Hoc network.
-
-2.1. Joining an Ad-Hoc Network
------------------------------------------------
-
-The easiest way to get onto an Ad-Hoc network is to join one that
-already exists.
-
-2.2. Creating an Ad-Hoc Network
------------------------------------------------
-
-An Ad-Hoc networks is created using the syntax of the Wireless tool.
-
-For Example:
-iwconfig eth1 mode ad-hoc essid testing channel 2
-
-2.3. Merging Ad-Hoc Networks
------------------------------------------------
-
-
-3. Interaction with Wireless Tools
------------------------------------------------
-
-3.1 iwconfig mode
------------------------------------------------
-
-When configuring the mode of the adapter, all run-time configured parameters
-are reset to the value used when the module was loaded. This includes
-channels, rates, ESSID, etc.
-
-3.2 iwconfig sens
------------------------------------------------
-
-The 'iwconfig ethX sens XX' command will not set the signal sensitivity
-threshold, as described in iwconfig documentation, but rather the number
-of consecutive missed beacons that will trigger handover, i.e. roaming
-to another access point. At the same time, it will set the disassociation
-threshold to 3 times the given value.
-
-
-4. About the Version Numbers
------------------------------------------------
-
-Due to the nature of open source development projects, there are
-frequently changes being incorporated that have not gone through
-a complete validation process. These changes are incorporated into
-development snapshot releases.
-
-Releases are numbered with a three level scheme:
-
- major.minor.development
-
-Any version where the 'development' portion is 0 (for example
-1.0.0, 1.1.0, etc.) indicates a stable version that will be made
-available for kernel inclusion.
-
-Any version where the 'development' portion is not a 0 (for
-example 1.0.1, 1.1.5, etc.) indicates a development version that is
-being made available for testing and cutting edge users. The stability
-and functionality of the development releases are not know. We make
-efforts to try and keep all snapshots reasonably stable, but due to the
-frequency of their release, and the desire to get those releases
-available as quickly as possible, unknown anomalies should be expected.
-
-The major version number will be incremented when significant changes
-are made to the driver. Currently, there are no major changes planned.
-
-5. Firmware installation
-----------------------------------------------
-
-The driver requires a firmware image, download it and extract the
-files under /lib/firmware (or wherever your hotplug's firmware.agent
-will look for firmware files)
-
-The firmware can be downloaded from the following URL:
-
- http://ipw2200.sf.net/
-
-
-6. Support
------------------------------------------------
-
-For direct support of the 1.0.0 version, you can contact
-http://supportmail.intel.com, or you can use the open source project
-support.
-
-For general information and support, go to:
-
- http://ipw2200.sf.net/
-
-
-7. License
------------------------------------------------
-
- Copyright(c) 2003 - 2006 Intel Corporation. All rights reserved.
-
- This program is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License version 2 as
- published by the Free Software Foundation.
-
- 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.
-
- The full GNU General Public License is included in this distribution in the
- file called LICENSE.
-
- Contact Information:
- James P. Ketrenos <ipw2100-admin@linux.intel.com>
- Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
diff --git a/Documentation/networking/README.sb1000 b/Documentation/networking/README.sb1000
deleted file mode 100644
index f92c2aac56a..00000000000
--- a/Documentation/networking/README.sb1000
+++ /dev/null
@@ -1,207 +0,0 @@
-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://web.archive.org/web/*/http://home.adelphia.net/~siglercm/sb1000.html
- http://web.archive.org/web/*/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/alias.txt b/Documentation/networking/alias.txt
deleted file mode 100644
index 85046f53fcf..00000000000
--- a/Documentation/networking/alias.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-
-IP-Aliasing:
-============
-
-IP-aliases are an obsolete way to manage multiple IP-addresses/masks
-per interface. Newer tools such as iproute2 support multiple
-address/prefixes per interface, but aliases are still supported
-for backwards compatibility.
-
-An alias is formed by adding a colon and a string when running ifconfig.
-This string is usually numeric, but this is not a must.
-
-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.
diff --git a/Documentation/networking/arcnet-hardware.txt b/Documentation/networking/arcnet-hardware.txt
deleted file mode 100644
index 731de411513..00000000000
--- a/Documentation/networking/arcnet-hardware.txt
+++ /dev/null
@@ -1,3133 +0,0 @@
-
------------------------------------------------------------------------------
-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 cannot 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
deleted file mode 100644
index 9ff57950215..00000000000
--- a/Documentation/networking/arcnet.txt
+++ /dev/null
@@ -1,555 +0,0 @@
-----------------------------------------------------------------------------
-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@infradead.org>, 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://epistolary.org/mailman/listinfo.cgi/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.qis.net/~jschmitz/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
deleted file mode 100644
index 82921cee77f..00000000000
--- a/Documentation/networking/atm.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-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
deleted file mode 100644
index 8257dbf9be5..00000000000
--- a/Documentation/networking/ax25.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-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
-AX.25, NET/ROM and ROSE, associated programs and and utilities can be
-found on http://www.linux-ax25.org.
-
-There is an active mailing list for discussing Linux amateur radio matters
-called linux-hams@vger.kernel.org. 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. You don't need to be
-subscribed to post but of course that means you might miss an answer.
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt
deleted file mode 100644
index 75a592365af..00000000000
--- a/Documentation/networking/batman-adv.txt
+++ /dev/null
@@ -1,242 +0,0 @@
-BATMAN-ADV
-----------
-
-Batman advanced is a new approach to wireless networking which
-does no longer operate on the IP basis. Unlike the batman daemon,
-which exchanges information using UDP packets and sets routing
-tables, batman-advanced operates on ISO/OSI Layer 2 only and uses
-and routes (or better: bridges) Ethernet Frames. It emulates a
-virtual network switch of all nodes participating. Therefore all
-nodes appear to be link local, thus all higher operating proto-
-cols won't be affected by any changes within the network. You can
-run almost any protocol above batman advanced, prominent examples
-are: IPv4, IPv6, DHCP, IPX.
-
-Batman advanced was implemented as a Linux kernel driver to re-
-duce the overhead to a minimum. It does not depend on any (other)
-network driver, and can be used on wifi as well as ethernet lan,
-vpn, etc ... (anything with ethernet-style layer 2).
-
-
-CONFIGURATION
--------------
-
-Load the batman-adv module into your kernel:
-
-# insmod batman-adv.ko
-
-The module is now waiting for activation. You must add some in-
-terfaces on which batman can operate. After loading the module
-batman advanced will scan your systems interfaces to search for
-compatible interfaces. Once found, it will create subfolders in
-the /sys directories of each supported interface, e.g.
-
-# ls /sys/class/net/eth0/batman_adv/
-# iface_status mesh_iface
-
-If an interface does not have the "batman_adv" subfolder it prob-
-ably is not supported. Not supported interfaces are: loopback,
-non-ethernet and batman's own interfaces.
-
-Note: After the module was loaded it will continuously watch for
-new interfaces to verify the compatibility. There is no need to
-reload the module if you plug your USB wifi adapter into your ma-
-chine after batman advanced was initially loaded.
-
-To activate a given interface simply write "bat0" into its
-"mesh_iface" file inside the batman_adv subfolder:
-
-# echo bat0 > /sys/class/net/eth0/batman_adv/mesh_iface
-
-Repeat this step for all interfaces you wish to add. Now batman
-starts using/broadcasting on this/these interface(s).
-
-By reading the "iface_status" file you can check its status:
-
-# cat /sys/class/net/eth0/batman_adv/iface_status
-# active
-
-To deactivate an interface you have to write "none" into its
-"mesh_iface" file:
-
-# echo none > /sys/class/net/eth0/batman_adv/mesh_iface
-
-
-All mesh wide settings can be found in batman's own interface
-folder:
-
-# ls /sys/class/net/bat0/mesh/
-# aggregated_ogms gw_bandwidth log_level
-# ap_isolation gw_mode orig_interval
-# bonding gw_sel_class routing_algo
-# bridge_loop_avoidance hop_penalty vis_mode
-# fragmentation
-
-
-There is a special folder for debugging information:
-
-# ls /sys/kernel/debug/batman_adv/bat0/
-# bla_claim_table log socket transtable_local
-# gateways originators transtable_global vis_data
-
-Some of the files contain all sort of status information regard-
-ing the mesh network. For example, you can view the table of
-originators (mesh participants) with:
-
-# cat /sys/kernel/debug/batman_adv/bat0/originators
-
-Other files allow to change batman's behaviour to better fit your
-requirements. For instance, you can check the current originator
-interval (value in milliseconds which determines how often batman
-sends its broadcast packets):
-
-# cat /sys/class/net/bat0/mesh/orig_interval
-# 1000
-
-and also change its value:
-
-# echo 3000 > /sys/class/net/bat0/mesh/orig_interval
-
-In very mobile scenarios, you might want to adjust the originator
-interval to a lower value. This will make the mesh more respon-
-sive to topology changes, but will also increase the overhead.
-
-
-USAGE
------
-
-To make use of your newly created mesh, batman advanced provides
-a new interface "bat0" which you should use from this point on.
-All interfaces added to batman advanced are not relevant any
-longer because batman handles them for you. Basically, one "hands
-over" the data by using the batman interface and batman will make
-sure it reaches its destination.
-
-The "bat0" interface can be used like any other regular inter-
-face. It needs an IP address which can be either statically con-
-figured or dynamically (by using DHCP or similar services):
-
-# NodeA: ifconfig bat0 192.168.0.1
-# NodeB: ifconfig bat0 192.168.0.2
-# NodeB: ping 192.168.0.1
-
-Note: In order to avoid problems remove all IP addresses previ-
-ously assigned to interfaces now used by batman advanced, e.g.
-
-# ifconfig eth0 0.0.0.0
-
-
-VISUALIZATION
--------------
-
-If you want topology visualization, at least one mesh node must
-be configured as VIS-server:
-
-# echo "server" > /sys/class/net/bat0/mesh/vis_mode
-
-Each node is either configured as "server" or as "client" (de-
-fault: "client"). Clients send their topology data to the server
-next to them, and server synchronize with other servers. If there
-is no server configured (default) within the mesh, no topology
-information will be transmitted. With these "synchronizing
-servers", there can be 1 or more vis servers sharing the same (or
-at least very similar) data.
-
-When configured as server, you can get a topology snapshot of
-your mesh:
-
-# cat /sys/kernel/debug/batman_adv/bat0/vis_data
-
-This raw output is intended to be easily parsable and convertable
-with other tools. Have a look at the batctl README if you want a
-vis output in dot or json format for instance and how those out-
-puts could then be visualised in an image.
-
-The raw format consists of comma separated values per entry where
-each entry is giving information about a certain source inter-
-face. Each entry can/has to have the following values:
--> "mac" - mac address of an originator's source interface
- (each line begins with it)
--> "TQ mac value" - src mac's link quality towards mac address
- of a neighbor originator's interface which
- is being used for routing
--> "TT mac" - TT announced by source mac
--> "PRIMARY" - this is a primary interface
--> "SEC mac" - secondary mac address of source
- (requires preceding PRIMARY)
-
-The TQ value has a range from 4 to 255 with 255 being the best.
-The TT entries are showing which hosts are connected to the mesh
-via bat0 or being bridged into the mesh network. The PRIMARY/SEC
-values are only applied on primary interfaces
-
-
-LOGGING/DEBUGGING
------------------
-
-All error messages, warnings and information messages are sent to
-the kernel log. Depending on your operating system distribution
-this can be read in one of a number of ways. Try using the com-
-mands: dmesg, logread, or looking in the files /var/log/kern.log
-or /var/log/syslog. All batman-adv messages are prefixed with
-"batman-adv:" So to see just these messages try
-
-# dmesg | grep batman-adv
-
-When investigating problems with your mesh network it is some-
-times necessary to see more detail debug messages. This must be
-enabled when compiling the batman-adv module. When building bat-
-man-adv as part of kernel, use "make menuconfig" and enable the
-option "B.A.T.M.A.N. debugging".
-
-Those additional debug messages can be accessed using a special
-file in debugfs
-
-# cat /sys/kernel/debug/batman_adv/bat0/log
-
-The additional debug output is by default disabled. It can be en-
-abled during run time. Following log_levels are defined:
-
-0 - All debug output disabled
-1 - Enable messages related to routing / flooding / broadcasting
-2 - Enable messages related to route added / changed / deleted
-4 - Enable messages related to translation table operations
-8 - Enable messages related to bridge loop avoidance
-15 - enable all messages
-
-The debug output can be changed at runtime using the file
-/sys/class/net/bat0/mesh/log_level. e.g.
-
-# echo 6 > /sys/class/net/bat0/mesh/log_level
-
-will enable debug messages for when routes change.
-
-
-BATCTL
-------
-
-As batman advanced operates on layer 2 all hosts participating in
-the virtual switch are completely transparent for all protocols
-above layer 2. Therefore the common diagnosis tools do not work
-as expected. To overcome these problems batctl was created. At
-the moment the batctl contains ping, traceroute, tcpdump and
-interfaces to the kernel module settings.
-
-For more information, please see the manpage (man batctl).
-
-batctl is available on http://www.open-mesh.org/
-
-
-CONTACT
--------
-
-Please send us comments, experiences, questions, anything :)
-
-IRC: #batman on irc.freenode.org
-Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription
- at https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n)
-
-You can also contact the Authors:
-
-Marek Lindner <lindner_marek@yahoo.de>
-Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
diff --git a/Documentation/networking/baycom.txt b/Documentation/networking/baycom.txt
deleted file mode 100644
index 688f18fd446..00000000000
--- a/Documentation/networking/baycom.txt
+++ /dev/null
@@ -1,158 +0,0 @@
- 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.d/*.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
deleted file mode 100644
index bfea8a33890..00000000000
--- a/Documentation/networking/bonding.txt
+++ /dev/null
@@ -1,2640 +0,0 @@
-
- Linux Ethernet Bonding Driver HOWTO
-
- Latest update: 27 April 2011
-
-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
-Added Sysfs information: 2006/04/24
- - Mitch Williams <mitch.a.williams at intel.com>
-
-Introduction
-============
-
- The Linux bonding driver provides a method for aggregating
-multiple network interfaces into a single logical "bonded" interface.
-The behavior of the bonded interfaces depends upon the mode; generally
-speaking, modes provide either hot standby or load balancing services.
-Additionally, link integrity monitoring may be performed.
-
- 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, updated userspace tools, and
-who to ask for help, 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.1.1 Using DHCP with Sysconfig
-3.1.2 Configuring Multiple Bonds with Sysconfig
-3.2 Configuration with Initscripts Support
-3.2.1 Using DHCP with Initscripts
-3.2.2 Configuring Multiple Bonds with Initscripts
-3.3 Configuring Bonding Manually with Ifenslave
-3.3.1 Configuring Multiple Bonds Manually
-3.4 Configuring Bonding Manually via Sysfs
-3.5 Configuration with Interfaces Support
-3.6 Overriding Configuration for Special Cases
-
-4. Querying Bonding Configuration
-4.1 Bonding Configuration
-4.2 Network Configuration
-
-5. Switch Configuration
-
-6. 802.1q VLAN Support
-
-7. Link Monitoring
-7.1 ARP Monitor Operation
-7.2 Configuring Multiple ARP Targets
-7.3 MII Monitor Operation
-
-8. Potential Trouble Sources
-8.1 Adventures in Routing
-8.2 Ethernet Device Renaming
-8.3 Painfully Slow Or No Failed Link Detection By Miimon
-
-9. SNMP agents
-
-10. Promiscuous mode
-
-11. Configuring Bonding for High Availability
-11.1 High Availability in a Single Switch Topology
-11.2 High Availability in a Multiple Switch Topology
-11.2.1 HA Bonding Mode Selection for Multiple Switch Topology
-11.2.2 HA Link Monitoring for Multiple Switch Topology
-
-12. Configuring Bonding for Maximum Throughput
-12.1 Maximum Throughput in a Single Switch Topology
-12.1.1 MT Bonding Mode Selection for Single Switch Topology
-12.1.2 MT Link Monitoring for Single Switch Topology
-12.2 Maximum Throughput in a Multiple Switch Topology
-12.2.1 MT Bonding Mode Selection for Multiple Switch Topology
-12.2.2 MT Link Monitoring for Multiple Switch Topology
-
-13. Switch Behavior Issues
-13.1 Link Establishment and Failover Delays
-13.2 Duplicated Incoming Packets
-
-14. Hardware Specific Considerations
-14.1 IBM BladeCenter
-
-15. Frequently Asked Questions
-
-16. 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 current 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). Most users "rolling their
-own" will want to use the most recent kernel from kernel.org.
-
- 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 continue
-below to install ifenslave.
-
-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.
-
-SECOND IMPORTANT NOTE:
- If you plan to configure bonding using sysfs or using the
-/etc/network/interfaces file, you do not need to use ifenslave.
-
-2. Bonding Driver Options
-=========================
-
- Options for the bonding driver are supplied as parameters to the
-bonding module at load time, or are specified via sysfs.
-
- Module options may be given as command line arguments to the
-insmod or modprobe command, but are usually specified in either the
-/etc/modrobe.d/*.conf configuration files, or in a distro-specific
-configuration file (some of which are detailed in the next section).
-
- Details on bonding support for sysfs is provided in the
-"Configuring Bonding Manually via Sysfs" section, below.
-
- 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:
-
-active_slave
-
- Specifies the new active slave for modes that support it
- (active-backup, balance-alb and balance-tlb). Possible values
- are the name of any currently enslaved interface, or an empty
- string. If a name is given, the slave and its link must be up in order
- to be selected as the new active slave. If an empty string is
- specified, the current active slave is cleared, and a new active
- slave is selected automatically.
-
- Note that this is only available through the sysfs interface. No module
- parameter by this name exists.
-
- The normal value of this option is the name of the currently
- active slave, or the empty string if there is no active slave or
- the current mode does not use an active slave.
-
-ad_select
-
- Specifies the 802.3ad aggregation selection logic to use. The
- possible values and their effects are:
-
- stable or 0
-
- The active aggregator is chosen by largest aggregate
- bandwidth.
-
- Reselection of the active aggregator occurs only when all
- slaves of the active aggregator are down or the active
- aggregator has no slaves.
-
- This is the default value.
-
- bandwidth or 1
-
- The active aggregator is chosen by largest aggregate
- bandwidth. Reselection occurs if:
-
- - A slave is added to or removed from the bond
-
- - Any slave's link state changes
-
- - Any slave's 802.3ad association state changes
-
- - The bond's administrative state changes to up
-
- count or 2
-
- The active aggregator is chosen by the largest number of
- ports (slaves). Reselection occurs as described under the
- "bandwidth" setting, above.
-
- The bandwidth and count selection policies permit failover of
- 802.3ad aggregations when partial failure of the active aggregator
- occurs. This keeps the aggregator with the highest availability
- (either in bandwidth or in number of ports) active at all times.
-
- This option was added in bonding version 3.4.0.
-
-all_slaves_active
-
- Specifies that duplicate frames (received on inactive ports) should be
- dropped (0) or delivered (1).
-
- Normally, bonding will drop duplicate frames (received on inactive
- ports), which is desirable for most users. But there are some times
- it is nice to allow duplicate frames to be delivered.
-
- The default value is 0 (drop duplicate frames received on inactive
- ports).
-
-arp_interval
-
- Specifies the ARP link monitoring frequency in milliseconds.
-
- The ARP monitor works by periodically checking the slave
- devices to determine whether they have sent or received
- traffic recently (the precise criteria depends upon the
- bonding mode, and the state of the slave). Regular traffic is
- generated via ARP probes issued for the addresses specified by
- the arp_ip_target option.
-
- This behavior can be modified by the arp_validate option,
- below.
-
- If ARP monitoring is used in an etherchannel compatible mode
- (modes 0 and 2), the switch should be configured in a mode
- that evenly distributes packets across all links. 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 as ARP monitoring peers 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
- addresses must be separated 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.
-
-arp_validate
-
- Specifies whether or not ARP probes and replies should be
- validated in the active-backup mode. This causes the ARP
- monitor to examine the incoming ARP requests and replies, and
- only consider a slave to be up if it is receiving the
- appropriate ARP traffic.
-
- Possible values are:
-
- none or 0
-
- No validation is performed. This is the default.
-
- active or 1
-
- Validation is performed only for the active slave.
-
- backup or 2
-
- Validation is performed only for backup slaves.
-
- all or 3
-
- Validation is performed for all slaves.
-
- For the active slave, the validation checks ARP replies to
- confirm that they were generated by an arp_ip_target. Since
- backup slaves do not typically receive these replies, the
- validation performed for backup slaves is on the ARP request
- sent out via the active slave. It is possible that some
- switch or network configurations may result in situations
- wherein the backup slaves do not receive the ARP requests; in
- such a situation, validation of backup slaves must be
- disabled.
-
- This option is useful in network configurations in which
- multiple bonding hosts are concurrently issuing ARPs to one or
- more targets beyond a common switch. Should the link between
- the switch and target fail (but not the switch itself), the
- probe traffic generated by the multiple bonding instances will
- fool the standard ARP monitor into considering the links as
- still up. Use of the arp_validate option can resolve this, as
- the ARP monitor will only consider ARP requests and replies
- associated with its own instance of bonding.
-
- This option was added in bonding version 3.1.0.
-
-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.
-
-fail_over_mac
-
- Specifies whether active-backup mode should set all slaves to
- the same MAC address at enslavement (the traditional
- behavior), or, when enabled, perform special handling of the
- bond's MAC address in accordance with the selected policy.
-
- Possible values are:
-
- none or 0
-
- This setting disables fail_over_mac, and causes
- bonding to set all slaves of an active-backup bond to
- the same MAC address at enslavement time. This is the
- default.
-
- active or 1
-
- The "active" fail_over_mac policy indicates that the
- MAC address of the bond should always be the MAC
- address of the currently active slave. The MAC
- address of the slaves is not changed; instead, the MAC
- address of the bond changes during a failover.
-
- This policy is useful for devices that cannot ever
- alter their MAC address, or for devices that refuse
- incoming broadcasts with their own source MAC (which
- interferes with the ARP monitor).
-
- The down side of this policy is that every device on
- the network must be updated via gratuitous ARP,
- vs. just updating a switch or set of switches (which
- often takes place for any traffic, not just ARP
- traffic, if the switch snoops incoming traffic to
- update its tables) for the traditional method. If the
- gratuitous ARP is lost, communication may be
- disrupted.
-
- When this policy is used in conjunction with the mii
- monitor, devices which assert link up prior to being
- able to actually transmit and receive are particularly
- susceptible to loss of the gratuitous ARP, and an
- appropriate updelay setting may be required.
-
- follow or 2
-
- The "follow" fail_over_mac policy causes the MAC
- address of the bond to be selected normally (normally
- the MAC address of the first slave added to the bond).
- However, the second and subsequent slaves are not set
- to this MAC address while they are in a backup role; a
- slave is programmed with the bond's MAC address at
- failover time (and the formerly active slave receives
- the newly active slave's MAC address).
-
- This policy is useful for multiport devices that
- either become confused or incur a performance penalty
- when multiple ports are programmed with the same MAC
- address.
-
-
- The default policy is none, unless the first slave cannot
- change its MAC address, in which case the active policy is
- selected by default.
-
- This option may be modified via sysfs only when no slaves are
- present in the bond.
-
- This option was added in bonding version 3.2.0. The "follow"
- policy was added in bonding version 3.3.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
-
- fast or 1
- Request partner to transmit LACPDUs every 1 second
-
- The default is slow.
-
-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. Specifying
- a value of 0 will load bonding, but will not create any devices.
-
-miimon
-
- Specifies the MII link monitoring frequency in milliseconds.
- This determines how often the link state of each slave is
- inspected for link failures. 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.
-
-min_links
-
- Specifies the minimum number of links that must be active before
- asserting carrier. It is similar to the Cisco EtherChannel min-links
- feature. This allows setting the minimum number of member ports that
- must be up (link-up state) before marking the bond device as up
- (carrier on). This is useful for situations where higher level services
- such as clustering want to ensure a minimum number of low bandwidth
- links are active before switchover. This option only affect 802.3ad
- mode.
-
- The default value is 0. This will cause carrier to be asserted (for
- 802.3ad mode) whenever there is an active aggregator, regardless of the
- number of available links in that aggregator. Note that, because an
- aggregator cannot be active without at least one available link,
- setting this option to 0 or to 1 has the exact same effect.
-
-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.
-
- In bonding version 2.6.2 or later, when a failover
- occurs in active-backup mode, bonding will issue one
- or more gratuitous ARPs on the newly active slave.
- One gratuitous ARP is issued for the bonding master
- interface and each VLAN interfaces configured above
- it, provided that the interface has at least one IP
- address configured. Gratuitous ARPs issued for VLAN
- interfaces are tagged with the appropriate VLAN id.
-
- This mode provides fault tolerance. The primary
- option, documented below, affects the behavior of this
- mode.
-
- balance-xor or 2
-
- XOR policy: Transmit based on the selected transmit
- hash policy. The default policy is a simple [(source
- MAC address XOR'd with destination MAC address) modulo
- slave count]. Alternate transmit policies may be
- selected via the xmit_hash_policy option, described
- below.
-
- 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.
-
- Slave selection for outgoing traffic is done according
- to the transmit hash policy, which may be changed from
- the default simple XOR policy via the xmit_hash_policy
- option, documented below. Note that not all transmit
- policies may be 802.3ad compliant, particularly in
- regards to the packet mis-ordering requirements of
- section 43.2.4 of the 802.3ad standard. Differing
- peer implementations will have varying tolerances for
- noncompliance.
-
- Prerequisites:
-
- 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 initiating 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.
-
-num_grat_arp
-num_unsol_na
-
- Specify the number of peer notifications (gratuitous ARPs and
- unsolicited IPv6 Neighbor Advertisements) to be issued after a
- failover event. As soon as the link is up on the new slave
- (possibly immediately) a peer notification is sent on the
- bonding device and each VLAN sub-device. This is repeated at
- each link monitor interval (arp_interval or miimon, whichever
- is active) if the number is greater than 1.
-
- The valid range is 0 - 255; the default value is 1. These options
- affect only the active-backup mode. These options were added for
- bonding versions 3.3.0 and 3.4.0 respectively.
-
- From Linux 3.0 and bonding version 3.7.1, these notifications
- are generated by the ipv4 and ipv6 code and the numbers of
- repetitions cannot be set independently.
-
-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.
-
-primary_reselect
-
- Specifies the reselection policy for the primary slave. This
- affects how the primary slave is chosen to become the active slave
- when failure of the active slave or recovery of the primary slave
- occurs. This option is designed to prevent flip-flopping between
- the primary slave and other slaves. Possible values are:
-
- always or 0 (default)
-
- The primary slave becomes the active slave whenever it
- comes back up.
-
- better or 1
-
- The primary slave becomes the active slave when it comes
- back up, if the speed and duplex of the primary slave is
- better than the speed and duplex of the current active
- slave.
-
- failure or 2
-
- The primary slave becomes the active slave only if the
- current active slave fails and the primary slave is up.
-
- The primary_reselect setting is ignored in two cases:
-
- If no slaves are active, the first slave to recover is
- made the active slave.
-
- When initially enslaved, the primary slave is always made
- the active slave.
-
- Changing the primary_reselect policy via sysfs will cause an
- immediate selection of the best active slave according to the new
- policy. This may or may not result in a change of the active
- slave, depending upon the circumstances.
-
- This option was added for bonding version 3.6.0.
-
-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.
-
-xmit_hash_policy
-
- Selects the transmit hash policy to use for slave selection in
- balance-xor and 802.3ad modes. Possible values are:
-
- layer2
-
- Uses XOR of hardware MAC addresses to generate the
- hash. The formula is
-
- (source MAC XOR destination MAC) modulo slave count
-
- This algorithm will place all traffic to a particular
- network peer on the same slave.
-
- This algorithm is 802.3ad compliant.
-
- layer2+3
-
- This policy uses a combination of layer2 and layer3
- protocol information to generate the hash.
-
- Uses XOR of hardware MAC addresses and IP addresses to
- generate the hash. The formula is
-
- (((source IP XOR dest IP) AND 0xffff) XOR
- ( source MAC XOR destination MAC ))
- modulo slave count
-
- This algorithm will place all traffic to a particular
- network peer on the same slave. For non-IP traffic,
- the formula is the same as for the layer2 transmit
- hash policy.
-
- This policy is intended to provide a more balanced
- distribution of traffic than layer2 alone, especially
- in environments where a layer3 gateway device is
- required to reach most destinations.
-
- This algorithm is 802.3ad compliant.
-
- layer3+4
-
- This policy uses upper layer protocol information,
- when available, to generate the hash. This allows for
- traffic to a particular network peer to span multiple
- slaves, although a single connection will not span
- multiple slaves.
-
- The formula for unfragmented TCP and UDP packets is
-
- ((source port XOR dest port) XOR
- ((source IP XOR dest IP) AND 0xffff)
- modulo slave count
-
- For fragmented TCP or UDP packets and all other IP
- protocol traffic, the source and destination port
- information is omitted. For non-IP traffic, the
- formula is the same as for the layer2 transmit hash
- policy.
-
- This policy is intended to mimic the behavior of
- certain switches, notably Cisco switches with PFC2 as
- well as some Foundry and IBM products.
-
- This algorithm is not fully 802.3ad compliant. A
- single TCP or UDP conversation containing both
- fragmented and unfragmented packets will see packets
- striped across two interfaces. This may result in out
- of order delivery. Most traffic types will not meet
- this criteria, as TCP rarely fragments traffic, and
- most UDP traffic is not involved in extended
- conversations. Other implementations of 802.3ad may
- or may not tolerate this noncompliance.
-
- The default value is layer2. This option was added in bonding
- version 2.6.3. In earlier versions of bonding, this parameter
- does not exist, and the layer2 policy is the only policy. The
- layer2+3 value was added for bonding version 3.2.2.
-
-resend_igmp
-
- Specifies the number of IGMP membership reports to be issued after
- a failover event. One membership report is issued immediately after
- the failover, subsequent packets are sent in each 200ms interval.
-
- The valid range is 0 - 255; the default value is 1. A value of 0
- prevents the IGMP membership report from being issued in response
- to the failover event.
-
- This option is useful for bonding modes balance-rr (0), active-backup
- (1), balance-tlb (5) and balance-alb (6), in which a failover can
- switch the IGMP traffic from one slave to another. Therefore a fresh
- IGMP report must be issued to cause the switch to forward the incoming
- IGMP traffic over the newly selected slave.
-
- This option was added for bonding version 3.7.0.
-
-3. Configuring Bonding Devices
-==============================
-
- You can configure bonding using either your distro's network
-initialization scripts, or manually using either ifenslave or the
-sysfs interface. Distros generally use one of three packages for the
-network initialization scripts: initscripts, sysconfig or interfaces.
-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, sysconfig and interfaces 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,
-initscripts or interfaces, or don't know if it's new enough, have no fear.
-Determining this is fairly straightforward.
-
- First, look for a file called interfaces in /etc/network directory.
-If this file is present in your system, then your system use interfaces. See
-Configuration with Interfaces Support.
-
- Else, 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
-front end 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 (this is only to get the
-file ifcfg-id file created; see below for some issues with 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 multiple 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="bus-pci-0000:06:08.1"
-
- Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK
-values with the appropriate values for your 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="slave device" for each
-slave. where "n" is an increasing value, one for each slave. The
-"slave device" is either an interface name, e.g., "eth0", or a device
-specifier for the network device. The interface name is easier to
-find, but the ethN names are subject to change at boot time if, e.g.,
-a device early in the sequence has failed. The device specifiers
-(bus-pci-0000:06:08.1 in the example above) specify the physical
-network device, and will not change unless the device's bus location
-changes (for example, it is moved from one PCI slot to another). The
-example above uses one of each type for demonstration purposes; most
-configurations will choose one or the other for all slave devices.
-
- 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 parameters 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.1.1 Using DHCP with Sysconfig
--------------------------------
-
- Under sysconfig, configuring a device with BOOTPROTO='dhcp'
-will cause it to query DHCP for its IP address information. At this
-writing, this does not function for bonding devices; 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.
-
-3.1.2 Configuring Multiple Bonds with Sysconfig
------------------------------------------------
-
- The sysconfig network initialization system is capable of
-handling multiple bonding devices. All that is necessary is for each
-bonding instance to have an appropriately configured ifcfg-bondX file
-(as described above). Do not specify the "max_bonds" parameter to any
-instance of bonding, as this will confuse sysconfig. If you require
-multiple bonding devices with identical parameters, create multiple
-ifcfg-bondX files.
-
- Because the sysconfig scripts supply the bonding module
-options in the ifcfg-bondX file, it is not necessary to add them to
-the system /etc/modules.d/*.conf configuration files.
-
-3.2 Configuration with Initscripts Support
-------------------------------------------
-
- This section applies to distros using a recent version of
-initscripts with bonding support, for example, Red Hat Enterprise Linux
-version 3 or later, Fedora, etc. On these systems, the network
-initialization scripts have knowledge of bonding, and can be configured to
-control bonding devices. Note that older versions of the initscripts
-package have lower levels of support for bonding; this will be noted where
-applicable.
-
- 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.
-
- For later versions of initscripts, such as that found with Fedora
-7 (or later) and Red Hat Enterprise Linux version 5 (or later), it is possible,
-and, indeed, preferable, to specify the bonding options in the ifcfg-bond0
-file, e.g. a line of the format:
-
-BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254"
-
- will configure the bond with the specified options. The options
-specified in BONDING_OPTS are identical to the bonding module parameters
-except for the arp_ip_target field when using versions of initscripts older
-than and 8.57 (Fedora 8) and 8.45.19 (Red Hat Enterprise Linux 5.2). When
-using older versions each target should be included as a separate option and
-should be preceded by a '+' to indicate it should be added to the list of
-queried targets, e.g.,
-
- arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2
-
- is the proper syntax to specify multiple targets. When specifying
-options via BONDING_OPTS, it is not necessary to edit /etc/modprobe.d/*.conf.
-
- For even older versions of initscripts that do not support
-BONDING_OPTS, it is necessary to edit /etc/modprobe.d/*.conf, depending upon
-your distro) to load the bonding module with your desired options when the
-bond0 interface is brought up. The following lines in /etc/modprobe.d/*.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.2.1 Using DHCP with Initscripts
----------------------------------
-
- Recent versions of initscripts (the versions supplied with Fedora
-Core 3 and Red Hat Enterprise Linux 4, or later versions, are reported to
-work) have support for assigning IP information to bonding devices via
-DHCP.
-
- To configure bonding for DHCP, configure it as described
-above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
-and add a line consisting of "TYPE=Bonding". Note that the TYPE value
-is case sensitive.
-
-3.2.2 Configuring Multiple Bonds with Initscripts
--------------------------------------------------
-
- Initscripts packages that are included with Fedora 7 and Red Hat
-Enterprise Linux 5 support multiple bonding interfaces by simply
-specifying the appropriate BONDING_OPTS= in ifcfg-bondX where X is the
-number of the bond. This support requires sysfs support in the kernel,
-and a bonding driver of version 3.0.0 or later. Other configurations may
-not support this method for specifying multiple bonding interfaces; for
-those instances, see the "Configuring Multiple Bonds Manually" section,
-below.
-
-3.3 Configuring Bonding Manually with Ifenslave
------------------------------------------------
-
- 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 method for these systems is to place the bonding
-module parameters into a config file in /etc/modprobe.d/ (as
-appropriate for the installed distro), 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 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.
-
- 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 bonding
-# rmmod e100
-
- Again, for convenience, it may be desirable to create a script
-with these commands.
-
-
-3.3.1 Configuring Multiple Bonds Manually
------------------------------------------
-
- This section contains information on configuring multiple
-bonding devices with differing options for those systems whose network
-initialization scripts lack support for configuring multiple bonds.
-
- If you require multiple bonding devices, but all with the same
-options, you may wish to use the "max_bonds" module parameter,
-documented above.
-
- To create multiple bonding devices with differing options, it is
-preferrable to use bonding parameters exported by sysfs, documented in the
-section below.
-
- For versions of bonding without sysfs support, the only means to
-provide multiple instances of bonding with differing options is 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.d/*.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.
-
- In some circumstances (typically with older distributions),
-the above does not work, and the second bonding instance never sees
-its options. In that case, the second options line can be substituted
-as follows:
-
-install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
- mode=balance-alb miimon=50
-
- This may be repeated any number of times, specifying a new and
-unique name in place of bond1 for each subsequent instance.
-
- It has been observed that some Red Hat supplied kernels are unable
-to rename modules at load time (the "-o bond1" part). Attempts to pass
-that option to modprobe will produce an "Operation not permitted" error.
-This has been reported on some Fedora Core kernels, and has been seen on
-RHEL 4 as well. On kernels exhibiting this problem, it will be impossible
-to configure multiple bonds with differing parameters (as they are older
-kernels, and also lack sysfs support).
-
-3.4 Configuring Bonding Manually via Sysfs
-------------------------------------------
-
- Starting with version 3.0.0, Channel Bonding may be configured
-via the sysfs interface. This interface allows dynamic configuration
-of all bonds in the system without unloading the module. It also
-allows for adding and removing bonds at runtime. Ifenslave is no
-longer required, though it is still supported.
-
- Use of the sysfs interface allows you to use multiple bonds
-with different configurations without having to reload the module.
-It also allows you to use multiple, differently configured bonds when
-bonding is compiled into the kernel.
-
- You must have the sysfs filesystem mounted to configure
-bonding this way. The examples in this document assume that you
-are using the standard mount point for sysfs, e.g. /sys. If your
-sysfs filesystem is mounted elsewhere, you will need to adjust the
-example paths accordingly.
-
-Creating and Destroying Bonds
------------------------------
-To add a new bond foo:
-# echo +foo > /sys/class/net/bonding_masters
-
-To remove an existing bond bar:
-# echo -bar > /sys/class/net/bonding_masters
-
-To show all existing bonds:
-# cat /sys/class/net/bonding_masters
-
-NOTE: due to 4K size limitation of sysfs files, this list may be
-truncated if you have more than a few hundred bonds. This is unlikely
-to occur under normal operating conditions.
-
-Adding and Removing Slaves
---------------------------
- Interfaces may be enslaved to a bond using the file
-/sys/class/net/<bond>/bonding/slaves. The semantics for this file
-are the same as for the bonding_masters file.
-
-To enslave interface eth0 to bond bond0:
-# ifconfig bond0 up
-# echo +eth0 > /sys/class/net/bond0/bonding/slaves
-
-To free slave eth0 from bond bond0:
-# echo -eth0 > /sys/class/net/bond0/bonding/slaves
-
- When an interface is enslaved to a bond, symlinks between the
-two are created in the sysfs filesystem. In this case, you would get
-/sys/class/net/bond0/slave_eth0 pointing to /sys/class/net/eth0, and
-/sys/class/net/eth0/master pointing to /sys/class/net/bond0.
-
- This means that you can tell quickly whether or not an
-interface is enslaved by looking for the master symlink. Thus:
-# echo -eth0 > /sys/class/net/eth0/master/bonding/slaves
-will free eth0 from whatever bond it is enslaved to, regardless of
-the name of the bond interface.
-
-Changing a Bond's Configuration
--------------------------------
- Each bond may be configured individually by manipulating the
-files located in /sys/class/net/<bond name>/bonding
-
- The names of these files correspond directly with the command-
-line parameters described elsewhere in this file, and, with the
-exception of arp_ip_target, they accept the same values. To see the
-current setting, simply cat the appropriate file.
-
- A few examples will be given here; for specific usage
-guidelines for each parameter, see the appropriate section in this
-document.
-
-To configure bond0 for balance-alb mode:
-# ifconfig bond0 down
-# echo 6 > /sys/class/net/bond0/bonding/mode
- - or -
-# echo balance-alb > /sys/class/net/bond0/bonding/mode
- NOTE: The bond interface must be down before the mode can be
-changed.
-
-To enable MII monitoring on bond0 with a 1 second interval:
-# echo 1000 > /sys/class/net/bond0/bonding/miimon
- NOTE: If ARP monitoring is enabled, it will disabled when MII
-monitoring is enabled, and vice-versa.
-
-To add ARP targets:
-# echo +192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
-# echo +192.168.0.101 > /sys/class/net/bond0/bonding/arp_ip_target
- NOTE: up to 16 target addresses may be specified.
-
-To remove an ARP target:
-# echo -192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
-
-Example Configuration
----------------------
- We begin with the same example that is shown in section 3.3,
-executed with sysfs, and without using ifenslave.
-
- 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
-modprobe e100
-echo balance-alb > /sys/class/net/bond0/bonding/mode
-ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
-echo 100 > /sys/class/net/bond0/bonding/miimon
-echo +eth0 > /sys/class/net/bond0/bonding/slaves
-echo +eth1 > /sys/class/net/bond0/bonding/slaves
-
- To add a second bond, with two e1000 interfaces in
-active-backup mode, using ARP monitoring, add the following lines to
-your init script:
-
-modprobe e1000
-echo +bond1 > /sys/class/net/bonding_masters
-echo active-backup > /sys/class/net/bond1/bonding/mode
-ifconfig bond1 192.168.2.1 netmask 255.255.255.0 up
-echo +192.168.2.100 /sys/class/net/bond1/bonding/arp_ip_target
-echo 2000 > /sys/class/net/bond1/bonding/arp_interval
-echo +eth2 > /sys/class/net/bond1/bonding/slaves
-echo +eth3 > /sys/class/net/bond1/bonding/slaves
-
-3.5 Configuration with Interfaces Support
------------------------------------------
-
- This section applies to distros which use /etc/network/interfaces file
-to describe network interface configuration, most notably Debian and it's
-derivatives.
-
- The ifup and ifdown commands on Debian don't support bonding out of
-the box. The ifenslave-2.6 package should be installed to provide bonding
-support. Once installed, this package will provide bond-* options to be used
-into /etc/network/interfaces.
-
- Note that ifenslave-2.6 package will load the bonding module and use
-the ifenslave command when appropriate.
-
-Example Configurations
-----------------------
-
-In /etc/network/interfaces, the following stanza will configure bond0, in
-active-backup mode, with eth0 and eth1 as slaves.
-
-auto bond0
-iface bond0 inet dhcp
- bond-slaves eth0 eth1
- bond-mode active-backup
- bond-miimon 100
- bond-primary eth0 eth1
-
-If the above configuration doesn't work, you might have a system using
-upstart for system startup. This is most notably true for recent
-Ubuntu versions. The following stanza in /etc/network/interfaces will
-produce the same result on those systems.
-
-auto bond0
-iface bond0 inet dhcp
- bond-slaves none
- bond-mode active-backup
- bond-miimon 100
-
-auto eth0
-iface eth0 inet manual
- bond-master bond0
- bond-primary eth0 eth1
-
-auto eth1
-iface eth1 inet manual
- bond-master bond0
- bond-primary eth0 eth1
-
-For a full list of bond-* supported options in /etc/network/interfaces and some
-more advanced examples tailored to you particular distros, see the files in
-/usr/share/doc/ifenslave-2.6.
-
-3.6 Overriding Configuration for Special Cases
-----------------------------------------------
-
-When using the bonding driver, the physical port which transmits a frame is
-typically selected by the bonding driver, and is not relevant to the user or
-system administrator. The output port is simply selected using the policies of
-the selected bonding mode. On occasion however, it is helpful to direct certain
-classes of traffic to certain physical interfaces on output to implement
-slightly more complex policies. For example, to reach a web server over a
-bonded interface in which eth0 connects to a private network, while eth1
-connects via a public network, it may be desirous to bias the bond to send said
-traffic over eth0 first, using eth1 only as a fall back, while all other traffic
-can safely be sent over either interface. Such configurations may be achieved
-using the traffic control utilities inherent in linux.
-
-By default the bonding driver is multiqueue aware and 16 queues are created
-when the driver initializes (see Documentation/networking/multiqueue.txt
-for details). If more or less queues are desired the module parameter
-tx_queues can be used to change this value. There is no sysfs parameter
-available as the allocation is done at module init time.
-
-The output of the file /proc/net/bonding/bondX has changed so the output Queue
-ID is now printed for each slave:
-
-Bonding Mode: fault-tolerance (active-backup)
-Primary Slave: None
-Currently Active Slave: eth0
-MII Status: up
-MII Polling Interval (ms): 0
-Up Delay (ms): 0
-Down Delay (ms): 0
-
-Slave Interface: eth0
-MII Status: up
-Link Failure Count: 0
-Permanent HW addr: 00:1a:a0:12:8f:cb
-Slave queue ID: 0
-
-Slave Interface: eth1
-MII Status: up
-Link Failure Count: 0
-Permanent HW addr: 00:1a:a0:12:8f:cc
-Slave queue ID: 2
-
-The queue_id for a slave can be set using the command:
-
-# echo "eth1:2" > /sys/class/net/bond0/bonding/queue_id
-
-Any interface that needs a queue_id set should set it with multiple calls
-like the one above until proper priorities are set for all interfaces. On
-distributions that allow configuration via initscripts, multiple 'queue_id'
-arguments can be added to BONDING_OPTS to set all needed slave queues.
-
-These queue id's can be used in conjunction with the tc utility to configure
-a multiqueue qdisc and filters to bias certain traffic to transmit on certain
-slave devices. For instance, say we wanted, in the above configuration to
-force all traffic bound to 192.168.1.100 to use eth1 in the bond as its output
-device. The following commands would accomplish this:
-
-# tc qdisc add dev bond0 handle 1 root multiq
-
-# tc filter add dev bond0 protocol ip parent 1: prio 1 u32 match ip dst \
- 192.168.1.100 action skbedit queue_mapping 2
-
-These commands tell the kernel to attach a multiqueue queue discipline to the
-bond0 interface and filter traffic enqueued to it, such that packets with a dst
-ip of 192.168.1.100 have their output queue mapping value overwritten to 2.
-This value is then passed into the driver, causing the normal output path
-selection policy to be overridden, selecting instead qid 2, which maps to eth1.
-
-Note that qid values begin at 1. Qid 0 is reserved to initiate to the driver
-that normal output policy selection should take place. One benefit to simply
-leaving the qid for a slave to 0 is the multiqueue awareness in the bonding
-driver that is now present. This awareness allows tc filters to be placed on
-slave devices as well as bond devices and the bonding driver will simply act as
-a pass-through for selecting output queues on the slave device rather than
-output port selection.
-
-This feature first appeared in bonding driver version 3.7.0 and support for
-output slave selection was limited to round-robin and active-backup modes.
-
-4 Querying Bonding Configuration
-=================================
-
-4.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.
-
-4.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
- 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
- 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
-
-5. 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.
-
-
-6. 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 offloading, the bonding
-interface declares itself as fully hardware offloading 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 promiscuous
-mode, which might not be what you want.
-
-
-7. 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.
-
-7.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.
-
-7.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 separated 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
-
-
-7.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.
-
-8. Potential Sources of Trouble
-===============================
-
-8.1 Adventures in Routing
--------------------------
-
- When bonding is configured, it is important that the slave
-devices not have routes that supersede 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 supersede routes of their master. This should generally be the
-case, but unusual configurations or errant manual or automatic static
-route additions may cause trouble.
-
-8.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 config files in
-/etc/modprobe.d/.
-
- 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 an equivalent problem can occur.
-In this case, the following can be added to config files in
-/etc/modprobe.d/ as:
-
-softdep bonding pre: tg3 e1000
-
- This will load tg3 and e1000 modules before loading the bonding one.
-Full documentation on this can be found in the modprobe.d and modprobe
-manual pages.
-
-8.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.
-
-9. 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 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.
-
-10. 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 propagates the setting to the slave
-devices.
-
- For the balance-rr, balance-xor, broadcast, and 802.3ad modes,
-the promiscuous mode setting is propagated to all slaves.
-
- For the active-backup, balance-tlb and balance-alb modes, the
-promiscuous mode setting is propagated 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 propagated to the new active slave.
-
-11. Configuring Bonding for High Availability
-=============================================
-
- High Availability refers to configurations that provide
-maximum network availability by having redundant or backup devices,
-links or switches between the host and the rest of the world. The
-goal is to provide the maximum availability of network connectivity
-(i.e., the network always works), even though other configurations
-could provide higher throughput.
-
-11.1 High Availability in a Single Switch Topology
---------------------------------------------------
-
- If two hosts (or a host and a single switch) are directly
-connected via multiple physical links, then there is no availability
-penalty to optimizing for maximum bandwidth. In this case, there is
-only one switch (or peer), so if it fails, there is no alternative
-access to fail over to. Additionally, the bonding load balance modes
-support link monitoring of their members, so if individual links fail,
-the load will be rebalanced across the remaining devices.
-
- See Section 13, "Configuring Bonding for Maximum Throughput"
-for information on configuring bonding with one peer device.
-
-11.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 trade off 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.
-
-11.2.1 HA Bonding Mode Selection for Multiple Switch Topology
--------------------------------------------------------------
-
- In a topology such as the example above, the active-backup and
-broadcast modes are the only useful bonding modes when optimizing for
-availability; 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 independent. 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.
-
-11.2.2 HA 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 end to
-end connectivity failures (which may be caused by the failure of any
-individual component to pass traffic for any reason). Additionally,
-the ARP monitor 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.
-
- Note, also, that of late many switches now support a functionality
-generally referred to as "trunk failover." This is a feature of the
-switch that causes the link state of a particular switch port to be set
-down (or up) when the state of another switch port goes down (or up).
-Its purpose is to propagate link failures from logically "exterior" ports
-to the logically "interior" ports that bonding is able to monitor via
-miimon. Availability and configuration for trunk failover varies by
-switch, but this can be a viable alternative to the ARP monitor when using
-suitable switches.
-
-12. Configuring Bonding for Maximum Throughput
-==============================================
-
-12.1 Maximizing Throughput in a Single Switch Topology
-------------------------------------------------------
-
- In a single switch configuration, the best method to maximize
-throughput depends upon the application and network environment. The
-various load balancing modes each have strengths and weaknesses in
-different environments, as detailed below.
-
- For this discussion, we will break down the topologies into
-two categories. Depending upon the destination of most traffic, we
-categorize them into either "gatewayed" or "local" configurations.
-
- In a gatewayed configuration, the "switch" is acting primarily
-as a router, and the majority of traffic passes through this router to
-other networks. An example would be the following:
-
-
- +----------+ +----------+
- | |eth0 port1| | to other networks
- | Host A +---------------------+ router +------------------->
- | +---------------------+ | Hosts B and C are out
- | |eth1 port2| | here somewhere
- +----------+ +----------+
-
- The router may be a dedicated router device, or another host
-acting as a gateway. For our discussion, the important point is that
-the majority of traffic from Host A will pass through the router to
-some other network before reaching its final destination.
-
- In a gatewayed network configuration, although Host A may
-communicate with many other systems, all of its traffic will be sent
-and received via one other peer on the local network, the router.
-
- Note that the case of two systems connected directly via
-multiple physical links is, for purposes of configuring bonding, the
-same as a gatewayed configuration. In that case, it happens that all
-traffic is destined for the "gateway" itself, not some other network
-beyond the gateway.
-
- In a local configuration, the "switch" is acting primarily as
-a switch, and the majority of traffic passes through this switch to
-reach other stations on the same network. An example would be the
-following:
-
- +----------+ +----------+ +--------+
- | |eth0 port1| +-------+ Host B |
- | Host A +------------+ switch |port3 +--------+
- | +------------+ | +--------+
- | |eth1 port2| +------------------+ Host C |
- +----------+ +----------+port4 +--------+
-
-
- Again, the switch may be a dedicated switch device, or another
-host acting as a gateway. For our discussion, the important point is
-that the majority of traffic from Host A is destined for other hosts
-on the same local network (Hosts B and C in the above example).
-
- In summary, in a gatewayed configuration, traffic to and from
-the bonded device will be to the same MAC level peer on the network
-(the gateway itself, i.e., the router), regardless of its final
-destination. In a local configuration, traffic flows directly to and
-from the final destinations, thus, each destination (Host B, Host C)
-will be addressed directly by their individual MAC addresses.
-
- This distinction between a gatewayed and a local network
-configuration is important because many of the load balancing modes
-available use the MAC addresses of the local network source and
-destination to make load balancing decisions. The behavior of each
-mode is described below.
-
-
-12.1.1 MT 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 trade offs 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 generally 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.
-
- Note that the fraction of packets that will be delivered out of
- order is highly variable, and is unlikely to be zero. The level
- of reordering depends upon a variety of factors, including the
- networking interfaces, the switch, and the topology of the
- configuration. Speaking in general terms, higher speed network
- cards produce more reordering (due to factors such as packet
- coalescing), and a "many to many" topology will reorder at a
- higher rate than a "many slow to one fast" configuration.
-
- Many switches do not support any modes that stripe traffic
- (instead choosing a port based upon IP or MAC level addresses);
- for those devices, traffic for a particular connection flowing
- through the switch to a balance-rr bond will not utilize greater
- than one interface's worth of bandwidth.
-
- 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, active-backup mode
- does not require any configuration of the switch, so it may
- have value if the hardware available does not support any of
- the load balance modes.
-
-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 mode works best in a "local" network
- configuration (as described above), with destinations all on
- the same local network. This mode is likely to be suboptimal
- if all your traffic is passed through a single router (i.e., a
- "gatewayed" network configuration, as described above).
-
- 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
- available 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 a "gatewayed" configuration, all outgoing traffic will
- generally use the same device. Incoming traffic may also end
- up on a single device, but that is dependent upon the
- balancing policy of the peer's 8023.ad implementation. In a
- "local" configuration, traffic will be distributed across the
- devices in the bond.
-
- Finally, the 802.3ad mode mandates the use of the MII monitor,
- therefore, the ARP monitor is not available in this mode.
-
-balance-tlb: The balance-tlb mode balances outgoing traffic by peer.
- Since the balancing is done according to MAC address, in a
- "gatewayed" configuration (as described above), this mode will
- send all traffic across a single device. However, in a
- "local" network configuration, this mode balances multiple
- local network peers across devices in a vaguely intelligent
- manner (not a simple XOR as in balance-xor or 802.3ad mode),
- so that mathematically unlucky MAC addresses (i.e., ones that
- XOR to the same value) will not all "bunch up" on a single
- interface.
-
- Unlike 802.3ad, interfaces may be of differing speeds, and no
- special switch configuration is required. 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 local network
- peers (as described in the Bonding Module Options section,
- above).
-
- The only additional 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 MT 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 end to end
-assurance as the ARP monitor).
-
-12.2 Maximum Throughput in a Multiple Switch Topology
------------------------------------------------------
-
- Multiple switches may be utilized to optimize for throughput
-when they are configured in parallel as part of an isolated network
-between two or more systems, for example:
-
- +-----------+
- | Host A |
- +-+---+---+-+
- | | |
- +--------+ | +---------+
- | | |
- +------+---+ +-----+----+ +-----+----+
- | Switch A | | Switch B | | Switch C |
- +------+---+ +-----+----+ +-----+----+
- | | |
- +--------+ | +---------+
- | | |
- +-+---+---+-+
- | Host B |
- +-----------+
-
- In this configuration, the switches are isolated from one
-another. One reason to employ a topology such as this is for an
-isolated network with many hosts (a cluster configured for high
-performance, for example), using multiple smaller switches can be more
-cost effective than a single larger switch, e.g., on a network with 24
-hosts, three 24 port switches can be significantly less expensive than
-a single 72 port switch.
-
- If access beyond the network is required, an individual host
-can be equipped with an additional network device connected to an
-external network; this host then additionally acts as a gateway.
-
-12.2.1 MT Bonding Mode Selection for Multiple Switch Topology
--------------------------------------------------------------
-
- In actual practice, the bonding mode typically employed in
-configurations of this type is balance-rr. Historically, in this
-network configuration, the usual caveats about out of order packet
-delivery are mitigated by the use of network adapters that do not do
-any kind of packet coalescing (via the use of NAPI, or because the
-device itself does not generate interrupts until some number of
-packets has arrived). When employed in this fashion, the balance-rr
-mode allows individual connections between two hosts to effectively
-utilize greater than one interface's bandwidth.
-
-12.2.2 MT Link Monitoring for Multiple Switch Topology
-------------------------------------------------------
-
- Again, in actual practice, the MII monitor is most often used
-in this configuration, as performance is given preference over
-availability. The ARP monitor will function in this topology, but its
-advantages over the MII monitor are mitigated by the volume of probes
-needed as the number of systems involved grows (remember that each
-host in the network is configured with bonding).
-
-13. Switch Behavior Issues
-==========================
-
-13.1 Link Establishment and Failover Delays
--------------------------------------------
-
- Some switches exhibit undesirable behavior with regard to 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.
-
- Note that when a bonding interface has no active links, the
-driver will immediately reuse the first link that goes up, even if the
-updelay parameter has been specified (the updelay is ignored in this
-case). 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, and since this occurs only in
-cases with no connectivity, there is no additional penalty for
-ignoring the updelay.
-
- 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.2 Duplicated Incoming Packets
---------------------------------
-
- NOTE: Starting with version 3.0.2, the bonding driver has logic to
-suppress duplicate packets, which should largely eliminate this problem.
-The following description is kept for reference.
-
- It is not uncommon to observe a short burst of duplicated
-traffic when the bonding device is first used, or after it has been
-idle for some period of time. This is most easily observed by issuing
-a "ping" to some other host on the network, and noticing that the
-output from ping flags duplicates (typically one per slave).
-
- For example, on a bond in active-backup mode with five slaves
-all connected to one switch, the output may appear as follows:
-
-# ping -n 10.0.4.2
-PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data.
-64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms
-64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
-64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
-64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
-64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
-64 bytes from 10.0.4.2: icmp_seq=2 ttl=64 time=0.216 ms
-64 bytes from 10.0.4.2: icmp_seq=3 ttl=64 time=0.267 ms
-64 bytes from 10.0.4.2: icmp_seq=4 ttl=64 time=0.222 ms
-
- This is not due to an error in the bonding driver, rather, it
-is a side effect of how many switches update their MAC forwarding
-tables. Initially, the switch does not associate the MAC address in
-the packet with a particular switch port, and so it may send the
-traffic to all ports until its MAC forwarding table is updated. Since
-the interfaces attached to the bond may occupy multiple ports on a
-single switch, when the switch (temporarily) floods the traffic to all
-ports, the bond device receives multiple copies of the same packet
-(one per slave device).
-
- The duplicated packet behavior is switch dependent, some
-switches exhibit this, and some do not. On switches that display this
-behavior, it can be induced by clearing the MAC forwarding table (on
-most Cisco switches, the privileged command "clear mac address-table
-dynamic" will accomplish this).
-
-14. 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.
-
-14.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 (that's "motherboard" in IBM-speak). 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 (ESMs) 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).
-
- A passthrough module (OPM or CPM, optical or copper,
-passthrough module) connects the I/O module directly to an external
-switch. By using PMs 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 ESMs and PMs, the network will
-appear to bonding as either a single switch topology (all PMs) or as a
-multiple switch topology (one or more ESMs, zero or more PMs). It is
-also possible to connect ESMs together, resulting in a configuration
-much like the example in "High Availability in a Multiple Switch
-Topology," above.
-
-Requirements for specific modes
--------------------------------
-
- The balance-rr mode requires the use of passthrough 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 (SoL) 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, as the SoL system is beyond the control of the
-bonding driver.
-
- 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 delay issues when using bonding.
-
-
-15. 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). For most modes,
-devices need not be of the same speed.
-
- Starting with version 3.2.1, bonding also supports Infiniband
-slaves in active-backup mode.
-
-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 sections on High
-Availability and the documentation for each mode for additional
-information.
-
- Link monitoring can be enabled via either the miimon or
-arp_interval parameters (described in the module parameters 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 degradation 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 unmanaged 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 parameters, above).
-
- In 802.3ad mode, it works 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?
-
- When using slave devices that have fixed MAC addresses, or when
-the fail_over_mac option is enabled, the bonding device's MAC address is
-the MAC address of the active slave.
-
- For other configurations, if not explicitly configured (with
-ifconfig or ip link), 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 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 or ip link:
-
-# ifconfig bond0 hw ether 00:11:22:33:44:55
-
-# ip link set bond0 address 66:77:88:99:aa:bb
-
- 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.
-
-16. 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
-
- The latest version of this document can be found in the latest kernel
-source (named Documentation/networking/bonding.txt).
-
- Discussions regarding the usage of the bonding driver take place on the
-bonding-devel mailing list, hosted at sourceforge.net. If you have questions or
-problems, post them to the list. The list address is:
-
-bonding-devel@lists.sourceforge.net
-
- The administrative interface (to subscribe or unsubscribe) can
-be found at:
-
-https://lists.sourceforge.net/lists/listinfo/bonding-devel
-
- Discussions regarding the developpement of the bonding driver take place
-on the main Linux network mailing list, hosted at vger.kernel.org. The list
-address is:
-
-netdev@vger.kernel.org
-
- The administrative interface (to subscribe or unsubscribe) can
-be found at:
-
-http://vger.kernel.org/vger-lists.html#netdev
-
-Donald Becker's Ethernet Drivers and diag programs may be found at :
- - http://web.archive.org/web/*/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
deleted file mode 100644
index a7ba5e4e2c9..00000000000
--- a/Documentation/networking/bridge.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-In order to use the Ethernet bridging functionality, you'll need the
-userspace tools. These programs and documentation are available
-at http://www.linuxfoundation.org/en/Net:Bridge. 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 https://lists.linux-foundation.org/mailman/listinfo/bridge).
-
diff --git a/Documentation/networking/caif/Linux-CAIF.txt b/Documentation/networking/caif/Linux-CAIF.txt
deleted file mode 100644
index e52fd62bef3..00000000000
--- a/Documentation/networking/caif/Linux-CAIF.txt
+++ /dev/null
@@ -1,212 +0,0 @@
-Linux CAIF
-===========
-copyright (C) ST-Ericsson AB 2010
-Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
-License terms: GNU General Public License (GPL) version 2
-
-
-Introduction
-------------
-CAIF is a MUX protocol used by ST-Ericsson cellular modems for
-communication between Modem and host. The host processes can open virtual AT
-channels, initiate GPRS Data connections, Video channels and Utility Channels.
-The Utility Channels are general purpose pipes between modem and host.
-
-ST-Ericsson modems support a number of transports between modem
-and host. Currently, UART and Loopback are available for Linux.
-
-
-Architecture:
-------------
-The implementation of CAIF is divided into:
-* CAIF Socket Layer, Kernel API, and Net Device.
-* CAIF Core Protocol Implementation
-* CAIF Link Layer, implemented as NET devices.
-
-
- RTNL
- !
- ! +------+ +------+ +------+
- ! +------+! +------+! +------+!
- ! ! Sock !! !Kernel!! ! Net !!
- ! ! API !+ ! API !+ ! Dev !+ <- CAIF Client APIs
- ! +------+ +------! +------+
- ! ! ! !
- ! +----------!----------+
- ! +------+ <- CAIF Protocol Implementation
- +-------> ! CAIF !
- ! Core !
- +------+
- +--------!--------+
- ! !
- +------+ +-----+
- ! ! ! TTY ! <- Link Layer (Net Devices)
- +------+ +-----+
-
-
-Using the Kernel API
-----------------------
-The Kernel API is used for accessing CAIF channels from the
-kernel.
-The user of the API has to implement two callbacks for receive
-and control.
-The receive callback gives a CAIF packet as a SKB. The control
-callback will
-notify of channel initialization complete, and flow-on/flow-
-off.
-
-
- struct caif_device caif_dev = {
- .caif_config = {
- .name = "MYDEV"
- .type = CAIF_CHTY_AT
- }
- .receive_cb = my_receive,
- .control_cb = my_control,
- };
- caif_add_device(&caif_dev);
- caif_transmit(&caif_dev, skb);
-
-See the caif_kernel.h for details about the CAIF kernel API.
-
-
-I M P L E M E N T A T I O N
-===========================
-===========================
-
-CAIF Core Protocol Layer
-=========================================
-
-CAIF Core layer implements the CAIF protocol as defined by ST-Ericsson.
-It implements the CAIF protocol stack in a layered approach, where
-each layer described in the specification is implemented as a separate layer.
-The architecture is inspired by the design patterns "Protocol Layer" and
-"Protocol Packet".
-
-== CAIF structure ==
-The Core CAIF implementation contains:
- - Simple implementation of CAIF.
- - Layered architecture (a la Streams), each layer in the CAIF
- specification is implemented in a separate c-file.
- - Clients must implement PHY layer to access physical HW
- with receive and transmit functions.
- - Clients must call configuration function to add PHY layer.
- - Clients must implement CAIF layer to consume/produce
- CAIF payload with receive and transmit functions.
- - Clients must call configuration function to add and connect the
- Client layer.
- - When receiving / transmitting CAIF Packets (cfpkt), ownership is passed
- to the called function (except for framing layers' receive functions
- or if a transmit function returns an error, in which case the caller
- must free the packet).
-
-Layered Architecture
---------------------
-The CAIF protocol can be divided into two parts: Support functions and Protocol
-Implementation. The support functions include:
-
- - CFPKT CAIF Packet. Implementation of CAIF Protocol Packet. The
- CAIF Packet has functions for creating, destroying and adding content
- and for adding/extracting header and trailers to protocol packets.
-
- - CFLST CAIF list implementation.
-
- - CFGLUE CAIF Glue. Contains OS Specifics, such as memory
- allocation, endianness, etc.
-
-The CAIF Protocol implementation contains:
-
- - CFCNFG CAIF Configuration layer. Configures the CAIF Protocol
- Stack and provides a Client interface for adding Link-Layer and
- Driver interfaces on top of the CAIF Stack.
-
- - CFCTRL CAIF Control layer. Encodes and Decodes control messages
- such as enumeration and channel setup. Also matches request and
- response messages.
-
- - CFSERVL General CAIF Service Layer functionality; handles flow
- control and remote shutdown requests.
-
- - CFVEI CAIF VEI layer. Handles CAIF AT Channels on VEI (Virtual
- External Interface). This layer encodes/decodes VEI frames.
-
- - CFDGML CAIF Datagram layer. Handles CAIF Datagram layer (IP
- traffic), encodes/decodes Datagram frames.
-
- - CFMUX CAIF Mux layer. Handles multiplexing between multiple
- physical bearers and multiple channels such as VEI, Datagram, etc.
- The MUX keeps track of the existing CAIF Channels and
- Physical Instances and selects the appropriate instance based
- on Channel-Id and Physical-ID.
-
- - CFFRML CAIF Framing layer. Handles Framing i.e. Frame length
- and frame checksum.
-
- - CFSERL CAIF Serial layer. Handles concatenation/split of frames
- into CAIF Frames with correct length.
-
-
-
- +---------+
- | Config |
- | CFCNFG |
- +---------+
- !
- +---------+ +---------+ +---------+
- | AT | | Control | | Datagram|
- | CFVEIL | | CFCTRL | | CFDGML |
- +---------+ +---------+ +---------+
- \_____________!______________/
- !
- +---------+
- | MUX |
- | |
- +---------+
- _____!_____
- / \
- +---------+ +---------+
- | CFFRML | | CFFRML |
- | Framing | | Framing |
- +---------+ +---------+
- ! !
- +---------+ +---------+
- | | | Serial |
- | | | CFSERL |
- +---------+ +---------+
-
-
-In this layered approach the following "rules" apply.
- - All layers embed the same structure "struct cflayer"
- - A layer does not depend on any other layer's private data.
- - Layers are stacked by setting the pointers
- layer->up , layer->dn
- - In order to send data upwards, each layer should do
- layer->up->receive(layer->up, packet);
- - In order to send data downwards, each layer should do
- layer->dn->transmit(layer->dn, packet);
-
-
-Linux Driver Implementation
-===========================
-
-Linux GPRS Net Device and CAIF socket are implemented on top of the
-CAIF Core protocol. The Net device and CAIF socket have an instance of
-'struct cflayer', just like the CAIF Core protocol stack.
-Net device and Socket implement the 'receive()' function defined by
-'struct cflayer', just like the rest of the CAIF stack. In this way, transmit and
-receive of packets is handled as by the rest of the layers: the 'dn->transmit()'
-function is called in order to transmit data.
-
-The layer on top of the CAIF Core implementation is
-sometimes referred to as the "Client layer".
-
-
-Configuration of Link Layer
----------------------------
-The Link Layer is implemented as Linux net devices (struct net_device).
-Payload handling and registration is done using standard Linux mechanisms.
-
-The CAIF Protocol relies on a loss-less link layer without implementing
-retransmission. This implies that packet drops must not happen.
-Therefore a flow-control mechanism is implemented where the physical
-interface can initiate flow stop for all CAIF Channels.
diff --git a/Documentation/networking/caif/README b/Documentation/networking/caif/README
deleted file mode 100644
index 757ccfaa138..00000000000
--- a/Documentation/networking/caif/README
+++ /dev/null
@@ -1,109 +0,0 @@
-Copyright (C) ST-Ericsson AB 2010
-Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
-License terms: GNU General Public License (GPL) version 2
----------------------------------------------------------
-
-=== Start ===
-If you have compiled CAIF for modules do:
-
-$modprobe crc_ccitt
-$modprobe caif
-$modprobe caif_socket
-$modprobe chnl_net
-
-
-=== Preparing the setup with a STE modem ===
-
-If you are working on integration of CAIF you should make sure
-that the kernel is built with module support.
-
-There are some things that need to be tweaked to get the host TTY correctly
-set up to talk to the modem.
-Since the CAIF stack is running in the kernel and we want to use the existing
-TTY, we are installing our physical serial driver as a line discipline above
-the TTY device.
-
-To achieve this we need to install the N_CAIF ldisc from user space.
-The benefit is that we can hook up to any TTY.
-
-The use of Start-of-frame-extension (STX) must also be set as
-module parameter "ser_use_stx".
-
-Normally Frame Checksum is always used on UART, but this is also provided as a
-module parameter "ser_use_fcs".
-
-$ modprobe caif_serial ser_ttyname=/dev/ttyS0 ser_use_stx=yes
-$ ifconfig caif_ttyS0 up
-
-PLEASE NOTE: There is a limitation in Android shell.
- It only accepts one argument to insmod/modprobe!
-
-=== Trouble shooting ===
-
-There are debugfs parameters provided for serial communication.
-/sys/kernel/debug/caif_serial/<tty-name>/
-
-* ser_state: Prints the bit-mask status where
- - 0x02 means SENDING, this is a transient state.
- - 0x10 means FLOW_OFF_SENT, i.e. the previous frame has not been sent
- and is blocking further send operation. Flow OFF has been propagated
- to all CAIF Channels using this TTY.
-
-* tty_status: Prints the bit-mask tty status information
- - 0x01 - tty->warned is on.
- - 0x02 - tty->low_latency is on.
- - 0x04 - tty->packed is on.
- - 0x08 - tty->flow_stopped is on.
- - 0x10 - tty->hw_stopped is on.
- - 0x20 - tty->stopped is on.
-
-* last_tx_msg: Binary blob Prints the last transmitted frame.
- This can be printed with
- $od --format=x1 /sys/kernel/debug/caif_serial/<tty>/last_rx_msg.
- The first two tx messages sent look like this. Note: The initial
- byte 02 is start of frame extension (STX) used for re-syncing
- upon errors.
-
- - Enumeration:
- 0000000 02 05 00 00 03 01 d2 02
- | | | | | |
- STX(1) | | | |
- Length(2)| | |
- Control Channel(1)
- Command:Enumeration(1)
- Link-ID(1)
- Checksum(2)
- - Channel Setup:
- 0000000 02 07 00 00 00 21 a1 00 48 df
- | | | | | | | |
- STX(1) | | | | | |
- Length(2)| | | | |
- Control Channel(1)
- Command:Channel Setup(1)
- Channel Type(1)
- Priority and Link-ID(1)
- Endpoint(1)
- Checksum(2)
-
-* last_rx_msg: Prints the last transmitted frame.
- The RX messages for LinkSetup look almost identical but they have the
- bit 0x20 set in the command bit, and Channel Setup has added one byte
- before Checksum containing Channel ID.
- NOTE: Several CAIF Messages might be concatenated. The maximum debug
- buffer size is 128 bytes.
-
-== Error Scenarios:
-- last_tx_msg contains channel setup message and last_rx_msg is empty ->
- The host seems to be able to send over the UART, at least the CAIF ldisc get
- notified that sending is completed.
-
-- last_tx_msg contains enumeration message and last_rx_msg is empty ->
- The host is not able to send the message from UART, the tty has not been
- able to complete the transmit operation.
-
-- if /sys/kernel/debug/caif_serial/<tty>/tty_status is non-zero there
- might be problems transmitting over UART.
- E.g. host and modem wiring is not correct you will typically see
- tty_status = 0x10 (hw_stopped) and ser_state = 0x10 (FLOW_OFF_SENT).
- You will probably see the enumeration message in last_tx_message
- and empty last_rx_message.
diff --git a/Documentation/networking/caif/spi_porting.txt b/Documentation/networking/caif/spi_porting.txt
deleted file mode 100644
index 9efd0687dc4..00000000000
--- a/Documentation/networking/caif/spi_porting.txt
+++ /dev/null
@@ -1,208 +0,0 @@
-- CAIF SPI porting -
-
-- CAIF SPI basics:
-
-Running CAIF over SPI needs some extra setup, owing to the nature of SPI.
-Two extra GPIOs have been added in order to negotiate the transfers
- between the master and the slave. The minimum requirement for running
-CAIF over SPI is a SPI slave chip and two GPIOs (more details below).
-Please note that running as a slave implies that you need to keep up
-with the master clock. An overrun or underrun event is fatal.
-
-- CAIF SPI framework:
-
-To make porting as easy as possible, the CAIF SPI has been divided in
-two parts. The first part (called the interface part) deals with all
-generic functionality such as length framing, SPI frame negotiation
-and SPI frame delivery and transmission. The other part is the CAIF
-SPI slave device part, which is the module that you have to write if
-you want to run SPI CAIF on a new hardware. This part takes care of
-the physical hardware, both with regard to SPI and to GPIOs.
-
-- Implementing a CAIF SPI device:
-
- - Functionality provided by the CAIF SPI slave device:
-
- In order to implement a SPI device you will, as a minimum,
- need to implement the following
- functions:
-
- int (*init_xfer) (struct cfspi_xfer * xfer, struct cfspi_dev *dev):
-
- This function is called by the CAIF SPI interface to give
- you a chance to set up your hardware to be ready to receive
- a stream of data from the master. The xfer structure contains
- both physical and logical addresses, as well as the total length
- of the transfer in both directions.The dev parameter can be used
- to map to different CAIF SPI slave devices.
-
- void (*sig_xfer) (bool xfer, struct cfspi_dev *dev):
-
- This function is called by the CAIF SPI interface when the output
- (SPI_INT) GPIO needs to change state. The boolean value of the xfer
- variable indicates whether the GPIO should be asserted (HIGH) or
- deasserted (LOW). The dev parameter can be used to map to different CAIF
- SPI slave devices.
-
- - Functionality provided by the CAIF SPI interface:
-
- void (*ss_cb) (bool assert, struct cfspi_ifc *ifc);
-
- This function is called by the CAIF SPI slave device in order to
- signal a change of state of the input GPIO (SS) to the interface.
- Only active edges are mandatory to be reported.
- This function can be called from IRQ context (recommended in order
- not to introduce latency). The ifc parameter should be the pointer
- returned from the platform probe function in the SPI device structure.
-
- void (*xfer_done_cb) (struct cfspi_ifc *ifc);
-
- This function is called by the CAIF SPI slave device in order to
- report that a transfer is completed. This function should only be
- called once both the transmission and the reception are completed.
- This function can be called from IRQ context (recommended in order
- not to introduce latency). The ifc parameter should be the pointer
- returned from the platform probe function in the SPI device structure.
-
- - Connecting the bits and pieces:
-
- - Filling in the SPI slave device structure:
-
- Connect the necessary callback functions.
- Indicate clock speed (used to calculate toggle delays).
- Chose a suitable name (helps debugging if you use several CAIF
- SPI slave devices).
- Assign your private data (can be used to map to your structure).
-
- - Filling in the SPI slave platform device structure:
- Add name of driver to connect to ("cfspi_sspi").
- Assign the SPI slave device structure as platform data.
-
-- Padding:
-
-In order to optimize throughput, a number of SPI padding options are provided.
-Padding can be enabled independently for uplink and downlink transfers.
-Padding can be enabled for the head, the tail and for the total frame size.
-The padding needs to be correctly configured on both sides of the link.
-The padding can be changed via module parameters in cfspi_sspi.c or via
-the sysfs directory of the cfspi_sspi driver (before device registration).
-
-- CAIF SPI device template:
-
-/*
- * Copyright (C) ST-Ericsson AB 2010
- * Author: Daniel Martensson / Daniel.Martensson@stericsson.com
- * License terms: GNU General Public License (GPL), version 2.
- *
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/device.h>
-#include <linux/wait.h>
-#include <linux/interrupt.h>
-#include <linux/dma-mapping.h>
-#include <net/caif/caif_spi.h>
-
-MODULE_LICENSE("GPL");
-
-struct sspi_struct {
- struct cfspi_dev sdev;
- struct cfspi_xfer *xfer;
-};
-
-static struct sspi_struct slave;
-static struct platform_device slave_device;
-
-static irqreturn_t sspi_irq(int irq, void *arg)
-{
- /* You only need to trigger on an edge to the active state of the
- * SS signal. Once a edge is detected, the ss_cb() function should be
- * called with the parameter assert set to true. It is OK
- * (and even advised) to call the ss_cb() function in IRQ context in
- * order not to add any delay. */
-
- return IRQ_HANDLED;
-}
-
-static void sspi_complete(void *context)
-{
- /* Normally the DMA or the SPI framework will call you back
- * in something similar to this. The only thing you need to
- * do is to call the xfer_done_cb() function, providing the pointer
- * to the CAIF SPI interface. It is OK to call this function
- * from IRQ context. */
-}
-
-static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev)
-{
- /* Store transfer info. For a normal implementation you should
- * set up your DMA here and make sure that you are ready to
- * receive the data from the master SPI. */
-
- struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
-
- sspi->xfer = xfer;
-
- return 0;
-}
-
-void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
-{
- /* If xfer is true then you should assert the SPI_INT to indicate to
- * the master that you are ready to receive the data from the master
- * SPI. If xfer is false then you should de-assert SPI_INT to indicate
- * that the transfer is done.
- */
-
- struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
-}
-
-static void sspi_release(struct device *dev)
-{
- /*
- * Here you should release your SPI device resources.
- */
-}
-
-static int __init sspi_init(void)
-{
- /* Here you should initialize your SPI device by providing the
- * necessary functions, clock speed, name and private data. Once
- * done, you can register your device with the
- * platform_device_register() function. This function will return
- * with the CAIF SPI interface initialized. This is probably also
- * the place where you should set up your GPIOs, interrupts and SPI
- * resources. */
-
- int res = 0;
-
- /* Initialize slave device. */
- slave.sdev.init_xfer = sspi_init_xfer;
- slave.sdev.sig_xfer = sspi_sig_xfer;
- slave.sdev.clk_mhz = 13;
- slave.sdev.priv = &slave;
- slave.sdev.name = "spi_sspi";
- slave_device.dev.release = sspi_release;
-
- /* Initialize platform device. */
- slave_device.name = "cfspi_sspi";
- slave_device.dev.platform_data = &slave.sdev;
-
- /* Register platform device. */
- res = platform_device_register(&slave_device);
- if (res) {
- printk(KERN_WARNING "sspi_init: failed to register dev.\n");
- return -ENODEV;
- }
-
- return res;
-}
-
-static void __exit sspi_exit(void)
-{
- platform_device_del(&slave_device);
-}
-
-module_init(sspi_init);
-module_exit(sspi_exit);
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
deleted file mode 100644
index ac295399f0d..00000000000
--- a/Documentation/networking/can.txt
+++ /dev/null
@@ -1,836 +0,0 @@
-============================================================================
-
-can.txt
-
-Readme file for the Controller Area Network Protocol Family (aka Socket CAN)
-
-This file contains
-
- 1 Overview / What is Socket CAN
-
- 2 Motivation / Why using the socket API
-
- 3 Socket CAN concept
- 3.1 receive lists
- 3.2 local loopback of sent frames
- 3.3 network security issues (capabilities)
- 3.4 network problem notifications
-
- 4 How to use Socket CAN
- 4.1 RAW protocol sockets with can_filters (SOCK_RAW)
- 4.1.1 RAW socket option CAN_RAW_FILTER
- 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
- 4.1.3 RAW socket option CAN_RAW_LOOPBACK
- 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
- 4.1.5 RAW socket returned message flags
- 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
- 4.3 connected transport protocols (SOCK_SEQPACKET)
- 4.4 unconnected transport protocols (SOCK_DGRAM)
-
- 5 Socket CAN core module
- 5.1 can.ko module params
- 5.2 procfs content
- 5.3 writing own CAN protocol modules
-
- 6 CAN network drivers
- 6.1 general settings
- 6.2 local loopback of sent frames
- 6.3 CAN controller hardware filters
- 6.4 The virtual CAN driver (vcan)
- 6.5 The CAN network device driver interface
- 6.5.1 Netlink interface to set/get devices properties
- 6.5.2 Setting the CAN bit-timing
- 6.5.3 Starting and stopping the CAN network device
- 6.6 supported CAN hardware
-
- 7 Socket CAN resources
-
- 8 Credits
-
-============================================================================
-
-1. Overview / What is Socket CAN
---------------------------------
-
-The socketcan package is an implementation of CAN protocols
-(Controller Area Network) for Linux. CAN is a networking technology
-which has widespread use in automation, embedded devices, and
-automotive fields. While there have been other CAN implementations
-for Linux based on character devices, Socket CAN uses the Berkeley
-socket API, the Linux network stack and implements the CAN device
-drivers as network interfaces. The CAN socket API has been designed
-as similar as possible to the TCP/IP protocols to allow programmers,
-familiar with network programming, to easily learn how to use CAN
-sockets.
-
-2. Motivation / Why using the socket API
-----------------------------------------
-
-There have been CAN implementations for Linux before Socket CAN so the
-question arises, why we have started another project. Most existing
-implementations come as a device driver for some CAN hardware, they
-are based on character devices and provide comparatively little
-functionality. Usually, there is only a hardware-specific device
-driver which provides a character device interface to send and
-receive raw CAN frames, directly to/from the controller hardware.
-Queueing of frames and higher-level transport protocols like ISO-TP
-have to be implemented in user space applications. Also, most
-character-device implementations support only one single process to
-open the device at a time, similar to a serial interface. Exchanging
-the CAN controller requires employment of another device driver and
-often the need for adaption of large parts of the application to the
-new driver's API.
-
-Socket CAN was designed to overcome all of these limitations. A new
-protocol family has been implemented which provides a socket interface
-to user space applications and which builds upon the Linux network
-layer, so to use all of the provided queueing functionality. A device
-driver for CAN controller hardware registers itself with the Linux
-network layer as a network device, so that CAN frames from the
-controller can be passed up to the network layer and on to the CAN
-protocol family module and also vice-versa. Also, the protocol family
-module provides an API for transport protocol modules to register, so
-that any number of transport protocols can be loaded or unloaded
-dynamically. In fact, the can core module alone does not provide any
-protocol and cannot be used without loading at least one additional
-protocol module. Multiple sockets can be opened at the same time,
-on different or the same protocol module and they can listen/send
-frames on different or the same CAN IDs. Several sockets listening on
-the same interface for frames with the same CAN ID are all passed the
-same received matching CAN frames. An application wishing to
-communicate using a specific transport protocol, e.g. ISO-TP, just
-selects that protocol when opening the socket, and then can read and
-write application data byte streams, without having to deal with
-CAN-IDs, frames, etc.
-
-Similar functionality visible from user-space could be provided by a
-character device, too, but this would lead to a technically inelegant
-solution for a couple of reasons:
-
-* Intricate usage. Instead of passing a protocol argument to
- socket(2) and using bind(2) to select a CAN interface and CAN ID, an
- application would have to do all these operations using ioctl(2)s.
-
-* Code duplication. A character device cannot make use of the Linux
- network queueing code, so all that code would have to be duplicated
- for CAN networking.
-
-* Abstraction. In most existing character-device implementations, the
- hardware-specific device driver for a CAN controller directly
- provides the character device for the application to work with.
- This is at least very unusual in Unix systems for both, char and
- block devices. For example you don't have a character device for a
- certain UART of a serial interface, a certain sound chip in your
- computer, a SCSI or IDE controller providing access to your hard
- disk or tape streamer device. Instead, you have abstraction layers
- which provide a unified character or block device interface to the
- application on the one hand, and a interface for hardware-specific
- device drivers on the other hand. These abstractions are provided
- by subsystems like the tty layer, the audio subsystem or the SCSI
- and IDE subsystems for the devices mentioned above.
-
- The easiest way to implement a CAN device driver is as a character
- device without such a (complete) abstraction layer, as is done by most
- existing drivers. The right way, however, would be to add such a
- layer with all the functionality like registering for certain CAN
- IDs, supporting several open file descriptors and (de)multiplexing
- CAN frames between them, (sophisticated) queueing of CAN frames, and
- providing an API for device drivers to register with. However, then
- it would be no more difficult, or may be even easier, to use the
- networking framework provided by the Linux kernel, and this is what
- Socket CAN does.
-
- The use of the networking framework of the Linux kernel is just the
- natural and most appropriate way to implement CAN for Linux.
-
-3. Socket CAN concept
----------------------
-
- As described in chapter 2 it is the main goal of Socket CAN to
- provide a socket interface to user space applications which builds
- upon the Linux network layer. In contrast to the commonly known
- TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!)
- medium that has no MAC-layer addressing like ethernet. The CAN-identifier
- (can_id) is used for arbitration on the CAN-bus. Therefore the CAN-IDs
- have to be chosen uniquely on the bus. When designing a CAN-ECU
- network the CAN-IDs are mapped to be sent by a specific ECU.
- For this reason a CAN-ID can be treated best as a kind of source address.
-
- 3.1 receive lists
-
- The network transparent access of multiple applications leads to the
- problem that different applications may be interested in the same
- CAN-IDs from the same CAN network interface. The Socket CAN core
- module - which implements the protocol family CAN - provides several
- high efficient receive lists for this reason. If e.g. a user space
- application opens a CAN RAW socket, the raw protocol module itself
- requests the (range of) CAN-IDs from the Socket CAN core that are
- requested by the user. The subscription and unsubscription of
- CAN-IDs can be done for specific CAN interfaces or for all(!) known
- CAN interfaces with the can_rx_(un)register() functions provided to
- CAN protocol modules by the SocketCAN core (see chapter 5).
- To optimize the CPU usage at runtime the receive lists are split up
- into several specific lists per device that match the requested
- filter complexity for a given use-case.
-
- 3.2 local loopback of sent frames
-
- As known from other networking concepts the data exchanging
- applications may run on the same or different nodes without any
- change (except for the according addressing information):
-
- ___ ___ ___ _______ ___
- | _ | | _ | | _ | | _ _ | | _ |
- ||A|| ||B|| ||C|| ||A| |B|| ||C||
- |___| |___| |___| |_______| |___|
- | | | | |
- -----------------(1)- CAN bus -(2)---------------
-
- To ensure that application A receives the same information in the
- example (2) as it would receive in example (1) there is need for
- some kind of local loopback of the sent CAN frames on the appropriate
- node.
-
- The Linux network devices (by default) just can handle the
- transmission and reception of media dependent frames. Due to the
- arbitration on the CAN bus the transmission of a low prio CAN-ID
- may be delayed by the reception of a high prio CAN frame. To
- reflect the correct* traffic on the node the loopback of the sent
- data has to be performed right after a successful transmission. If
- the CAN network interface is not capable of performing the loopback for
- some reason the SocketCAN core can do this task as a fallback solution.
- See chapter 6.2 for details (recommended).
-
- The loopback functionality is enabled by default to reflect standard
- networking behaviour for CAN applications. Due to some requests from
- the RT-SocketCAN group the loopback optionally may be disabled for each
- separate socket. See sockopts from the CAN RAW sockets in chapter 4.1.
-
- * = you really like to have this when you're running analyser tools
- like 'candump' or 'cansniffer' on the (same) node.
-
- 3.3 network security issues (capabilities)
-
- The Controller Area Network is a local field bus transmitting only
- broadcast messages without any routing and security concepts.
- In the majority of cases the user application has to deal with
- raw CAN frames. Therefore it might be reasonable NOT to restrict
- the CAN access only to the user root, as known from other networks.
- Since the currently implemented CAN_RAW and CAN_BCM sockets can only
- send and receive frames to/from CAN interfaces it does not affect
- security of others networks to allow all users to access the CAN.
- To enable non-root users to access CAN_RAW and CAN_BCM protocol
- sockets the Kconfig options CAN_RAW_USER and/or CAN_BCM_USER may be
- selected at kernel compile time.
-
- 3.4 network problem notifications
-
- The use of the CAN bus may lead to several problems on the physical
- and media access control layer. Detecting and logging of these lower
- layer problems is a vital requirement for CAN users to identify
- hardware issues on the physical transceiver layer as well as
- arbitration problems and error frames caused by the different
- ECUs. The occurrence of detected errors are important for diagnosis
- and have to be logged together with the exact timestamp. For this
- reason the CAN interface driver can generate so called Error Frames
- that can optionally be passed to the user application in the same
- way as other CAN frames. Whenever an error on the physical layer
- or the MAC layer is detected (e.g. by the CAN controller) the driver
- creates an appropriate error frame. Error frames can be requested by
- the user application using the common CAN filter mechanisms. Inside
- this filter definition the (interested) type of errors may be
- selected. The reception of error frames is disabled by default.
- The format of the CAN error frame is briefly described in the Linux
- header file "include/linux/can/error.h".
-
-4. How to use Socket CAN
-------------------------
-
- Like TCP/IP, you first need to open a socket for communicating over a
- CAN network. Since Socket CAN implements a new protocol family, you
- need to pass PF_CAN as the first argument to the socket(2) system
- call. Currently, there are two CAN protocols to choose from, the raw
- socket protocol and the broadcast manager (BCM). So to open a socket,
- you would write
-
- s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
-
- and
-
- s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
-
- respectively. After the successful creation of the socket, you would
- normally use the bind(2) system call to bind the socket to a CAN
- interface (which is different from TCP/IP due to different addressing
- - see chapter 3). After binding (CAN_RAW) or connecting (CAN_BCM)
- the socket, you can read(2) and write(2) from/to the socket or use
- send(2), sendto(2), sendmsg(2) and the recv* counterpart operations
- on the socket as usual. There are also CAN specific socket options
- described below.
-
- The basic CAN frame structure and the sockaddr structure are defined
- in include/linux/can.h:
-
- struct can_frame {
- canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
- __u8 can_dlc; /* data length code: 0 .. 8 */
- __u8 data[8] __attribute__((aligned(8)));
- };
-
- The alignment of the (linear) payload data[] to a 64bit boundary
- allows the user to define own structs and unions to easily access the
- CAN payload. There is no given byteorder on the CAN bus by
- default. A read(2) system call on a CAN_RAW socket transfers a
- struct can_frame to the user space.
-
- The sockaddr_can structure has an interface index like the
- PF_PACKET socket, that also binds to a specific interface:
-
- struct sockaddr_can {
- sa_family_t can_family;
- int can_ifindex;
- union {
- /* transport protocol class address info (e.g. ISOTP) */
- struct { canid_t rx_id, tx_id; } tp;
-
- /* reserved for future CAN protocols address information */
- } can_addr;
- };
-
- To determine the interface index an appropriate ioctl() has to
- be used (example for CAN_RAW sockets without error checking):
-
- int s;
- struct sockaddr_can addr;
- struct ifreq ifr;
-
- s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
-
- strcpy(ifr.ifr_name, "can0" );
- ioctl(s, SIOCGIFINDEX, &ifr);
-
- addr.can_family = AF_CAN;
- addr.can_ifindex = ifr.ifr_ifindex;
-
- bind(s, (struct sockaddr *)&addr, sizeof(addr));
-
- (..)
-
- To bind a socket to all(!) CAN interfaces the interface index must
- be 0 (zero). In this case the socket receives CAN frames from every
- enabled CAN interface. To determine the originating CAN interface
- the system call recvfrom(2) may be used instead of read(2). To send
- on a socket that is bound to 'any' interface sendto(2) is needed to
- specify the outgoing interface.
-
- Reading CAN frames from a bound CAN_RAW socket (see above) consists
- of reading a struct can_frame:
-
- struct can_frame frame;
-
- nbytes = read(s, &frame, sizeof(struct can_frame));
-
- if (nbytes < 0) {
- perror("can raw socket read");
- return 1;
- }
-
- /* paranoid check ... */
- if (nbytes < sizeof(struct can_frame)) {
- fprintf(stderr, "read: incomplete CAN frame\n");
- return 1;
- }
-
- /* do something with the received CAN frame */
-
- Writing CAN frames can be done similarly, with the write(2) system call:
-
- nbytes = write(s, &frame, sizeof(struct can_frame));
-
- When the CAN interface is bound to 'any' existing CAN interface
- (addr.can_ifindex = 0) it is recommended to use recvfrom(2) if the
- information about the originating CAN interface is needed:
-
- struct sockaddr_can addr;
- struct ifreq ifr;
- socklen_t len = sizeof(addr);
- struct can_frame frame;
-
- nbytes = recvfrom(s, &frame, sizeof(struct can_frame),
- 0, (struct sockaddr*)&addr, &len);
-
- /* get interface name of the received CAN frame */
- ifr.ifr_ifindex = addr.can_ifindex;
- ioctl(s, SIOCGIFNAME, &ifr);
- printf("Received a CAN frame from interface %s", ifr.ifr_name);
-
- To write CAN frames on sockets bound to 'any' CAN interface the
- outgoing interface has to be defined certainly.
-
- strcpy(ifr.ifr_name, "can0");
- ioctl(s, SIOCGIFINDEX, &ifr);
- addr.can_ifindex = ifr.ifr_ifindex;
- addr.can_family = AF_CAN;
-
- nbytes = sendto(s, &frame, sizeof(struct can_frame),
- 0, (struct sockaddr*)&addr, sizeof(addr));
-
- 4.1 RAW protocol sockets with can_filters (SOCK_RAW)
-
- Using CAN_RAW sockets is extensively comparable to the commonly
- known access to CAN character devices. To meet the new possibilities
- provided by the multi user SocketCAN approach, some reasonable
- defaults are set at RAW socket binding time:
-
- - The filters are set to exactly one filter receiving everything
- - The socket only receives valid data frames (=> no error frames)
- - The loopback of sent CAN frames is enabled (see chapter 3.2)
- - The socket does not receive its own sent frames (in loopback mode)
-
- These default settings may be changed before or after binding the socket.
- To use the referenced definitions of the socket options for CAN_RAW
- sockets, include <linux/can/raw.h>.
-
- 4.1.1 RAW socket option CAN_RAW_FILTER
-
- The reception of CAN frames using CAN_RAW sockets can be controlled
- by defining 0 .. n filters with the CAN_RAW_FILTER socket option.
-
- The CAN filter structure is defined in include/linux/can.h:
-
- struct can_filter {
- canid_t can_id;
- canid_t can_mask;
- };
-
- A filter matches, when
-
- <received_can_id> & mask == can_id & mask
-
- which is analogous to known CAN controllers hardware filter semantics.
- The filter can be inverted in this semantic, when the CAN_INV_FILTER
- bit is set in can_id element of the can_filter structure. In
- contrast to CAN controller hardware filters the user may set 0 .. n
- receive filters for each open socket separately:
-
- struct can_filter rfilter[2];
-
- rfilter[0].can_id = 0x123;
- rfilter[0].can_mask = CAN_SFF_MASK;
- rfilter[1].can_id = 0x200;
- rfilter[1].can_mask = 0x700;
-
- setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter));
-
- To disable the reception of CAN frames on the selected CAN_RAW socket:
-
- setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0);
-
- To set the filters to zero filters is quite obsolete as not read
- data causes the raw socket to discard the received CAN frames. But
- having this 'send only' use-case we may remove the receive list in the
- Kernel to save a little (really a very little!) CPU usage.
-
- 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
-
- As described in chapter 3.4 the CAN interface driver can generate so
- called Error Frames that can optionally be passed to the user
- application in the same way as other CAN frames. The possible
- errors are divided into different error classes that may be filtered
- using the appropriate error mask. To register for every possible
- error condition CAN_ERR_MASK can be used as value for the error mask.
- The values for the error mask are defined in linux/can/error.h .
-
- can_err_mask_t err_mask = ( CAN_ERR_TX_TIMEOUT | CAN_ERR_BUSOFF );
-
- setsockopt(s, SOL_CAN_RAW, CAN_RAW_ERR_FILTER,
- &err_mask, sizeof(err_mask));
-
- 4.1.3 RAW socket option CAN_RAW_LOOPBACK
-
- To meet multi user needs the local loopback is enabled by default
- (see chapter 3.2 for details). But in some embedded use-cases
- (e.g. when only one application uses the CAN bus) this loopback
- functionality can be disabled (separately for each socket):
-
- int loopback = 0; /* 0 = disabled, 1 = enabled (default) */
-
- setsockopt(s, SOL_CAN_RAW, CAN_RAW_LOOPBACK, &loopback, sizeof(loopback));
-
- 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
-
- When the local loopback is enabled, all the sent CAN frames are
- looped back to the open CAN sockets that registered for the CAN
- frames' CAN-ID on this given interface to meet the multi user
- needs. The reception of the CAN frames on the same socket that was
- sending the CAN frame is assumed to be unwanted and therefore
- disabled by default. This default behaviour may be changed on
- demand:
-
- int recv_own_msgs = 1; /* 0 = disabled (default), 1 = enabled */
-
- setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
- &recv_own_msgs, sizeof(recv_own_msgs));
-
- 4.1.5 RAW socket returned message flags
-
- When using recvmsg() call, the msg->msg_flags may contain following flags:
-
- MSG_DONTROUTE: set when the received frame was created on the local host.
-
- MSG_CONFIRM: set when the frame was sent via the socket it is received on.
- This flag can be interpreted as a 'transmission confirmation' when the
- CAN driver supports the echo of frames on driver level, see 3.2 and 6.2.
- In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set.
-
- 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
- 4.3 connected transport protocols (SOCK_SEQPACKET)
- 4.4 unconnected transport protocols (SOCK_DGRAM)
-
-
-5. Socket CAN core module
--------------------------
-
- The Socket CAN core module implements the protocol family
- PF_CAN. CAN protocol modules are loaded by the core module at
- runtime. The core module provides an interface for CAN protocol
- modules to subscribe needed CAN IDs (see chapter 3.1).
-
- 5.1 can.ko module params
-
- - stats_timer: To calculate the Socket CAN core statistics
- (e.g. current/maximum frames per second) this 1 second timer is
- invoked at can.ko module start time by default. This timer can be
- disabled by using stattimer=0 on the module commandline.
-
- - debug: (removed since SocketCAN SVN r546)
-
- 5.2 procfs content
-
- As described in chapter 3.1 the Socket CAN core uses several filter
- lists to deliver received CAN frames to CAN protocol modules. These
- receive lists, their filters and the count of filter matches can be
- checked in the appropriate receive list. All entries contain the
- device and a protocol module identifier:
-
- foo@bar:~$ cat /proc/net/can/rcvlist_all
-
- receive list 'rx_all':
- (vcan3: no entry)
- (vcan2: no entry)
- (vcan1: no entry)
- device can_id can_mask function userdata matches ident
- vcan0 000 00000000 f88e6370 f6c6f400 0 raw
- (any: no entry)
-
- In this example an application requests any CAN traffic from vcan0.
-
- rcvlist_all - list for unfiltered entries (no filter operations)
- rcvlist_eff - list for single extended frame (EFF) entries
- rcvlist_err - list for error frames masks
- rcvlist_fil - list for mask/value filters
- rcvlist_inv - list for mask/value filters (inverse semantic)
- rcvlist_sff - list for single standard frame (SFF) entries
-
- Additional procfs files in /proc/net/can
-
- stats - Socket CAN core statistics (rx/tx frames, match ratios, ...)
- reset_stats - manual statistic reset
- version - prints the Socket CAN core version and the ABI version
-
- 5.3 writing own CAN protocol modules
-
- To implement a new protocol in the protocol family PF_CAN a new
- protocol has to be defined in include/linux/can.h .
- The prototypes and definitions to use the Socket CAN core can be
- accessed by including include/linux/can/core.h .
- In addition to functions that register the CAN protocol and the
- CAN device notifier chain there are functions to subscribe CAN
- frames received by CAN interfaces and to send CAN frames:
-
- can_rx_register - subscribe CAN frames from a specific interface
- can_rx_unregister - unsubscribe CAN frames from a specific interface
- can_send - transmit a CAN frame (optional with local loopback)
-
- For details see the kerneldoc documentation in net/can/af_can.c or
- the source code of net/can/raw.c or net/can/bcm.c .
-
-6. CAN network drivers
-----------------------
-
- Writing a CAN network device driver is much easier than writing a
- CAN character device driver. Similar to other known network device
- drivers you mainly have to deal with:
-
- - TX: Put the CAN frame from the socket buffer to the CAN controller.
- - RX: Put the CAN frame from the CAN controller to the socket buffer.
-
- See e.g. at Documentation/networking/netdevices.txt . The differences
- for writing CAN network device driver are described below:
-
- 6.1 general settings
-
- dev->type = ARPHRD_CAN; /* the netdevice hardware type */
- dev->flags = IFF_NOARP; /* CAN has no arp */
-
- dev->mtu = sizeof(struct can_frame);
-
- The struct can_frame is the payload of each socket buffer in the
- protocol family PF_CAN.
-
- 6.2 local loopback of sent frames
-
- As described in chapter 3.2 the CAN network device driver should
- support a local loopback functionality similar to the local echo
- e.g. of tty devices. In this case the driver flag IFF_ECHO has to be
- set to prevent the PF_CAN core from locally echoing sent frames
- (aka loopback) as fallback solution:
-
- dev->flags = (IFF_NOARP | IFF_ECHO);
-
- 6.3 CAN controller hardware filters
-
- To reduce the interrupt load on deep embedded systems some CAN
- controllers support the filtering of CAN IDs or ranges of CAN IDs.
- These hardware filter capabilities vary from controller to
- controller and have to be identified as not feasible in a multi-user
- networking approach. The use of the very controller specific
- hardware filters could make sense in a very dedicated use-case, as a
- filter on driver level would affect all users in the multi-user
- system. The high efficient filter sets inside the PF_CAN core allow
- to set different multiple filters for each socket separately.
- Therefore the use of hardware filters goes to the category 'handmade
- tuning on deep embedded systems'. The author is running a MPC603e
- @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
- load without any problems ...
-
- 6.4 The virtual CAN driver (vcan)
-
- Similar to the network loopback devices, vcan offers a virtual local
- CAN interface. A full qualified address on CAN consists of
-
- - a unique CAN Identifier (CAN ID)
- - the CAN bus this CAN ID is transmitted on (e.g. can0)
-
- so in common use cases more than one virtual CAN interface is needed.
-
- The virtual CAN interfaces allow the transmission and reception of CAN
- frames without real CAN controller hardware. Virtual CAN network
- devices are usually named 'vcanX', like vcan0 vcan1 vcan2 ...
- When compiled as a module the virtual CAN driver module is called vcan.ko
-
- Since Linux Kernel version 2.6.24 the vcan driver supports the Kernel
- netlink interface to create vcan network devices. The creation and
- removal of vcan network devices can be managed with the ip(8) tool:
-
- - Create a virtual CAN network interface:
- $ ip link add type vcan
-
- - Create a virtual CAN network interface with a specific name 'vcan42':
- $ ip link add dev vcan42 type vcan
-
- - Remove a (virtual CAN) network interface 'vcan42':
- $ ip link del vcan42
-
- 6.5 The CAN network device driver interface
-
- The CAN network device driver interface provides a generic interface
- to setup, configure and monitor CAN network devices. The user can then
- configure the CAN device, like setting the bit-timing parameters, via
- the netlink interface using the program "ip" from the "IPROUTE2"
- utility suite. The following chapter describes briefly how to use it.
- Furthermore, the interface uses a common data structure and exports a
- set of common functions, which all real CAN network device drivers
- should use. Please have a look to the SJA1000 or MSCAN driver to
- understand how to use them. The name of the module is can-dev.ko.
-
- 6.5.1 Netlink interface to set/get devices properties
-
- The CAN device must be configured via netlink interface. The supported
- netlink message types are defined and briefly described in
- "include/linux/can/netlink.h". CAN link support for the program "ip"
- of the IPROUTE2 utility suite is available and it can be used as shown
- below:
-
- - Setting CAN device properties:
-
- $ ip link set can0 type can help
- Usage: ip link set DEVICE type can
- [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
- [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
- phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
-
- [ loopback { on | off } ]
- [ listen-only { on | off } ]
- [ triple-sampling { on | off } ]
-
- [ restart-ms TIME-MS ]
- [ restart ]
-
- Where: BITRATE := { 1..1000000 }
- SAMPLE-POINT := { 0.000..0.999 }
- TQ := { NUMBER }
- PROP-SEG := { 1..8 }
- PHASE-SEG1 := { 1..8 }
- PHASE-SEG2 := { 1..8 }
- SJW := { 1..4 }
- RESTART-MS := { 0 | NUMBER }
-
- - Display CAN device details and statistics:
-
- $ ip -details -statistics link show can0
- 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP qlen 10
- link/can
- can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 100
- bitrate 125000 sample_point 0.875
- tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
- sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
- clock 8000000
- re-started bus-errors arbit-lost error-warn error-pass bus-off
- 41 17457 0 41 42 41
- RX: bytes packets errors dropped overrun mcast
- 140859 17608 17457 0 0 0
- TX: bytes packets errors dropped carrier collsns
- 861 112 0 41 0 0
-
- More info to the above output:
-
- "<TRIPLE-SAMPLING>"
- Shows the list of selected CAN controller modes: LOOPBACK,
- LISTEN-ONLY, or TRIPLE-SAMPLING.
-
- "state ERROR-ACTIVE"
- The current state of the CAN controller: "ERROR-ACTIVE",
- "ERROR-WARNING", "ERROR-PASSIVE", "BUS-OFF" or "STOPPED"
-
- "restart-ms 100"
- Automatic restart delay time. If set to a non-zero value, a
- restart of the CAN controller will be triggered automatically
- in case of a bus-off condition after the specified delay time
- in milliseconds. By default it's off.
-
- "bitrate 125000 sample_point 0.875"
- Shows the real bit-rate in bits/sec and the sample-point in the
- range 0.000..0.999. If the calculation of bit-timing parameters
- is enabled in the kernel (CONFIG_CAN_CALC_BITTIMING=y), the
- bit-timing can be defined by setting the "bitrate" argument.
- Optionally the "sample-point" can be specified. By default it's
- 0.000 assuming CIA-recommended sample-points.
-
- "tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1"
- Shows the time quanta in ns, propagation segment, phase buffer
- segment 1 and 2 and the synchronisation jump width in units of
- tq. They allow to define the CAN bit-timing in a hardware
- independent format as proposed by the Bosch CAN 2.0 spec (see
- chapter 8 of http://www.semiconductors.bosch.de/pdf/can2spec.pdf).
-
- "sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
- clock 8000000"
- Shows the bit-timing constants of the CAN controller, here the
- "sja1000". The minimum and maximum values of the time segment 1
- and 2, the synchronisation jump width in units of tq, the
- bitrate pre-scaler and the CAN system clock frequency in Hz.
- These constants could be used for user-defined (non-standard)
- bit-timing calculation algorithms in user-space.
-
- "re-started bus-errors arbit-lost error-warn error-pass bus-off"
- Shows the number of restarts, bus and arbitration lost errors,
- and the state changes to the error-warning, error-passive and
- bus-off state. RX overrun errors are listed in the "overrun"
- field of the standard network statistics.
-
- 6.5.2 Setting the CAN bit-timing
-
- The CAN bit-timing parameters can always be defined in a hardware
- independent format as proposed in the Bosch CAN 2.0 specification
- specifying the arguments "tq", "prop_seg", "phase_seg1", "phase_seg2"
- and "sjw":
-
- $ ip link set canX type can tq 125 prop-seg 6 \
- phase-seg1 7 phase-seg2 2 sjw 1
-
- If the kernel option CONFIG_CAN_CALC_BITTIMING is enabled, CIA
- recommended CAN bit-timing parameters will be calculated if the bit-
- rate is specified with the argument "bitrate":
-
- $ ip link set canX type can bitrate 125000
-
- Note that this works fine for the most common CAN controllers with
- standard bit-rates but may *fail* for exotic bit-rates or CAN system
- clock frequencies. Disabling CONFIG_CAN_CALC_BITTIMING saves some
- space and allows user-space tools to solely determine and set the
- bit-timing parameters. The CAN controller specific bit-timing
- constants can be used for that purpose. They are listed by the
- following command:
-
- $ ip -details link show can0
- ...
- sja1000: clock 8000000 tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
-
- 6.5.3 Starting and stopping the CAN network device
-
- A CAN network device is started or stopped as usual with the command
- "ifconfig canX up/down" or "ip link set canX up/down". Be aware that
- you *must* define proper bit-timing parameters for real CAN devices
- before you can start it to avoid error-prone default settings:
-
- $ ip link set canX up type can bitrate 125000
-
- A device may enter the "bus-off" state if too much errors occurred on
- the CAN bus. Then no more messages are received or sent. An automatic
- bus-off recovery can be enabled by setting the "restart-ms" to a
- non-zero value, e.g.:
-
- $ ip link set canX type can restart-ms 100
-
- Alternatively, the application may realize the "bus-off" condition
- by monitoring CAN error frames and do a restart when appropriate with
- the command:
-
- $ ip link set canX type can restart
-
- Note that a restart will also create a CAN error frame (see also
- chapter 3.4).
-
- 6.6 Supported CAN hardware
-
- Please check the "Kconfig" file in "drivers/net/can" to get an actual
- list of the support CAN hardware. On the Socket CAN project website
- (see chapter 7) there might be further drivers available, also for
- older kernel versions.
-
-7. Socket CAN resources
------------------------
-
- You can find further resources for Socket CAN like user space tools,
- support for old kernel versions, more drivers, mailing lists, etc.
- at the BerliOS OSS project website for Socket CAN:
-
- http://developer.berlios.de/projects/socketcan
-
- If you have questions, bug fixes, etc., don't hesitate to post them to
- the Socketcan-Users mailing list. But please search the archives first.
-
-8. Credits
-----------
-
- Oliver Hartkopp (PF_CAN core, filters, drivers, bcm, SJA1000 driver)
- Urs Thuermann (PF_CAN core, kernel integration, socket interfaces, raw, vcan)
- Jan Kizka (RT-SocketCAN core, Socket-API reconciliation)
- Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews,
- CAN device driver interface, MSCAN driver)
- Robert Schwebel (design reviews, PTXdist integration)
- Marc Kleine-Budde (design reviews, Kernel 2.6 cleanups, drivers)
- Benedikt Spranger (reviews)
- Thomas Gleixner (LKML reviews, coding style, posting hints)
- Andrey Volkov (kernel subtree structure, ioctls, MSCAN driver)
- Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
- Klaus Hitschler (PEAK driver integration)
- Uwe Koppe (CAN netdevices with PF_PACKET approach)
- Michael Schulze (driver layer loopback requirement, RT CAN drivers review)
- Pavel Pisa (Bit-timing calculation)
- Sascha Hauer (SJA1000 platform driver)
- Sebastian Haas (SJA1000 EMS PCI driver)
- Markus Plessing (SJA1000 EMS PCI driver)
- Per Dalen (SJA1000 Kvaser PCI driver)
- Sam Ravnborg (reviews, coding style, kbuild help)
diff --git a/Documentation/networking/cops.txt b/Documentation/networking/cops.txt
deleted file mode 100644
index 3e344b448e0..00000000000
--- a/Documentation/networking/cops.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-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
deleted file mode 100644
index c725d33b316..00000000000
--- a/Documentation/networking/cs89x0.txt
+++ /dev/null
@@ -1,703 +0,0 @@
-
-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.
-
-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 media=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
- to partially 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 cannot 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 Adapter
-A000-C7FF VGA Graphics Adapter
-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
-latest drivers and technical publications.
-
-
-6.4 Current maintainer
-
-In February 2000 the maintenance of this driver was assumed by Andrew
-Morton.
-
-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/cxacru-cf.py b/Documentation/networking/cxacru-cf.py
deleted file mode 100644
index b41d298398c..00000000000
--- a/Documentation/networking/cxacru-cf.py
+++ /dev/null
@@ -1,48 +0,0 @@
-#!/usr/bin/env python
-# Copyright 2009 Simon Arlott
-#
-# 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.
-#
-# Usage: cxacru-cf.py < cxacru-cf.bin
-# Output: values string suitable for the sysfs adsl_config attribute
-#
-# Warning: cxacru-cf.bin with MD5 hash cdbac2689969d5ed5d4850f117702110
-# contains mis-aligned values which will stop the modem from being able
-# to make a connection. If the first and last two bytes are removed then
-# the values become valid, but the modulation will be forced to ANSI
-# T1.413 only which may not be appropriate.
-#
-# The original binary format is a packed list of le32 values.
-
-import sys
-import struct
-
-i = 0
-while True:
- buf = sys.stdin.read(4)
-
- if len(buf) == 0:
- break
- elif len(buf) != 4:
- sys.stdout.write("\n")
- sys.stderr.write("Error: read {0} not 4 bytes\n".format(len(buf)))
- sys.exit(1)
-
- if i > 0:
- sys.stdout.write(" ")
- sys.stdout.write("{0:x}={1}".format(i, struct.unpack("<I", buf)[0]))
- i += 1
-
-sys.stdout.write("\n")
diff --git a/Documentation/networking/cxacru.txt b/Documentation/networking/cxacru.txt
deleted file mode 100644
index 2cce04457b4..00000000000
--- a/Documentation/networking/cxacru.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Firmware is required for this device: http://accessrunner.sourceforge.net/
-
-While it is capable of managing/maintaining the ADSL connection without the
-module loaded, the device will sometimes stop responding after unloading the
-driver and it is necessary to unplug/remove power to the device to fix this.
-
-Note: support for cxacru-cf.bin has been removed. It was not loaded correctly
-so it had no effect on the device configuration. Fixing it could have stopped
-existing devices working when an invalid configuration is supplied.
-
-There is a script cxacru-cf.py to convert an existing file to the sysfs form.
-
-Detected devices will appear as ATM devices named "cxacru". In /sys/class/atm/
-these are directories named cxacruN where N is the device number. A symlink
-named device points to the USB interface device's directory which contains
-several sysfs attribute files for retrieving device statistics:
-
-* adsl_controller_version
-
-* adsl_headend
-* adsl_headend_environment
- Information about the remote headend.
-
-* adsl_config
- Configuration writing interface.
- Write parameters in hexadecimal format <index>=<value>,
- separated by whitespace, e.g.:
- "1=0 a=5"
- Up to 7 parameters at a time will be sent and the modem will restart
- the ADSL connection when any value is set. These are logged for future
- reference.
-
-* downstream_attenuation (dB)
-* downstream_bits_per_frame
-* downstream_rate (kbps)
-* downstream_snr_margin (dB)
- Downstream stats.
-
-* upstream_attenuation (dB)
-* upstream_bits_per_frame
-* upstream_rate (kbps)
-* upstream_snr_margin (dB)
-* transmitter_power (dBm/Hz)
- Upstream stats.
-
-* downstream_crc_errors
-* downstream_fec_errors
-* downstream_hec_errors
-* upstream_crc_errors
-* upstream_fec_errors
-* upstream_hec_errors
- Error counts.
-
-* line_startable
- Indicates that ADSL support on the device
- is/can be enabled, see adsl_start.
-
-* line_status
- "initialising"
- "down"
- "attempting to activate"
- "training"
- "channel analysis"
- "exchange"
- "waiting"
- "up"
-
- Changes between "down" and "attempting to activate"
- if there is no signal.
-
-* link_status
- "not connected"
- "connected"
- "lost"
-
-* mac_address
-
-* modulation
- "" (when not connected)
- "ANSI T1.413"
- "ITU-T G.992.1 (G.DMT)"
- "ITU-T G.992.2 (G.LITE)"
-
-* startup_attempts
- Count of total attempts to initialise ADSL.
-
-To enable/disable ADSL, the following can be written to the adsl_state file:
- "start"
- "stop
- "restart" (stops, waits 1.5s, then starts)
- "poll" (used to resume status polling if it was disabled due to failure)
-
-Changes in adsl/line state are reported via kernel log messages:
- [4942145.150704] ATM dev 0: ADSL state: running
- [4942243.663766] ATM dev 0: ADSL line: down
- [4942249.665075] ATM dev 0: ADSL line: attempting to activate
- [4942253.654954] ATM dev 0: ADSL line: training
- [4942255.666387] ATM dev 0: ADSL line: channel analysis
- [4942259.656262] ATM dev 0: ADSL line: exchange
- [2635357.696901] ATM dev 0: ADSL line: up (8128 kb/s down | 832 kb/s up)
diff --git a/Documentation/networking/cxgb.txt b/Documentation/networking/cxgb.txt
deleted file mode 100644
index 20a887615c4..00000000000
--- a/Documentation/networking/cxgb.txt
+++ /dev/null
@@ -1,352 +0,0 @@
- Chelsio N210 10Gb Ethernet Network Controller
-
- Driver Release Notes for Linux
-
- Version 2.1.1
-
- June 20, 2005
-
-CONTENTS
-========
- INTRODUCTION
- FEATURES
- PERFORMANCE
- DRIVER MESSAGES
- KNOWN ISSUES
- SUPPORT
-
-
-INTRODUCTION
-============
-
- This document describes the Linux driver for Chelsio 10Gb Ethernet Network
- Controller. This driver supports the Chelsio N210 NIC and is backward
- compatible with the Chelsio N110 model 10Gb NICs.
-
-
-FEATURES
-========
-
- Adaptive Interrupts (adaptive-rx)
- ---------------------------------
-
- This feature provides an adaptive algorithm that adjusts the interrupt
- coalescing parameters, allowing the driver to dynamically adapt the latency
- settings to achieve the highest performance during various types of network
- load.
-
- The interface used to control this feature is ethtool. Please see the
- ethtool manpage for additional usage information.
-
- By default, adaptive-rx is disabled.
- To enable adaptive-rx:
-
- ethtool -C <interface> adaptive-rx on
-
- To disable adaptive-rx, use ethtool:
-
- ethtool -C <interface> adaptive-rx off
-
- After disabling adaptive-rx, the timer latency value will be set to 50us.
- You may set the timer latency after disabling adaptive-rx:
-
- ethtool -C <interface> rx-usecs <microseconds>
-
- An example to set the timer latency value to 100us on eth0:
-
- ethtool -C eth0 rx-usecs 100
-
- You may also provide a timer latency value while disabling adaptive-rx:
-
- ethtool -C <interface> adaptive-rx off rx-usecs <microseconds>
-
- If adaptive-rx is disabled and a timer latency value is specified, the timer
- will be set to the specified value until changed by the user or until
- adaptive-rx is enabled.
-
- To view the status of the adaptive-rx and timer latency values:
-
- ethtool -c <interface>
-
-
- TCP Segmentation Offloading (TSO) Support
- -----------------------------------------
-
- This feature, also known as "large send", enables a system's protocol stack
- to offload portions of outbound TCP processing to a network interface card
- thereby reducing system CPU utilization and enhancing performance.
-
- The interface used to control this feature is ethtool version 1.8 or higher.
- Please see the ethtool manpage for additional usage information.
-
- By default, TSO is enabled.
- To disable TSO:
-
- ethtool -K <interface> tso off
-
- To enable TSO:
-
- ethtool -K <interface> tso on
-
- To view the status of TSO:
-
- ethtool -k <interface>
-
-
-PERFORMANCE
-===========
-
- The following information is provided as an example of how to change system
- parameters for "performance tuning" an what value to use. You may or may not
- want to change these system parameters, depending on your server/workstation
- application. Doing so is not warranted in any way by Chelsio Communications,
- and is done at "YOUR OWN RISK". Chelsio will not be held responsible for loss
- of data or damage to equipment.
-
- Your distribution may have a different way of doing things, or you may prefer
- a different method. These commands are shown only to provide an example of
- what to do and are by no means definitive.
-
- Making any of the following system changes will only last until you reboot
- your system. You may want to write a script that runs at boot-up which
- includes the optimal settings for your system.
-
- Setting PCI Latency Timer:
- setpci -d 1425:* 0x0c.l=0x0000F800
-
- Disabling TCP timestamp:
- sysctl -w net.ipv4.tcp_timestamps=0
-
- Disabling SACK:
- sysctl -w net.ipv4.tcp_sack=0
-
- Setting large number of incoming connection requests:
- sysctl -w net.ipv4.tcp_max_syn_backlog=3000
-
- Setting maximum receive socket buffer size:
- sysctl -w net.core.rmem_max=1024000
-
- Setting maximum send socket buffer size:
- sysctl -w net.core.wmem_max=1024000
-
- Set smp_affinity (on a multiprocessor system) to a single CPU:
- echo 1 > /proc/irq/<interrupt_number>/smp_affinity
-
- Setting default receive socket buffer size:
- sysctl -w net.core.rmem_default=524287
-
- Setting default send socket buffer size:
- sysctl -w net.core.wmem_default=524287
-
- Setting maximum option memory buffers:
- sysctl -w net.core.optmem_max=524287
-
- Setting maximum backlog (# of unprocessed packets before kernel drops):
- sysctl -w net.core.netdev_max_backlog=300000
-
- Setting TCP read buffers (min/default/max):
- sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000"
-
- Setting TCP write buffers (min/pressure/max):
- sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000"
-
- Setting TCP buffer space (min/pressure/max):
- sysctl -w net.ipv4.tcp_mem="10000000 10000000 10000000"
-
- TCP window size for single connections:
- The receive buffer (RX_WINDOW) size must be at least as large as the
- Bandwidth-Delay Product of the communication link between the sender and
- receiver. Due to the variations of RTT, you may want to increase the buffer
- size up to 2 times the Bandwidth-Delay Product. Reference page 289 of
- "TCP/IP Illustrated, Volume 1, The Protocols" by W. Richard Stevens.
- At 10Gb speeds, use the following formula:
- RX_WINDOW >= 1.25MBytes * RTT(in milliseconds)
- Example for RTT with 100us: RX_WINDOW = (1,250,000 * 0.1) = 125,000
- RX_WINDOW sizes of 256KB - 512KB should be sufficient.
- Setting the min, max, and default receive buffer (RX_WINDOW) size:
- sysctl -w net.ipv4.tcp_rmem="<min> <default> <max>"
-
- TCP window size for multiple connections:
- The receive buffer (RX_WINDOW) size may be calculated the same as single
- connections, but should be divided by the number of connections. The
- smaller window prevents congestion and facilitates better pacing,
- especially if/when MAC level flow control does not work well or when it is
- not supported on the machine. Experimentation may be necessary to attain
- the correct value. This method is provided as a starting point for the
- correct receive buffer size.
- Setting the min, max, and default receive buffer (RX_WINDOW) size is
- performed in the same manner as single connection.
-
-
-DRIVER MESSAGES
-===============
-
- The following messages are the most common messages logged by syslog. These
- may be found in /var/log/messages.
-
- Driver up:
- Chelsio Network Driver - version 2.1.1
-
- NIC detected:
- eth#: Chelsio N210 1x10GBaseX NIC (rev #), PCIX 133MHz/64-bit
-
- Link up:
- eth#: link is up at 10 Gbps, full duplex
-
- Link down:
- eth#: link is down
-
-
-KNOWN ISSUES
-============
-
- These issues have been identified during testing. The following information
- is provided as a workaround to the problem. In some cases, this problem is
- inherent to Linux or to a particular Linux Distribution and/or hardware
- platform.
-
- 1. Large number of TCP retransmits on a multiprocessor (SMP) system.
-
- On a system with multiple CPUs, the interrupt (IRQ) for the network
- controller may be bound to more than one CPU. This will cause TCP
- retransmits if the packet data were to be split across different CPUs
- and re-assembled in a different order than expected.
-
- To eliminate the TCP retransmits, set smp_affinity on the particular
- interrupt to a single CPU. You can locate the interrupt (IRQ) used on
- the N110/N210 by using ifconfig:
- ifconfig <dev_name> | grep Interrupt
- Set the smp_affinity to a single CPU:
- echo 1 > /proc/irq/<interrupt_number>/smp_affinity
-
- It is highly suggested that you do not run the irqbalance daemon on your
- system, as this will change any smp_affinity setting you have applied.
- The irqbalance daemon runs on a 10 second interval and binds interrupts
- to the least loaded CPU determined by the daemon. To disable this daemon:
- chkconfig --level 2345 irqbalance off
-
- By default, some Linux distributions enable the kernel feature,
- irqbalance, which performs the same function as the daemon. To disable
- this feature, add the following line to your bootloader:
- noirqbalance
-
- Example using the Grub bootloader:
- title Red Hat Enterprise Linux AS (2.4.21-27.ELsmp)
- root (hd0,0)
- kernel /vmlinuz-2.4.21-27.ELsmp ro root=/dev/hda3 noirqbalance
- initrd /initrd-2.4.21-27.ELsmp.img
-
- 2. After running insmod, the driver is loaded and the incorrect network
- interface is brought up without running ifup.
-
- When using 2.4.x kernels, including RHEL kernels, the Linux kernel
- invokes a script named "hotplug". This script is primarily used to
- automatically bring up USB devices when they are plugged in, however,
- the script also attempts to automatically bring up a network interface
- after loading the kernel module. The hotplug script does this by scanning
- the ifcfg-eth# config files in /etc/sysconfig/network-scripts, looking
- for HWADDR=<mac_address>.
-
- If the hotplug script does not find the HWADDRR within any of the
- ifcfg-eth# files, it will bring up the device with the next available
- interface name. If this interface is already configured for a different
- network card, your new interface will have incorrect IP address and
- network settings.
-
- To solve this issue, you can add the HWADDR=<mac_address> key to the
- interface config file of your network controller.
-
- To disable this "hotplug" feature, you may add the driver (module name)
- to the "blacklist" file located in /etc/hotplug. It has been noted that
- this does not work for network devices because the net.agent script
- does not use the blacklist file. Simply remove, or rename, the net.agent
- script located in /etc/hotplug to disable this feature.
-
- 3. Transport Protocol (TP) hangs when running heavy multi-connection traffic
- on an AMD Opteron system with HyperTransport PCI-X Tunnel chipset.
-
- If your AMD Opteron system uses the AMD-8131 HyperTransport PCI-X Tunnel
- chipset, you may experience the "133-Mhz Mode Split Completion Data
- Corruption" bug identified by AMD while using a 133Mhz PCI-X card on the
- bus PCI-X bus.
-
- AMD states, "Under highly specific conditions, the AMD-8131 PCI-X Tunnel
- can provide stale data via split completion cycles to a PCI-X card that
- is operating at 133 Mhz", causing data corruption.
-
- AMD's provides three workarounds for this problem, however, Chelsio
- recommends the first option for best performance with this bug:
-
- For 133Mhz secondary bus operation, limit the transaction length and
- the number of outstanding transactions, via BIOS configuration
- programming of the PCI-X card, to the following:
-
- Data Length (bytes): 1k
- Total allowed outstanding transactions: 2
-
- Please refer to AMD 8131-HT/PCI-X Errata 26310 Rev 3.08 August 2004,
- section 56, "133-MHz Mode Split Completion Data Corruption" for more
- details with this bug and workarounds suggested by AMD.
-
- It may be possible to work outside AMD's recommended PCI-X settings, try
- increasing the Data Length to 2k bytes for increased performance. If you
- have issues with these settings, please revert to the "safe" settings
- and duplicate the problem before submitting a bug or asking for support.
-
- NOTE: The default setting on most systems is 8 outstanding transactions
- and 2k bytes data length.
-
- 4. On multiprocessor systems, it has been noted that an application which
- is handling 10Gb networking can switch between CPUs causing degraded
- and/or unstable performance.
-
- If running on an SMP system and taking performance measurements, it
- is suggested you either run the latest netperf-2.4.0+ or use a binding
- tool such as Tim Hockin's procstate utilities (runon)
- <http://www.hockin.org/~thockin/procstate/>.
-
- Binding netserver and netperf (or other applications) to particular
- CPUs will have a significant difference in performance measurements.
- You may need to experiment which CPU to bind the application to in
- order to achieve the best performance for your system.
-
- If you are developing an application designed for 10Gb networking,
- please keep in mind you may want to look at kernel functions
- sched_setaffinity & sched_getaffinity to bind your application.
-
- If you are just running user-space applications such as ftp, telnet,
- etc., you may want to try the runon tool provided by Tim Hockin's
- procstate utility. You could also try binding the interface to a
- particular CPU: runon 0 ifup eth0
-
-
-SUPPORT
-=======
-
- If you have problems with the software or hardware, please contact our
- customer support team via email at support@chelsio.com or check our website
- at http://www.chelsio.com
-
-===============================================================================
-
- Chelsio Communications
- 370 San Aleso Ave.
- Suite 100
- Sunnyvale, CA 94085
- http://www.chelsio.com
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License, version 2, as
-published by the Free Software Foundation.
-
-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.
-
-THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
-WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
-
- Copyright (c) 2003-2005 Chelsio Communications. All rights reserved.
-
-===============================================================================
diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt
deleted file mode 100644
index d718bc2ff1c..00000000000
--- a/Documentation/networking/dccp.txt
+++ /dev/null
@@ -1,207 +0,0 @@
-DCCP protocol
-=============
-
-
-Contents
-========
-- Introduction
-- Missing features
-- Socket options
-- Sysctl variables
-- IOCTLs
-- Other tunables
-- Notes
-
-
-Introduction
-============
-Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
-oriented protocol designed to solve issues present in UDP and TCP, particularly
-for real-time and multimedia (streaming) traffic.
-It divides into a base protocol (RFC 4340) and plugable congestion control
-modules called CCIDs. Like plugable TCP congestion control, at least one CCID
-needs to be enabled in order for the protocol to function properly. In the Linux
-implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as
-the TCP-friendly CCID3 (RFC 4342), are optional.
-For a brief introduction to CCIDs and suggestions for choosing a CCID to match
-given applications, see section 10 of RFC 4340.
-
-It has a base protocol and pluggable congestion control IDs (CCIDs).
-
-DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol
-is at http://www.ietf.org/html.charters/dccp-charter.html
-
-
-Missing features
-================
-The Linux DCCP implementation does not currently support all the features that are
-specified in RFCs 4340...42.
-
-The known bugs are at:
- http://www.linuxfoundation.org/collaborate/workgroups/networking/todo#DCCP
-
-For more up-to-date versions of the DCCP implementation, please consider using
-the experimental DCCP test tree; instructions for checking this out are on:
-http://www.linuxfoundation.org/collaborate/workgroups/networking/dccp_testing#Experimental_DCCP_source_tree
-
-
-Socket options
-==============
-DCCP_SOCKOPT_QPOLICY_ID sets the dequeuing policy for outgoing packets. It takes
-a policy ID as argument and can only be set before the connection (i.e. changes
-during an established connection are not supported). Currently, two policies are
-defined: the "simple" policy (DCCPQ_POLICY_SIMPLE), which does nothing special,
-and a priority-based variant (DCCPQ_POLICY_PRIO). The latter allows to pass an
-u32 priority value as ancillary data to sendmsg(), where higher numbers indicate
-a higher packet priority (similar to SO_PRIORITY). This ancillary data needs to
-be formatted using a cmsg(3) message header filled in as follows:
- cmsg->cmsg_level = SOL_DCCP;
- cmsg->cmsg_type = DCCP_SCM_PRIORITY;
- cmsg->cmsg_len = CMSG_LEN(sizeof(uint32_t)); /* or CMSG_LEN(4) */
-
-DCCP_SOCKOPT_QPOLICY_TXQLEN sets the maximum length of the output queue. A zero
-value is always interpreted as unbounded queue length. If different from zero,
-the interpretation of this parameter depends on the current dequeuing policy
-(see above): the "simple" policy will enforce a fixed queue size by returning
-EAGAIN, whereas the "prio" policy enforces a fixed queue length by dropping the
-lowest-priority packet first. The default value for this parameter is
-initialised from /proc/sys/net/dccp/default/tx_qlen.
-
-DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
-service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
-the socket will fall back to 0 (which means that no meaningful service code
-is present). On active sockets this is set before connect(); specifying more
-than one code has no effect (all subsequent service codes are ignored). The
-case is different for passive sockets, where multiple service codes (up to 32)
-can be set before calling bind().
-
-DCCP_SOCKOPT_GET_CUR_MPS is read-only and retrieves the current maximum packet
-size (application payload size) in bytes, see RFC 4340, section 14.
-
-DCCP_SOCKOPT_AVAILABLE_CCIDS is also read-only and returns the list of CCIDs
-supported by the endpoint. The option value is an array of type uint8_t whose
-size is passed as option length. The minimum array size is 4 elements, the
-value returned in the optlen argument always reflects the true number of
-built-in CCIDs.
-
-DCCP_SOCKOPT_CCID is write-only and sets both the TX and RX CCIDs at the same
-time, combining the operation of the next two socket options. This option is
-preferrable over the latter two, since often applications will use the same
-type of CCID for both directions; and mixed use of CCIDs is not currently well
-understood. This socket option takes as argument at least one uint8_t value, or
-an array of uint8_t values, which must match available CCIDS (see above). CCIDs
-must be registered on the socket before calling connect() or listen().
-
-DCCP_SOCKOPT_TX_CCID is read/write. It returns the current CCID (if set) or sets
-the preference list for the TX CCID, using the same format as DCCP_SOCKOPT_CCID.
-Please note that the getsockopt argument type here is `int', not uint8_t.
-
-DCCP_SOCKOPT_RX_CCID is analogous to DCCP_SOCKOPT_TX_CCID, but for the RX CCID.
-
-DCCP_SOCKOPT_SERVER_TIMEWAIT enables the server (listening socket) to hold
-timewait state when closing the connection (RFC 4340, 8.3). The usual case is
-that the closing server sends a CloseReq, whereupon the client holds timewait
-state. When this boolean socket option is on, the server sends a Close instead
-and will enter TIMEWAIT. This option must be set after accept() returns.
-
-DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
-partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
-always cover the entire packet and that only fully covered application data is
-accepted by the receiver. Hence, when using this feature on the sender, it must
-be enabled at the receiver, too with suitable choice of CsCov.
-
-DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the
- range 0..15 are acceptable. The default setting is 0 (full coverage),
- values between 1..15 indicate partial coverage.
-DCCP_SOCKOPT_RECV_CSCOV is for the receiver and has a different meaning: it
- sets a threshold, where again values 0..15 are acceptable. The default
- of 0 means that all packets with a partial coverage will be discarded.
- Values in the range 1..15 indicate that packets with minimally such a
- coverage value are also acceptable. The higher the number, the more
- restrictive this setting (see [RFC 4340, sec. 9.2.1]). Partial coverage
- settings are inherited to the child socket after accept().
-
-The following two options apply to CCID 3 exclusively and are getsockopt()-only.
-In either case, a TFRC info struct (defined in <linux/tfrc.h>) is returned.
-DCCP_SOCKOPT_CCID_RX_INFO
- Returns a `struct tfrc_rx_info' in optval; the buffer for optval and
- optlen must be set to at least sizeof(struct tfrc_rx_info).
-DCCP_SOCKOPT_CCID_TX_INFO
- Returns a `struct tfrc_tx_info' in optval; the buffer for optval and
- optlen must be set to at least sizeof(struct tfrc_tx_info).
-
-On unidirectional connections it is useful to close the unused half-connection
-via shutdown (SHUT_WR or SHUT_RD): this will reduce per-packet processing costs.
-
-
-Sysctl variables
-================
-Several DCCP default parameters can be managed by the following sysctls
-(sysctl net.dccp.default or /proc/sys/net/dccp/default):
-
-request_retries
- The number of active connection initiation retries (the number of
- Requests minus one) before timing out. In addition, it also governs
- the behaviour of the other, passive side: this variable also sets
- the number of times DCCP repeats sending a Response when the initial
- handshake does not progress from RESPOND to OPEN (i.e. when no Ack
- is received after the initial Request). This value should be greater
- than 0, suggested is less than 10. Analogue of tcp_syn_retries.
-
-retries1
- How often a DCCP Response is retransmitted until the listening DCCP
- side considers its connecting peer dead. Analogue of tcp_retries1.
-
-retries2
- The number of times a general DCCP packet is retransmitted. This has
- importance for retransmitted acknowledgments and feature negotiation,
- data packets are never retransmitted. Analogue of tcp_retries2.
-
-tx_ccid = 2
- Default CCID for the sender-receiver half-connection. Depending on the
- choice of CCID, the Send Ack Vector feature is enabled automatically.
-
-rx_ccid = 2
- Default CCID for the receiver-sender half-connection; see tx_ccid.
-
-seq_window = 100
- The initial sequence window (sec. 7.5.2) of the sender. This influences
- the local ackno validity and the remote seqno validity windows (7.5.1).
- Values in the range Wmin = 32 (RFC 4340, 7.5.2) up to 2^32-1 can be set.
-
-tx_qlen = 5
- The size of the transmit buffer in packets. A value of 0 corresponds
- to an unbounded transmit buffer.
-
-sync_ratelimit = 125 ms
- The timeout between subsequent DCCP-Sync packets sent in response to
- sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit
- of this parameter is milliseconds; a value of 0 disables rate-limiting.
-
-
-IOCTLS
-======
-FIONREAD
- Works as in udp(7): returns in the `int' argument pointer the size of
- the next pending datagram in bytes, or 0 when no datagram is pending.
-
-
-Other tunables
-==============
-Per-route rto_min support
- CCID-2 supports the RTAX_RTO_MIN per-route setting for the minimum value
- of the RTO timer. This setting can be modified via the 'rto_min' option
- of iproute2; for example:
- > ip route change 10.0.0.0/24 rto_min 250j dev wlan0
- > ip route add 10.0.0.254/32 rto_min 800j dev wlan0
- > ip route show dev wlan0
- CCID-3 also supports the rto_min setting: it is used to define the lower
- bound for the expiry of the nofeedback timer. This can be useful on LANs
- with very low RTTs (e.g., loopback, Gbit ethernet).
-
-
-Notes
-=====
-DCCP does not travel through NAT successfully at present on many boxes. This is
-because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT
-support for DCCP has been added.
diff --git a/Documentation/networking/de4x5.txt b/Documentation/networking/de4x5.txt
deleted file mode 100644
index c8e4ca9b2c3..00000000000
--- a/Documentation/networking/de4x5.txt
+++ /dev/null
@@ -1,178 +0,0 @@
- 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
deleted file mode 100644
index e12a4900cf7..00000000000
--- a/Documentation/networking/decnet.txt
+++ /dev/null
@@ -1,232 +0,0 @@
- Linux DECnet Networking Layer Information
- ===========================================
-
-1) Other documentation....
-
- o Project Home Pages
- http://www.chygwyn.com/ - 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.addr=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 or
-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 ?
- - 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
deleted file mode 100644
index 24c6b26e565..00000000000
--- a/Documentation/networking/depca.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-
-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/dl2k.txt b/Documentation/networking/dl2k.txt
deleted file mode 100644
index cba74f7a3ab..00000000000
--- a/Documentation/networking/dl2k.txt
+++ /dev/null
@@ -1,282 +0,0 @@
-
- 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.d/dl2k.conf:
- alias eth0 dl2k
-6. Run depmod to updated module indexes.
-7. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
- located at /etc/sysconfig/network-scripts or create it manually.
- [see - Configuration Script Sample]
-8. 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 in the
- /etc/modprobe.d/ 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 additional 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 bottleneck 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/dm9000.txt b/Documentation/networking/dm9000.txt
deleted file mode 100644
index 5552e2e575c..00000000000
--- a/Documentation/networking/dm9000.txt
+++ /dev/null
@@ -1,167 +0,0 @@
-DM9000 Network driver
-=====================
-
-Copyright 2008 Simtec Electronics,
- Ben Dooks <ben@simtec.co.uk> <ben-linux@fluff.org>
-
-
-Introduction
-------------
-
-This file describes how to use the DM9000 platform-device based network driver
-that is contained in the files drivers/net/dm9000.c and drivers/net/dm9000.h.
-
-The driver supports three DM9000 variants, the DM9000E which is the first chip
-supported as well as the newer DM9000A and DM9000B devices. It is currently
-maintained and tested by Ben Dooks, who should be CC: to any patches for this
-driver.
-
-
-Defining the platform device
-----------------------------
-
-The minimum set of resources attached to the platform device are as follows:
-
- 1) The physical address of the address register
- 2) The physical address of the data register
- 3) The IRQ line the device's interrupt pin is connected to.
-
-These resources should be specified in that order, as the ordering of the
-two address regions is important (the driver expects these to be address
-and then data).
-
-An example from arch/arm/mach-s3c2410/mach-bast.c is:
-
-static struct resource bast_dm9k_resource[] = {
- [0] = {
- .start = S3C2410_CS5 + BAST_PA_DM9000,
- .end = S3C2410_CS5 + BAST_PA_DM9000 + 3,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = S3C2410_CS5 + BAST_PA_DM9000 + 0x40,
- .end = S3C2410_CS5 + BAST_PA_DM9000 + 0x40 + 0x3f,
- .flags = IORESOURCE_MEM,
- },
- [2] = {
- .start = IRQ_DM9000,
- .end = IRQ_DM9000,
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
- }
-};
-
-static struct platform_device bast_device_dm9k = {
- .name = "dm9000",
- .id = 0,
- .num_resources = ARRAY_SIZE(bast_dm9k_resource),
- .resource = bast_dm9k_resource,
-};
-
-Note the setting of the IRQ trigger flag in bast_dm9k_resource[2].flags,
-as this will generate a warning if it is not present. The trigger from
-the flags field will be passed to request_irq() when registering the IRQ
-handler to ensure that the IRQ is setup correctly.
-
-This shows a typical platform device, without the optional configuration
-platform data supplied. The next example uses the same resources, but adds
-the optional platform data to pass extra configuration data:
-
-static struct dm9000_plat_data bast_dm9k_platdata = {
- .flags = DM9000_PLATF_16BITONLY,
-};
-
-static struct platform_device bast_device_dm9k = {
- .name = "dm9000",
- .id = 0,
- .num_resources = ARRAY_SIZE(bast_dm9k_resource),
- .resource = bast_dm9k_resource,
- .dev = {
- .platform_data = &bast_dm9k_platdata,
- }
-};
-
-The platform data is defined in include/linux/dm9000.h and described below.
-
-
-Platform data
--------------
-
-Extra platform data for the DM9000 can describe the IO bus width to the
-device, whether or not an external PHY is attached to the device and
-the availability of an external configuration EEPROM.
-
-The flags for the platform data .flags field are as follows:
-
-DM9000_PLATF_8BITONLY
-
- The IO should be done with 8bit operations.
-
-DM9000_PLATF_16BITONLY
-
- The IO should be done with 16bit operations.
-
-DM9000_PLATF_32BITONLY
-
- The IO should be done with 32bit operations.
-
-DM9000_PLATF_EXT_PHY
-
- The chip is connected to an external PHY.
-
-DM9000_PLATF_NO_EEPROM
-
- This can be used to signify that the board does not have an
- EEPROM, or that the EEPROM should be hidden from the user.
-
-DM9000_PLATF_SIMPLE_PHY
-
- Switch to using the simpler PHY polling method which does not
- try and read the MII PHY state regularly. This is only available
- when using the internal PHY. See the section on link state polling
- for more information.
-
- The config symbol DM9000_FORCE_SIMPLE_PHY_POLL, Kconfig entry
- "Force simple NSR based PHY polling" allows this flag to be
- forced on at build time.
-
-
-PHY Link state polling
-----------------------
-
-The driver keeps track of the link state and informs the network core
-about link (carrier) availability. This is managed by several methods
-depending on the version of the chip and on which PHY is being used.
-
-For the internal PHY, the original (and currently default) method is
-to read the MII state, either when the status changes if we have the
-necessary interrupt support in the chip or every two seconds via a
-periodic timer.
-
-To reduce the overhead for the internal PHY, there is now the option
-of using the DM9000_FORCE_SIMPLE_PHY_POLL config, or DM9000_PLATF_SIMPLE_PHY
-platform data option to read the summary information without the
-expensive MII accesses. This method is faster, but does not print
-as much information.
-
-When using an external PHY, the driver currently has to poll the MII
-link status as there is no method for getting an interrupt on link change.
-
-
-DM9000A / DM9000B
------------------
-
-These chips are functionally similar to the DM9000E and are supported easily
-by the same driver. The features are:
-
- 1) Interrupt on internal PHY state change. This means that the periodic
- polling of the PHY status may be disabled on these devices when using
- the internal PHY.
-
- 2) TCP/UDP checksum offloading, which the driver does not currently support.
-
-
-ethtool
--------
-
-The driver supports the ethtool interface for access to the driver
-state information, the PHY state and the EEPROM.
diff --git a/Documentation/networking/dmfe.txt b/Documentation/networking/dmfe.txt
deleted file mode 100644
index 25320bf19c8..00000000000
--- a/Documentation/networking/dmfe.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Note: This driver doesn't have a maintainer.
-
-Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for 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.
-
-
-This driver provides kernel support for Davicom DM9102(A)/DM9132/DM9801 ethernet cards ( CNET
-10/100 ethernet cards uses Davicom chipset too, so this driver supports CNET cards too ).If you
-didn't compile this driver as a module, it will automatically load itself on boot and print a
-line similar to :
-
- dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
-
-If you compiled this driver as a module, you have to load it on boot.You can load it with command :
-
- insmod dmfe
-
-This way it will autodetect the device mode.This is the suggested way to load the module.Or you can pass
-a mode= setting to module while loading, like :
-
- 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
-
-Next you should configure your network interface with a command similar to :
-
- ifconfig eth0 172.22.3.18
- ^^^^^^^^^^^
- Your IP Address
-
-Then you may have to modify the default routing table with command :
-
- route add default eth0
-
-
-Now your ethernet card should be up and running.
-
-
-TODO:
-
-Implement pci_driver::suspend() and pci_driver::resume() power management methods.
-Check on 64 bit boxes.
-Check and fix on big endian boxes.
-Test and make sure PCI latency is now correct for all cases.
-
-
-Authors:
-
-Sten Wang <sten_wang@davicom.com.tw > : Original Author
-
-Contributors:
-
-Marcelo Tosatti <marcelo@conectiva.com.br>
-Alan Cox <alan@lxorguk.ukuu.org.uk>
-Jeff Garzik <jgarzik@pobox.com>
-Vojtech Pavlik <vojtech@suse.cz>
diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt
deleted file mode 100644
index d86adcdae42..00000000000
--- a/Documentation/networking/dns_resolver.txt
+++ /dev/null
@@ -1,157 +0,0 @@
- ===================
- DNS Resolver Module
- ===================
-
-Contents:
-
- - Overview.
- - Compilation.
- - Setting up.
- - Usage.
- - Mechanism.
- - Debugging.
-
-
-========
-OVERVIEW
-========
-
-The DNS resolver module provides a way for kernel services to make DNS queries
-by way of requesting a key of key type dns_resolver. These queries are
-upcalled to userspace through /sbin/request-key.
-
-These routines must be supported by userspace tools dns.upcall, cifs.upcall and
-request-key. It is under development and does not yet provide the full feature
-set. The features it does support include:
-
- (*) Implements the dns_resolver key_type to contact userspace.
-
-It does not yet support the following AFS features:
-
- (*) Dns query support for AFSDB resource record.
-
-This code is extracted from the CIFS filesystem.
-
-
-===========
-COMPILATION
-===========
-
-The module should be enabled by turning on the kernel configuration options:
-
- CONFIG_DNS_RESOLVER - tristate "DNS Resolver support"
-
-
-==========
-SETTING UP
-==========
-
-To set up this facility, the /etc/request-key.conf file must be altered so that
-/sbin/request-key can appropriately direct the upcalls. For example, to handle
-basic dname to IPv4/IPv6 address resolution, the following line should be
-added:
-
- #OP TYPE DESC CO-INFO PROGRAM ARG1 ARG2 ARG3 ...
- #====== ============ ======= ======= ==========================
- create dns_resolver * * /usr/sbin/cifs.upcall %k
-
-To direct a query for query type 'foo', a line of the following should be added
-before the more general line given above as the first match is the one taken.
-
- create dns_resolver foo:* * /usr/sbin/dns.foo %k
-
-
-=====
-USAGE
-=====
-
-To make use of this facility, one of the following functions that are
-implemented in the module can be called after doing:
-
- #include <linux/dns_resolver.h>
-
- (1) int dns_query(const char *type, const char *name, size_t namelen,
- const char *options, char **_result, time_t *_expiry);
-
- This is the basic access function. It looks for a cached DNS query and if
- it doesn't find it, it upcalls to userspace to make a new DNS query, which
- may then be cached. The key description is constructed as a string of the
- form:
-
- [<type>:]<name>
-
- where <type> optionally specifies the particular upcall program to invoke,
- and thus the type of query to do, and <name> specifies the string to be
- looked up. The default query type is a straight hostname to IP address
- set lookup.
-
- The name parameter is not required to be a NUL-terminated string, and its
- length should be given by the namelen argument.
-
- The options parameter may be NULL or it may be a set of options
- appropriate to the query type.
-
- The return value is a string appropriate to the query type. For instance,
- for the default query type it is just a list of comma-separated IPv4 and
- IPv6 addresses. The caller must free the result.
-
- The length of the result string is returned on success, and a negative
- error code is returned otherwise. -EKEYREJECTED will be returned if the
- DNS lookup failed.
-
- If _expiry is non-NULL, the expiry time (TTL) of the result will be
- returned also.
-
-The kernel maintains an internal keyring in which it caches looked up keys.
-This can be cleared by any process that has the CAP_SYS_ADMIN capability by
-the use of KEYCTL_KEYRING_CLEAR on the keyring ID.
-
-
-===============================
-READING DNS KEYS FROM USERSPACE
-===============================
-
-Keys of dns_resolver type can be read from userspace using keyctl_read() or
-"keyctl read/print/pipe".
-
-
-=========
-MECHANISM
-=========
-
-The dnsresolver module registers a key type called "dns_resolver". Keys of
-this type are used to transport and cache DNS lookup results from userspace.
-
-When dns_query() is invoked, it calls request_key() to search the local
-keyrings for a cached DNS result. If that fails to find one, it upcalls to
-userspace to get a new result.
-
-Upcalls to userspace are made through the request_key() upcall vector, and are
-directed by means of configuration lines in /etc/request-key.conf that tell
-/sbin/request-key what program to run to instantiate the key.
-
-The upcall handler program is responsible for querying the DNS, processing the
-result into a form suitable for passing to the keyctl_instantiate_key()
-routine. This then passes the data to dns_resolver_instantiate() which strips
-off and processes any options included in the data, and then attaches the
-remainder of the string to the key as its payload.
-
-The upcall handler program should set the expiry time on the key to that of the
-lowest TTL of all the records it has extracted a result from. This means that
-the key will be discarded and recreated when the data it holds has expired.
-
-dns_query() returns a copy of the value attached to the key, or an error if
-that is indicated instead.
-
-See <file:Documentation/security/keys-request-key.txt> for further
-information about request-key function.
-
-
-=========
-DEBUGGING
-=========
-
-Debugging messages can be turned on dynamically by writing a 1 into the
-following file:
-
- /sys/module/dnsresolver/parameters/debug
diff --git a/Documentation/networking/driver.txt b/Documentation/networking/driver.txt
deleted file mode 100644
index da59e288413..00000000000
--- a/Documentation/networking/driver.txt
+++ /dev/null
@@ -1,93 +0,0 @@
-Document about softnet driver issues
-
-Transmit path guidelines:
-
-1) The ndo_start_xmit method must not return NETDEV_TX_BUSY 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 netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
- struct net_device *dev)
- {
- struct drv *dp = netdev_priv(dev);
-
- 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 NETDEV_TX_BUSY;
- }
-
- ... queue packet to card ...
- ... update tx consumer index ...
-
- if (TX_BUFFS_AVAIL(dp) <= (MAX_SKB_FRAGS + 1))
- netif_stop_queue(dev);
-
- ...
- unlock_tx(dp);
- ...
- return NETDEV_TX_OK;
- }
-
- And then at the end of your TX reclamation 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) An ndo_start_xmit method must not modify the shared parts of a
- cloned SKB.
-
-3) Do not forget that once you return NETDEV_TX_OK from your
- ndo_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 NETDEV_TX_BUSY from the ndo_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 ndo_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 ndo_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
deleted file mode 100644
index fcb6c71cdb6..00000000000
--- a/Documentation/networking/e100.txt
+++ /dev/null
@@ -1,197 +0,0 @@
-Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
-==============================================================
-
-November 15, 2005
-
-Contents
-========
-
-- In This Release
-- Identifying Your Adapter
-- Building and Installation
-- Driver Configuration Parameters
-- Additional Configurations
-- Known Issues
-- Support
-
-
-In This Release
-===============
-
-This file describes the Linux* Base Driver for the Intel(R) PRO/100 Family of
-Adapters. This driver includes support for Itanium(R)2-based systems.
-
-For questions related to hardware requirements, refer to the documentation
-supplied with your Intel PRO/100 adapter.
-
-The following features are now available in supported kernels:
- - Native VLANs
- - Channel Bonding (teaming)
- - SNMP
-
-Channel Bonding documentation can be found in the Linux kernel source:
-/Documentation/networking/bonding.txt
-
-
-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.x.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.x.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. The ethtool utility 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/modprobe.d/*.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 a configuraton file in /etc/modprobe.d/
-
- 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. The ethtool
- version 1.6 or later is required for this functionality.
-
- The latest release of ethtool can be found from
- http://ftp.kernel.org/pub/software/network/ethtool/
-
- Enabling Wake on LAN* (WoL)
- ---------------------------
- WoL is provided through the ethtool* utility. 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.
-
- Multiple Interfaces on Same Ethernet Broadcast Network
- ------------------------------------------------------
-
- Due to the default ARP behavior on Linux, it is not possible to have
- one system on two IP networks in the same Ethernet broadcast domain
- (non-partitioned switch) behave as expected. All Ethernet interfaces
- will respond to IP traffic for any IP address assigned to the system.
- This results in unbalanced receive traffic.
-
- If you have multiple interfaces in a server, either turn on ARP
- filtering by
-
- (1) entering: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
- (this only works if your kernel's version is higher than 2.4.5), or
-
- (2) installing the interfaces in separate broadcast domains (either
- in different switches or in a switch partitioned to VLANs).
-
-
-Support
-=======
-
-For general information, go to the Intel support website at:
-
- http://support.intel.com
-
- or the Intel Wired Networking project hosted by Sourceforge at:
-
- http://sourceforge.net/projects/e1000
-
-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 e1000-devel@lists.sourceforge.net.
-
-
-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 file COPYING 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
deleted file mode 100644
index 71ca9585567..00000000000
--- a/Documentation/networking/e1000.txt
+++ /dev/null
@@ -1,461 +0,0 @@
-Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
-===============================================================
-
-Intel Gigabit Linux driver.
-Copyright(c) 1999 - 2010 Intel Corporation.
-
-Contents
-========
-
-- Identifying Your Adapter
-- Command Line Parameters
-- Speed and Duplex Configuration
-- Additional Configurations
-- Support
-
-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/go/network/adapter/idguide.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://support.intel.com/support/go/network/adapter/home.htm
-
-Command Line Parameters
-=======================
-
-The default value for each parameter is generally the recommended setting,
-unless otherwise noted.
-
-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
-
-AutoNeg
--------
-(Supported only on adapters with copper connections)
-Valid Range: 0x01-0x0F, 0x20-0x2F
-Default Value: 0x2F
-
-This parameter is a bit-mask that specifies the speed and duplex settings
-advertised by the adapter. 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
-------
-(Supported only on adapters with copper connections)
-Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
-Default Value: 0
-
-This 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 Value: Reads flow control settings from the EEPROM
-
-This parameter controls the automatic generation(Tx) and response(Rx)
-to Ethernet PAUSE frames.
-
-InterruptThrottleRate
----------------------
-(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
-Valid Range: 0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
- 4=simplified balancing)
-Default Value: 3
-
-The driver can limit the amount of interrupts per second that the adapter
-will generate for incoming packets. It does this by writing a value to the
-adapter that is based on the maximum amount of interrupts that the adapter
-will generate per second.
-
-Setting InterruptThrottleRate to a value greater or equal to 100
-will program the adapter to send out a maximum of that many interrupts
-per second, even if more packets have come in. This reduces interrupt
-load on the system and can lower CPU utilization under heavy load,
-but will increase latency as packets are not processed as quickly.
-
-The default behaviour of the driver previously assumed a static
-InterruptThrottleRate value of 8000, providing a good fallback value for
-all traffic types,but lacking in small packet performance and latency.
-The hardware can handle many more small packets per second however, and
-for this reason an adaptive interrupt moderation algorithm was implemented.
-
-Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which
-it dynamically adjusts the InterruptThrottleRate value based on the traffic
-that it receives. After determining the type of incoming traffic in the last
-timeframe, it will adjust the InterruptThrottleRate to an appropriate value
-for that traffic.
-
-The algorithm classifies the incoming traffic every interval into
-classes. Once the class is determined, the InterruptThrottleRate value is
-adjusted to suit that traffic type the best. There are three classes defined:
-"Bulk traffic", for large amounts of packets of normal size; "Low latency",
-for small amounts of traffic and/or a significant percentage of small
-packets; and "Lowest latency", for almost completely small packets or
-minimal traffic.
-
-In dynamic conservative mode, the InterruptThrottleRate value is set to 4000
-for traffic that falls in class "Bulk traffic". If traffic falls in the "Low
-latency" or "Lowest latency" class, the InterruptThrottleRate is increased
-stepwise to 20000. This default mode is suitable for most applications.
-
-For situations where low latency is vital such as cluster or
-grid computing, the algorithm can reduce latency even more when
-InterruptThrottleRate is set to mode 1. In this mode, which operates
-the same as mode 3, the InterruptThrottleRate will be increased stepwise to
-70000 for traffic in class "Lowest latency".
-
-In simplified mode the interrupt rate is based on the ratio of TX and
-RX traffic. If the bytes per second rate is approximately equal, the
-interrupt rate will drop as low as 2000 interrupts per second. If the
-traffic is mostly transmit or mostly receive, the interrupt rate could
-be as high as 8000.
-
-Setting InterruptThrottleRate to 0 turns off any interrupt moderation
-and may improve small packet latency, but is generally not suitable
-for bulk throughput traffic.
-
-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(R) 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:
-
- modprobe e1000 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 specifies the number of receive buffer descriptors allocated
-by the driver. Increasing this value allows the driver to buffer more
-incoming packets, at the expense of increased system memory utilization.
-
-Each descriptor is 16 bytes. A receive buffer is also allocated for each
-descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending
-on the MTU setting. The maximum MTU size is 16110.
-
-NOTE: MTU designates the frame size. It only needs to be set for Jumbo
- Frames. 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
--------------
-(This parameter is supported only on 82540, 82545 and later adapters.)
-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
------
-(This parameter is supported only on adapters with copper connections.)
-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.
-
-TxDescriptorStep
-----------------
-Valid Range: 1 (use every Tx Descriptor)
- 4 (use every 4th Tx Descriptor)
-
-Default Value: 1 (use every Tx Descriptor)
-
-On certain non-Intel architectures, it has been observed that intense TX
-traffic bursts of short packets may result in an improper descriptor
-writeback. If this occurs, the driver will report a "TX Timeout" and reset
-the adapter, after which the transmit flow will restart, though data may
-have stalled for as much as 10 seconds before it resumes.
-
-The improper writeback does not occur on the first descriptor in a system
-memory cache-line, which is typically 32 bytes, or 4 descriptors long.
-
-Setting TxDescriptorStep to a value of 4 will ensure that all TX descriptors
-are aligned to the start of a system memory cache line, and so this problem
-will not occur.
-
-NOTES: Setting TxDescriptorStep to 4 effectively reduces the number of
- TxDescriptors available for transmits to 1/4 of the normal allocation.
- This has a possible negative performance impact, which may be
- compensated for by allocating more descriptors using the TxDescriptors
- module parameter.
-
- There are other conditions which may result in "TX Timeout", which will
- not be resolved by the use of the TxDescriptorStep parameter. As the
- issue addressed by this parameter has never been observed on Intel
- Architecture platforms, it should not be used on Intel platforms.
-
-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
--------------
-(This parameter is supported only on 82540, 82545 and later adapters.)
-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
-------
-(This parameter is NOT supported 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.
-
-Copybreak
----------
-Valid Range: 0-xxxxxxx (0=off)
-Default Value: 256
-Usage: insmod e1000.ko copybreak=128
-
-Driver copies all packets below or equaling this size to a fresh RX
-buffer before handing it up the stack.
-
-This parameter is different than other parameters, in that it is a
-single (not 1,1,1 etc.) parameter applied to all driver instances and
-it is also available during runtime at
-/sys/module/e1000/parameters/copybreak
-
-SmartPowerDownEnable
---------------------
-Valid Range: 0-1
-Default Value: 0 (disabled)
-
-Allows PHY to turn off in lower power states. The user can turn off
-this parameter in supported chipsets.
-
-KumeranLockLoss
----------------
-Valid Range: 0-1
-Default Value: 1 (enabled)
-
-This workaround skips resetting the PHY at shutdown for the initial
-silicon releases of ICH8 systems.
-
-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. It should be used when you wish to control which
-speed and duplex combinations are advertised during the auto-negotiation
-process.
-
-The parameter may be specified as either a decimal or hexadecimal value as
-determined by the bitmap below.
-
-Bit position 7 6 5 4 3 2 1 0
-Decimal Value 128 64 32 16 8 4 2 1
-Hex value 80 40 20 10 8 4 2 1
-Speed (Mbps) N/A N/A 1000 N/A 100 100 10 10
-Duplex Full Full Half Full Half
-
-Some examples of using AutoNeg:
-
- modprobe e1000 AutoNeg=0x01 (Restricts autonegotiation to 10 Half)
- modprobe e1000 AutoNeg=1 (Same as above)
- modprobe e1000 AutoNeg=0x02 (Restricts autonegotiation to 10 Full)
- modprobe e1000 AutoNeg=0x03 (Restricts autonegotiation to 10 Half or 10 Full)
- modprobe e1000 AutoNeg=0x04 (Restricts autonegotiation to 100 Half)
- modprobe e1000 AutoNeg=0x05 (Restricts autonegotiation to 10 Half or 100
- Half)
- modprobe e1000 AutoNeg=0x020 (Restricts autonegotiation to 1000 Full)
- modprobe e1000 AutoNeg=32 (Same as above)
-
-Note that when this parameter is used, Speed and Duplex must not be specified.
-
-If the link partner is forced to a specific speed and duplex, then this
-parameter should not be used. Instead, use the Speed and Duplex parameters
-previously mentioned to force the adapter to the same speed and duplex.
-
-Additional Configurations
-=========================
-
- Jumbo Frames
- ------------
- 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 eth<x> mtu 9000 up
-
- This setting is not saved across reboots. It can be made permanent if
- you add:
-
- MTU=9000
-
- to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
- applies to the Red Hat distributions; other distributions may store this
- setting in a different location.
-
- Notes:
- Degradation in throughput performance may be observed in some Jumbo frames
- environments. If this is observed, increasing the application's socket buffer
- size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
- See the specific application manual and /usr/src/linux*/Documentation/
- networking/ip-sysctl.txt for more details.
-
- - The maximum MTU setting for Jumbo Frames is 16110. This value coincides
- with the maximum Jumbo Frames size of 16128.
-
- - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
- loss of link.
-
- - Adapters based on the Intel(R) 82542 and 82573V/E controller do not
- support Jumbo Frames. These correspond to the following product names:
- Intel(R) PRO/1000 Gigabit Server Adapter
- Intel(R) PRO/1000 PM Network Connection
-
- Ethtool
- -------
- The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information. The ethtool
- version 1.6 or later is required for this functionality.
-
- The latest release of ethtool can be found from
- http://ftp.kernel.org/pub/software/network/ethtool/
-
- Enabling Wake on LAN* (WoL)
- ---------------------------
- WoL is configured through the ethtool* utility.
-
- 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.
-
-Support
-=======
-
-For general information, go to the Intel support website at:
-
- http://support.intel.com
-
-or the Intel Wired Networking project hosted by Sourceforge at:
-
- http://sourceforge.net/projects/e1000
-
-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 e1000-devel@lists.sf.net
diff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt
deleted file mode 100644
index 97b5ba942eb..00000000000
--- a/Documentation/networking/e1000e.txt
+++ /dev/null
@@ -1,306 +0,0 @@
-Linux* Driver for Intel(R) Network Connection
-=============================================
-
-Intel Gigabit Linux driver.
-Copyright(c) 1999 - 2010 Intel Corporation.
-
-Contents
-========
-
-- Identifying Your Adapter
-- Command Line Parameters
-- Additional Configurations
-- Support
-
-Identifying Your Adapter
-========================
-
-The e1000e driver supports all PCI Express Intel(R) Gigabit Network
-Connections, except those that are 82575, 82576 and 82580-based*.
-
-* NOTE: The Intel(R) PRO/1000 P Dual Port Server Adapter is supported by
- the e1000 driver, not the e1000e driver due to the 82546 part being used
- behind a PCI Express bridge.
-
-For more information on how to identify your adapter, go to the Adapter &
-Driver ID Guide at:
-
- http://support.intel.com/support/go/network/adapter/idguide.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://support.intel.com/support/go/network/adapter/home.htm
-
-Command Line Parameters
-=======================
-
-The default value for each parameter is generally the recommended setting,
-unless otherwise noted.
-
-NOTES: 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
-
-InterruptThrottleRate
----------------------
-Valid Range: 0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
- 4=simplified balancing)
-Default Value: 3
-
-The driver can limit the amount of interrupts per second that the adapter
-will generate for incoming packets. It does this by writing a value to the
-adapter that is based on the maximum amount of interrupts that the adapter
-will generate per second.
-
-Setting InterruptThrottleRate to a value greater or equal to 100
-will program the adapter to send out a maximum of that many interrupts
-per second, even if more packets have come in. This reduces interrupt
-load on the system and can lower CPU utilization under heavy load,
-but will increase latency as packets are not processed as quickly.
-
-The default behaviour of the driver previously assumed a static
-InterruptThrottleRate value of 8000, providing a good fallback value for
-all traffic types, but lacking in small packet performance and latency.
-The hardware can handle many more small packets per second however, and
-for this reason an adaptive interrupt moderation algorithm was implemented.
-
-The driver has two adaptive modes (setting 1 or 3) in which
-it dynamically adjusts the InterruptThrottleRate value based on the traffic
-that it receives. After determining the type of incoming traffic in the last
-timeframe, it will adjust the InterruptThrottleRate to an appropriate value
-for that traffic.
-
-The algorithm classifies the incoming traffic every interval into
-classes. Once the class is determined, the InterruptThrottleRate value is
-adjusted to suit that traffic type the best. There are three classes defined:
-"Bulk traffic", for large amounts of packets of normal size; "Low latency",
-for small amounts of traffic and/or a significant percentage of small
-packets; and "Lowest latency", for almost completely small packets or
-minimal traffic.
-
-In dynamic conservative mode, the InterruptThrottleRate value is set to 4000
-for traffic that falls in class "Bulk traffic". If traffic falls in the "Low
-latency" or "Lowest latency" class, the InterruptThrottleRate is increased
-stepwise to 20000. This default mode is suitable for most applications.
-
-For situations where low latency is vital such as cluster or
-grid computing, the algorithm can reduce latency even more when
-InterruptThrottleRate is set to mode 1. In this mode, which operates
-the same as mode 3, the InterruptThrottleRate will be increased stepwise to
-70000 for traffic in class "Lowest latency".
-
-In simplified mode the interrupt rate is based on the ratio of TX and
-RX traffic. If the bytes per second rate is approximately equal, the
-interrupt rate will drop as low as 2000 interrupts per second. If the
-traffic is mostly transmit or mostly receive, the interrupt rate could
-be as high as 8000.
-
-Setting InterruptThrottleRate to 0 turns off any interrupt moderation
-and may improve small packet latency, but is generally not suitable
-for bulk throughput traffic.
-
-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.
-
-NOTE: When e1000e 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:
-
- modprobe e1000e 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.
-
-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
--------------
-Valid Range: 0-65535 (0=off)
-Default Value: 8
-
-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.
-
-TxIntDelay
-----------
-Valid Range: 0-65535 (0=off)
-Default Value: 8
-
-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
--------------
-Valid Range: 0-65535 (0=off)
-Default Value: 32
-
-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.
-
-Copybreak
----------
-Valid Range: 0-xxxxxxx (0=off)
-Default Value: 256
-
-Driver copies all packets below or equaling this size to a fresh RX
-buffer before handing it up the stack.
-
-This parameter is different than other parameters, in that it is a
-single (not 1,1,1 etc.) parameter applied to all driver instances and
-it is also available during runtime at
-/sys/module/e1000e/parameters/copybreak
-
-SmartPowerDownEnable
---------------------
-Valid Range: 0-1
-Default Value: 0 (disabled)
-
-Allows PHY to turn off in lower power states. The user can set this parameter
-in supported chipsets.
-
-KumeranLockLoss
----------------
-Valid Range: 0-1
-Default Value: 1 (enabled)
-
-This workaround skips resetting the PHY at shutdown for the initial
-silicon releases of ICH8 systems.
-
-IntMode
--------
-Valid Range: 0-2 (0=legacy, 1=MSI, 2=MSI-X)
-Default Value: 2
-
-Allows changing the interrupt mode at module load time, without requiring a
-recompile. If the driver load fails to enable a specific interrupt mode, the
-driver will try other interrupt modes, from least to most compatible. The
-interrupt order is MSI-X, MSI, Legacy. If specifying MSI (IntMode=1)
-interrupts, only MSI and Legacy will be attempted.
-
-CrcStripping
-------------
-Valid Range: 0-1
-Default Value: 1 (enabled)
-
-Strip the CRC from received packets before sending up the network stack. If
-you have a machine with a BMC enabled but cannot receive IPMI traffic after
-loading or enabling the driver, try disabling this feature.
-
-WriteProtectNVM
----------------
-Valid Range: 0,1
-Default Value: 1
-
-If set to 1, configure the hardware to ignore all write/erase cycles to the
-GbE region in the ICHx NVM (in order to prevent accidental corruption of the
-NVM). This feature can be disabled by setting the parameter to 0 during initial
-driver load.
-NOTE: The machine must be power cycled (full off/on) when enabling NVM writes
-via setting the parameter to zero. Once the NVM has been locked (via the
-parameter at 1 when the driver loads) it cannot be unlocked except via power
-cycle.
-
-Additional Configurations
-=========================
-
- Jumbo Frames
- ------------
- 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 eth<x> mtu 9000 up
-
- This setting is not saved across reboots.
-
- Notes:
-
- - The maximum MTU setting for Jumbo Frames is 9216. This value coincides
- with the maximum Jumbo Frames size of 9234 bytes.
-
- - Using Jumbo Frames at 10 or 100 Mbps is not supported and may result in
- poor performance or loss of link.
-
- - Some adapters limit Jumbo Frames sized packets to a maximum of
- 4096 bytes and some adapters do not support Jumbo Frames.
-
- Ethtool
- -------
- The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information. We
- strongly recommend downloading the latest version of ethtool at:
-
- http://ftp.kernel.org/pub/software/network/ethtool/
-
- Speed and Duplex
- ----------------
- Speed and Duplex are configured through the ethtool* utility. For
- instructions, refer to the ethtool man page.
-
- Enabling Wake on LAN* (WoL)
- ---------------------------
- WoL is configured through the ethtool* utility. 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 e1000e driver must be
- loaded when shutting down or rebooting the system.
-
- In most cases Wake On LAN is only supported on port A for multiple port
- adapters. To verify if a port supports Wake on Lan run ethtool eth<X>.
-
-Support
-=======
-
-For general information, go to the Intel support website at:
-
- www.intel.com/support/
-
-or the Intel Wired Networking project hosted by Sourceforge at:
-
- http://sourceforge.net/projects/e1000
-
-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 e1000-devel@lists.sf.net
diff --git a/Documentation/networking/eql.txt b/Documentation/networking/eql.txt
deleted file mode 100644
index 0f1550150f0..00000000000
--- a/Documentation/networking/eql.txt
+++ /dev/null
@@ -1,528 +0,0 @@
- 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
deleted file mode 100644
index 90e9e5f16e6..00000000000
--- a/Documentation/networking/ewrk3.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-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/fib_trie.txt b/Documentation/networking/fib_trie.txt
deleted file mode 100644
index 0723db7f849..00000000000
--- a/Documentation/networking/fib_trie.txt
+++ /dev/null
@@ -1,145 +0,0 @@
- LC-trie implementation notes.
-
-Node types
-----------
-leaf
- An end node with data. This has a copy of the relevant key, along
- with 'hlist' with routing table entries sorted by prefix length.
- See struct leaf and struct leaf_info.
-
-trie node or tnode
- An internal node, holding an array of child (leaf or tnode) pointers,
- indexed through a subset of the key. See Level Compression.
-
-A few concepts explained
-------------------------
-Bits (tnode)
- The number of bits in the key segment used for indexing into the
- child array - the "child index". See Level Compression.
-
-Pos (tnode)
- The position (in the key) of the key segment used for indexing into
- the child array. See Path Compression.
-
-Path Compression / skipped bits
- Any given tnode is linked to from the child array of its parent, using
- a segment of the key specified by the parent's "pos" and "bits"
- In certain cases, this tnode's own "pos" will not be immediately
- adjacent to the parent (pos+bits), but there will be some bits
- in the key skipped over because they represent a single path with no
- deviations. These "skipped bits" constitute Path Compression.
- Note that the search algorithm will simply skip over these bits when
- searching, making it necessary to save the keys in the leaves to
- verify that they actually do match the key we are searching for.
-
-Level Compression / child arrays
- the trie is kept level balanced moving, under certain conditions, the
- children of a full child (see "full_children") up one level, so that
- instead of a pure binary tree, each internal node ("tnode") may
- contain an arbitrarily large array of links to several children.
- Conversely, a tnode with a mostly empty child array (see empty_children)
- may be "halved", having some of its children moved downwards one level,
- in order to avoid ever-increasing child arrays.
-
-empty_children
- the number of positions in the child array of a given tnode that are
- NULL.
-
-full_children
- the number of children of a given tnode that aren't path compressed.
- (in other words, they aren't NULL or leaves and their "pos" is equal
- to this tnode's "pos"+"bits").
-
- (The word "full" here is used more in the sense of "complete" than
- as the opposite of "empty", which might be a tad confusing.)
-
-Comments
----------
-
-We have tried to keep the structure of the code as close to fib_hash as
-possible to allow verification and help up reviewing.
-
-fib_find_node()
- A good start for understanding this code. This function implements a
- straightforward trie lookup.
-
-fib_insert_node()
- Inserts a new leaf node in the trie. This is bit more complicated than
- fib_find_node(). Inserting a new node means we might have to run the
- level compression algorithm on part of the trie.
-
-trie_leaf_remove()
- Looks up a key, deletes it and runs the level compression algorithm.
-
-trie_rebalance()
- The key function for the dynamic trie after any change in the trie
- it is run to optimize and reorganize. Tt will walk the trie upwards
- towards the root from a given tnode, doing a resize() at each step
- to implement level compression.
-
-resize()
- Analyzes a tnode and optimizes the child array size by either inflating
- or shrinking it repeatedly until it fulfills the criteria for optimal
- level compression. This part follows the original paper pretty closely
- and there may be some room for experimentation here.
-
-inflate()
- Doubles the size of the child array within a tnode. Used by resize().
-
-halve()
- Halves the size of the child array within a tnode - the inverse of
- inflate(). Used by resize();
-
-fn_trie_insert(), fn_trie_delete(), fn_trie_select_default()
- The route manipulation functions. Should conform pretty closely to the
- corresponding functions in fib_hash.
-
-fn_trie_flush()
- This walks the full trie (using nextleaf()) and searches for empty
- leaves which have to be removed.
-
-fn_trie_dump()
- Dumps the routing table ordered by prefix length. This is somewhat
- slower than the corresponding fib_hash function, as we have to walk the
- entire trie for each prefix length. In comparison, fib_hash is organized
- as one "zone"/hash per prefix length.
-
-Locking
--------
-
-fib_lock is used for an RW-lock in the same way that this is done in fib_hash.
-However, the functions are somewhat separated for other possible locking
-scenarios. It might conceivably be possible to run trie_rebalance via RCU
-to avoid read_lock in the fn_trie_lookup() function.
-
-Main lookup mechanism
----------------------
-fn_trie_lookup() is the main lookup function.
-
-The lookup is in its simplest form just like fib_find_node(). We descend the
-trie, key segment by key segment, until we find a leaf. check_leaf() does
-the fib_semantic_match in the leaf's sorted prefix hlist.
-
-If we find a match, we are done.
-
-If we don't find a match, we enter prefix matching mode. The prefix length,
-starting out at the same as the key length, is reduced one step at a time,
-and we backtrack upwards through the trie trying to find a longest matching
-prefix. The goal is always to reach a leaf and get a positive result from the
-fib_semantic_match mechanism.
-
-Inside each tnode, the search for longest matching prefix consists of searching
-through the child array, chopping off (zeroing) the least significant "1" of
-the child index until we find a match or the child index consists of nothing but
-zeros.
-
-At this point we backtrack (t->stats.backtrack++) up the trie, continuing to
-chop off part of the key in order to find the longest matching prefix.
-
-At this point we will repeatedly descend subtries to look for a match, and there
-are some optimizations available that can provide us with "shortcuts" to avoid
-descending into dead ends. Look for "HL_OPTIMIZE" sections in the code.
-
-To alleviate any doubts about the correctness of the route selection process,
-a new netlink operation has been added. Look for NETLINK_FIB_LOOKUP, which
-gives userland access to fib_lookup().
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
deleted file mode 100644
index bbf2005270b..00000000000
--- a/Documentation/networking/filter.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-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
deleted file mode 100644
index d52af53efdc..00000000000
--- a/Documentation/networking/fore200e.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-
-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,
-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.
-
-
-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://en.wikipedia.org/wiki/FORE_Systems. 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 endianness 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
deleted file mode 100644
index 1a0b720440d..00000000000
--- a/Documentation/networking/framerelay.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-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
deleted file mode 100644
index 70e6275b757..00000000000
--- a/Documentation/networking/gen_stats.txt
+++ /dev/null
@@ -1,117 +0,0 @@
-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 needs 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, every time you dump my_rate_est_stats it will contain
-up-to-date 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
deleted file mode 100644
index 4eb3cc40b70..00000000000
--- a/Documentation/networking/generic-hdlc.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-Generic HDLC layer
-Krzysztof Halasa <khc@pm.waw.pl>
-
-
-Generic HDLC layer currently supports:
-1. Frame Relay (ANSI, CCITT, Cisco and no LMI)
- - Normal (routed) and Ethernet-bridged (Ethernet device emulation)
- interfaces can share a single PVC.
- - ARP support (no InARP support in the kernel - there is an
- experimental InARP user-space daemon available on:
- http://www.kernel.org/pub/linux/utils/net/hdlc/).
-2. raw HDLC - either IP (IPv4) interface or Ethernet device emulation
-3. Cisco HDLC
-4. PPP
-5. X.25 (uses X.25 routines).
-
-Generic HDLC is a protocol driver only - it needs a low-level driver
-for your particular hardware.
-
-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://www.kernel.org/pub/linux/utils/net/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