Merge with Linux 2.4.0-test6-pre3.

7 files changed, 369 insertions, 125 deletions

diff --git a/Documentation/Changes b/Documentation/Changes
index 9479dc463..f856fe16b 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -43,7 +43,7 @@ with pcmcia-cs.
 o  Gnu C                  2.7.2.3                 # gcc --version
 o  binutils               2.9.1.0.22              # ld -v
 o  util-linux             2.10g                   # chsh -v
-o  modutils               2.3.10                  # insmod -V
+o  modutils               2.3.13                  # insmod -V
 o  e2fsprogs              1.18                    # /sbin/tune2fs --version
 o  pcmcia-cs              3.1.13                  # cardmgr -V
 o  PPP                    2.4.0b1                 # pppd --version
@@ -266,8 +266,8 @@ o  ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.3
 
 Modutils
 --------
-o  ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3/modutils-2.3.9.tar.gz
-     <ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3/modutils-2.3.9.tar.gz>
+o  ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3/modutils-2.3.13.tar.gz
+     <ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3/modutils-2.3.13.tar.gz>
 
 E2fsprogs
 ---------
diff --git a/Documentation/Configure.help b/Documentation/Configure.help
index b64444b26..b94126f2c 100644
--- a/Documentation/Configure.help
+++ b/Documentation/Configure.help
@@ -4649,9 +4649,11 @@ CONFIG_PACKET_MMAP
 Kernel/User network link driver
 CONFIG_NETLINK
   This driver allows for two-way communication between the kernel and
-  user processes; the user processes communicate with the kernel by
-  reading from and writing to character special files in the /dev
-  directory having major mode 36.
+  user processes. It does so by creating a new socket family, PF_NETLINK.
+  Over this socket, the kernel can send and receive datagrams carrying
+  information. It is documented on many systems in netlink(7), a HOWTO is
+  provided as well, for example on
+  http://snafu.freedom.org/linux2.2/docs/netlink-HOWTO.html
 
   So far, the kernel uses this feature to publish some network related
   information if you say Y to "Routing messages", below. You also need
@@ -4665,16 +4667,19 @@ CONFIG_NETLINK
 
 Routing messages
 CONFIG_RTNETLINK
-  If you say Y here and create a character special file /dev/route
-  with major number 36 and minor number 0 using mknod ("man mknod"),
-  you (or some user space utility) can read some network related
-  routing information from that file. Everything you write to that
-  file will be discarded.
+  If you say Y here, userspace programs can receive some network
+  related routing information over the netlink. 'rtmon', supplied
+  with the iproute2 package (ftp://ftp.inr.ac.ru), can read and
+  interpret this data.  Information sent to the kernel over this link
+  is ignored.
 
 Netlink device emulation
 CONFIG_NETLINK_DEV
+  This option will be removed soon. Any programs that want to use
+  character special nodes like /dev/tap0 or /dev/route (all with major
+  number 36) need this option, and need to be rewritten soon to use
+  the real netlink socket.
   This is a backward compatibility option, choose Y for now.
-  This option will be removed soon.
 
 Asynchronous Transfer Mode (ATM)
 CONFIG_ATM
diff --git a/Documentation/README.DAC960 b/Documentation/README.DAC960
index 2a80042dc..8166455b0 100644
--- a/Documentation/README.DAC960
+++ b/Documentation/README.DAC960
@@ -1,47 +1,52 @@
-	   Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux
+   Linux Driver for Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers
 
-			Version 2.2.4 for Linux 2.2.11
-			Version 2.0.4 for Linux 2.0.37
+			Version 2.2.7 for Linux 2.2.16
+			Version 2.4.7 for Linux 2.4.0
 
 			      PRODUCTION RELEASE
 
-				23 August 1999
+				 1 August 2000
 
 			       Leonard N. Zubkoff
 			       Dandelion Digital
 			       lnz@dandelion.com
 
-	 Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com>
+	 Copyright 1998-2000 by Leonard N. Zubkoff <lnz@dandelion.com>
 
 
 				 INTRODUCTION
 
 Mylex, Inc. designs and manufactures a variety of high performance PCI RAID
 controllers.  Mylex Corporation is located at 34551 Ardenwood Blvd., Fremont,
-California 94555, USA and can be reached at 510/796-6100 or on the World Wide
-Web at http://www.mylex.com.  Mylex RAID Technical Support can be reached by
-electronic mail at support@mylex.com (for eXtremeRAID 1100 and older DAC960
-models) or techsup@mylex.com (for AcceleRAID models), by voice at 510/608-2400,
-or by FAX at 510/745-7715.  Contact information for offices in Europe and Japan
-is available on the Web site.
+California 94555, USA and can be reached at 510.796.6100 or on the World Wide
+Web at http://www.mylex.com.  Mylex Technical Support can be reached by
+electronic mail at support@mylex.com, by voice at 510.608.2400, or by FAX at
+510.745.7715.  Contact information for offices in Europe and Japan is available
+on their Web site.
 
 The latest information on Linux support for DAC960 PCI RAID Controllers, as
 well as the most recent release of this driver, will always be available from
 my Linux Home Page at URL "http://www.dandelion.com/Linux/".  The Linux DAC960
-driver supports all current DAC960 PCI family controllers including the
-AcceleRAID models, as well as the eXtremeRAID 1100; see below for a complete
-list.  For simplicity, in most places this documentation refers to DAC960
-generically rather than explicitly listing all the models.
-
-Bug reports should be sent via electronic mail to "lnz@dandelion.com".  Please
-include with the bug report the complete configuration messages reported by the
-driver at startup, along with any subsequent system messages relevant to the
-controller's operation, and a detailed description of your system's hardware
-configuration.
-
-Please consult the DAC960 RAID controller documentation for detailed
-information regarding installation and configuration of the controllers.  This
-document primarily provides information specific to the Linux DAC960 support.
+driver supports all current Mylex PCI RAID controllers including the new
+eXtremeRAID 2000/3000 and AcceleRAID 352/170 models which have an entirely new
+firmware interface from the older eXtremeRAID 1100, AcceleRAID 150/200/250, and
+DAC960PJ/PG/PU/PD/PL.  See below for a complete controller list as well as
+minimum firmware version requirements.  For simplicity, in most places this
+documentation refers to DAC960 generically rather than explicitly listing all
+the supported models.
+
+Driver bug reports should be sent via electronic mail to "lnz@dandelion.com".
+Please include with the bug report the complete configuration messages reported
+by the driver at startup, along with any subsequent system messages relevant to
+the controller's operation, and a detailed description of your system's
+hardware configuration.  Driver bugs are actually quite rare; if you encounter
+problems with disks being marked offline, for example, please contact Mylex
+Technical Support as the problem is related to the hardware configuration
+rather than the Linux driver.
+
+Please consult the RAID controller documentation for detailed information
+regarding installation and configuration of the controllers.  This document
+primarily provides information specific to the Linux support.
 
 
 				DRIVER FEATURES
@@ -60,16 +65,18 @@ of the controller and adding new disk drives, most everything can be handled
 from Linux while the system is operational.
 
 The DAC960 driver is architected to support up to 8 controllers per system.
-Each DAC960 controller can support up to 15 disk drives per channel, for a
-maximum of 45 drives on a three channel controller.  The drives installed on a
-controller are divided into one or more "Drive Groups", and then each Drive
-Group is subdivided further into 1 to 32 "Logical Drives".  Each Logical Drive
-has a specific RAID Level and caching policy associated with it, and it appears
-to Linux as a single block device.  Logical Drives are further subdivided into
-up to 7 partitions through the normal Linux and PC disk partitioning schemes.
-Logical Drives are also known as "System Drives", and Drive Groups are also
-called "Packs".  Both terms are in use in the Mylex documentation; I have
-chosen to standardize on the more generic "Logical Drive" and "Drive Group".
+Each DAC960 parallel SCSI controller can support up to 15 disk drives per
+channel, for a maximum of 60 drives on a four channel controller; the fibre
+channel eXtremeRAID 3000 controller supports up to 125 disk drives per loop for
+a total of 250 drives.  The drives installed on a controller are divided into
+one or more "Drive Groups", and then each Drive Group is subdivided further
+into 1 to 32 "Logical Drives".  Each Logical Drive has a specific RAID Level
+and caching policy associated with it, and it appears to Linux as a single
+block device.  Logical Drives are further subdivided into up to 7 partitions
+through the normal Linux and PC disk partitioning schemes.  Logical Drives are
+also known as "System Drives", and Drive Groups are also called "Packs".  Both
+terms are in use in the Mylex documentation; I have chosen to standardize on
+the more generic "Logical Drive" and "Drive Group".
 
 DAC960 RAID disk devices are named in the style of the Device File System
 (DEVFS).  The device corresponding to Logical Drive D on Controller C is
@@ -82,17 +89,41 @@ controller.  The 8 bits of minor number are divided into 5 bits for the Logical
 Drive and 3 bits for the partition.
 
 
-		 SUPPORTED DAC960/DAC1100 PCI RAID CONTROLLERS
+	  SUPPORTED DAC960/AcceleRAID/eXtremeRAID PCI RAID CONTROLLERS
 
-The following list comprises the supported DAC960 and DAC1100 PCI RAID
-Controllers as of the date of this document.  It is recommended that anyone
-purchasing a Mylex PCI RAID Controller not in the following table contact the
-author beforehand to verify that it is or will be supported.
+The following list comprises the supported DAC960, AcceleRAID, and eXtremeRAID
+PCI RAID Controllers as of the date of this document.  It is recommended that
+anyone purchasing a Mylex PCI RAID Controller not in the following table
+contact the author beforehand to verify that it is or will be supported.
+
+eXtremeRAID 3000
+	    1 Wide Ultra-2/LVD SCSI channel
+	    2 External Fibre FC-AL channels
+	    233MHz StrongARM SA 110 Processor
+	    64 Bit 33MHz PCI (backward compatible with 32 Bit PCI slots)
+	    32MB/64MB ECC SDRAM Memory
+
+eXtremeRAID 2000
+	    4 Wide Ultra-160 LVD SCSI channels
+	    233MHz StrongARM SA 110 Processor
+	    64 Bit 33MHz PCI (backward compatible with 32 Bit PCI slots)
+	    32MB/64MB ECC SDRAM Memory
+
+AcceleRAID 352
+	    2 Wide Ultra-160 LVD SCSI channels
+	    100MHz Intel i960RN RISC Processor
+	    64 Bit 33MHz PCI (backward compatible with 32 Bit PCI slots)
+	    32MB/64MB ECC SDRAM Memory
+
+AcceleRAID 170
+	    1 Wide Ultra-160 LVD SCSI channel
+	    100MHz Intel i960RM RISC Processor
+	    16MB/32MB/64MB ECC SDRAM Memory
 
 eXtremeRAID 1100 (DAC1164P)
 	    3 Wide Ultra-2/LVD SCSI channels
 	    233MHz StrongARM SA 110 Processor
-	    64 Bit PCI (backward compatible with 32 Bit PCI slots)
+	    64 Bit 33MHz PCI (backward compatible with 32 Bit PCI slots)
 	    16MB/32MB/64MB Parity SDRAM Memory with Battery Backup
 
 AcceleRAID 250 (DAC960PTL1)
@@ -133,6 +164,9 @@ DAC960PL    1/2/3 Wide Fast SCSI-2 Channels
 	    Intel i960 RISC Processor
 	    2MB/4MB/8MB/16MB/32MB DRAM Memory
 
+For the eXtremeRAID 2000/3000 and AcceleRAID 352/170, firmware version 6.00-01
+or above is required.
+
 For the eXtremeRAID 1100, firmware version 5.06-0-52 or above is required.
 
 For the AcceleRAID 250, 200, and 150, firmware version 4.06-0-57 or above is
@@ -163,13 +197,13 @@ ftp://ftp.mylex.com/pub/dac960/diskcomp.html.
 
 			      DRIVER INSTALLATION
 
-This distribution was prepared for Linux kernel version 2.2.11 or 2.0.37.
+This distribution was prepared for Linux kernel version 2.2.16 or 2.4.0.
 
 To install the DAC960 RAID driver, you may use the following commands,
 replacing "/usr/src" with wherever you keep your Linux kernel source tree:
 
   cd /usr/src
-  tar -xvzf DAC960-2.2.4.tar.gz (or DAC960-2.0.4.tar.gz)
+  tar -xvzf DAC960-2.2.7.tar.gz (or DAC960-2.4.7.tar.gz)
   mv README.DAC960 linux/Documentation
   mv DAC960.[ch] linux/drivers/block
   patch -p0 < DAC960.patch
@@ -201,13 +235,13 @@ system, the controller must first be configured to provide one or more logical
 drives using the BIOS Configuration Utility or DACCF.  Please note that since
 there are only at most 6 usable partitions on each logical drive, systems
 requiring more partitions should subdivide a drive group into multiple logical
-drives, each of which can have up to 6 partitions.  Also, note that with large
-disk arrays it is advisable to enable the 8GB BIOS Geometry (255/63) rather
-than accepting the default 2GB BIOS Geometry (128/32); failing to so do will
-cause the logical drive geometry to have more than 65535 cylinders which will
-make it impossible for FDISK to be used properly.  The 8GB BIOS Geometry can be
-enabled by configuring the DAC960 BIOS, which is accessible via Alt-M during
-the BIOS initialization sequence.
+drives, each of which can have up to 6 usable partitions.  Also, note that with
+large disk arrays it is advisable to enable the 8GB BIOS Geometry (255/63)
+rather than accepting the default 2GB BIOS Geometry (128/32); failing to so do
+will cause the logical drive geometry to have more than 65535 cylinders which
+will make it impossible for FDISK to be used properly.  The 8GB BIOS Geometry
+can be enabled by configuring the DAC960 BIOS, which is accessible via Alt-M
+during the BIOS initialization sequence.
 
 For maximum performance and the most efficient E2FSCK performance, it is
 recommended that EXT2 file systems be built with a 4KB block size and 16 block
diff --git a/Documentation/ia64/README b/Documentation/ia64/README
index 54b591caa..738572a80 100644
--- a/Documentation/ia64/README
+++ b/Documentation/ia64/README
@@ -57,8 +57,8 @@ IA-64 SPECIFICS
       table and only if that fails fall back on walking the page table
       tree.
 	  
-    o Discontinuous large memory support; memory above 4GB will be
-      discontinuous since the 4GB-64MB is reserved for firmware and I/O
+    o Discontiguous large memory support; memory above 4GB will be
+      discontiguous since the 4GB-64MB is reserved for firmware and I/O
       space.
  
     o Correct mapping for PAL runtime code; PAL code needs to be
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 42f894248..d3c8bbdaa 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -20,6 +20,8 @@ restrictions referred to are that the relevant option is valid if:
 	EIDE	EIDE/ATAPI support is enabled.
 	FB	The frame buffer device is enabled.
 	HW	Appropriate hardware is enabled.
+	IA-32	IA-32 aka i386 architecture is enabled.
+	IA-64	IA-64 architecture is enabled.
 	ISDN	Appropriate ISDN support is enabled.
 	JOY 	Appropriate joystick support is enabled.
 	LP	Printer support is enabled.
@@ -396,7 +398,36 @@ running once the system is up.
 
 	pcd.		[PARIDE]
 
-	pci=		[PCI]
+	pci=option[,option...]		[PCI] various PCI subsystem options:
+		off			[IA-32] don't probe for the PCI bus
+		bios			[IA-32] force use of PCI BIOS, don't access
+					the hardware directly. Use this if your machine
+					has a non-standard PCI host bridge.
+		nobios			[IA-32] disallow use of PCI BIOS, only direct
+					hardware access methods are allowed. Use this
+					if you experience crashes upon bootup and you
+					suspect they are caused by the BIOS.
+		conf1			[IA-32] Force use of PCI Configuration Mechanism 1.
+		conf2			[IA-32] Force use of PCI Configuration Mechanism 2.
+		nosort			[IA-32] Don't sort PCI devices according to
+					order given by the PCI BIOS. This sorting is done
+					to get a device order compatible with older kernels.
+		biosirq			[IA-32] Use PCI BIOS calls to get the interrupt
+					routing table. These calls are known to be buggy
+					on several machines and they hang the machine when used,
+					but on other computers it's the only way to get the
+					interrupt routing table. Try this option if the kernel
+					is unable to allocate IRQs or discover secondary PCI
+					buses on your motherboard.
+		rom			[IA-32] Assign address space to expansion ROMs.
+					Use with caution as certain devices share address
+					decoders between ROMs and other resources.
+		irqmask=0xMMMM		[IA-32] Set a bit mask of IRQs allowed to be assigned
+					automatically to PCI devices. You can make the kernel
+					exclude IRQs of your ISA cards this way.
+		lastbus=N		[IA-32] Scan all buses till bus #N. Can be useful
+					if the kernel is unable to find your secondary buses
+					and you want to tell it explicitly which ones they are.
 
 	pd.		[PARIDE]
 
diff --git a/Documentation/networking/ethertap.txt b/Documentation/networking/ethertap.txt
index 653f043a7..4a27cd899 100644
--- a/Documentation/networking/ethertap.txt
+++ b/Documentation/networking/ethertap.txt
@@ -1,88 +1,262 @@
-Documentation on setup and use of EtherTap.
+Ethertap programming mini-HOWTO
+-------------------------------
 
-Contact Jay Schulist <jschlst@turbolinux.com> if you
-have questions or need further assistance.
+The ethertap driver was written by Jay Schulist <jschlst@turbolinux.com>,
+you should contact him for further information. This document was written by
+bert hubert <bert.hubert@netherlabs.nl>. Updates are welcome.
 
-Introduction
-============
+What ethertap can do for you
+----------------------------
 
-Ethertap provides packet reception and transmission for user
-space programs. It can be viewed as a simple Ethernet device,
-which instead of receiving packets from a network wire, it receives
-them from user space.
+Ethertap allows you to easily run your own network stack from userspace.
+Tunnels can benefit greatly from this. You can also use it to do network
+experiments. The alternative would be to use a raw socket to send data and
+use libpcap to receive it. Using ethertap saves you this multiplicity and
+also does ARP for you if you want.
 
-Ethertap can be used for anything from AppleTalk to IPX to even 
-building bridging tunnels. It also has many other general purpose
-uses.
+The more technical blurb:
 
-Ethertap also can do ARP for you, although this is not enabled by
-default.
+Ethertap provides packet reception and transmission for user space programs.
+It can be viewed as a simple Ethernet device, which instead of receiving
+packets from a network wire, it receives them from user space.
 
-SetUp
-=====
+Ethertap can be used for anything from AppleTalk to IPX to even building
+bridging tunnels. It also has many other general purpose uses.
 
-First you will have to enable Ethertap in the kernel configuration.
-Then you will need to create any number of ethertap device files,
-/dev/tap0->/dev/tap15. This is done by the following command.
+Configuring your kernel
+-----------------------
 
-mknod /dev/tap* c 36 16  ( 17 18 19 20 for tap1,2,3,4...)
+Firstly, you need this in Networking Options:
 
-** Replace * with the proper tap device number you need. **
+	#
+	# Code maturity level options
+	#
+	CONFIG_EXPERIMENTAL=y
 
-Now with your kernel that has ethertap enabled, you will need
-to ifconfig /dev/tap* 192.168.1.1 (replace 192.168.1.1 with the
-proper IP number for your situation.)
+Then you need Netlink support:
 
-If you want your Ethertap device to ARP for you would ifconfig
-the interface like this: ifconfig tap* 192.168.1.1 arp
+	CONFIG_NETLINK=y
 
-Remember that you need to have a corresponding /dev/tap* file
-for each tap* device you need to ifconfig.
+This allows the kernel to exchange data with userspace applications. There
+are two ways of doing this, the new way works with netlink sockets and I
+have no experience with that yet. ANK uses it in his excellent iproute2
+package, see for example rtmon.c. iproute2 can be found on
+ftp://ftp.inr.ac.ru/ip-routing/iproute2*
 
-Now Ethertap should be ready to use.
+The new way is described, partly in netlink(7), available on 
+http://www.europe.redhat.com/documentation/man-pages/man7/netlink.7.php3
 
-Diagram of how Ethertap works. (Courtesy of Alan Cox)
-====================================================
+There is also a Netlink-HOWTO, available on http://snafu.freedom.org/linux2.2/docs/netlink-HOWTO.html
+Sadly I know of no code using ethertap with this new interface.
 
-This is for a tunnel, but you should be able to
-get the general idea.
+The older way works by opening character special files with major node 36.
+Enable this with:
 
-        1.2.3.4 will be the router to the outside world
-        1.2.3.5 our box
-        2.0.0.1 our box (appletalk side)
-        2.0.0.* a pile of macintoys
+	CONFIG_NETLINK_DEV=m
 
+Please be advised that this support is going to be dropped somewhere in the
+future!
 
-[1.2.3.4]-------------1.2.3.5[Our Box]2.0.0.1---------> macs
+Then finally in the Network Devices section, 
 
-The routing on our box would be
+	CONFIG_ETHERTAP=m
 
-                ifconfig eth0 1.2.3.5 netmask 255.255.255.0 up
-                route add default gw 1.2.3.4
-                ifconfig tap0   2.0.0.1 netmask 255.255.255.0 up arp
-                (route add 2.0.0.0 netmask 255.255.255.0)
+You can include it directly in the kernel if you want, of course, no need
+for modules.
 
-C code for a Simple program using an EtherTap device
-====================================================
+Setting it all up
+-----------------
 
-This code is just excerpts from a real program, so some parts are missing
-but the important stuff is below.
+First we need to create the /dev/tap0 device node:
 
-void main (void)
+	# mknod /dev/tap0 c 36 16
+	# mknod /dev/tap1 c 36 17
+	(etc)
+
+Include the relevant modules (ethertap.o, netlink_dev.o, perhaps netlink.o),
+and bring up your tap0 device:
+
+	# ifconfig tap0 10.0.0.123 up
+
+Now your device is up and running, you can ping it as well. This is what
+confused me to no end, because nothing is connected to our ethertap as yet,
+how is it that we can ping it?
+
+It turns out that the ethertap is just like a regular network interface -
+even when it's down you can ping it. We need to route stuff to it:
+
+	# route add -host 10.0.0.124 gw 10.0.0.123
+
+Now we can read /dev/tap0 and when we ping 10.0.0.124 from our
+localhost, output should appear on the screen.
+
+	# cat /dev/tap0
+	:ßVU:9````````````````````````şışET@?'
+
+
+Getting this to work from other hosts
+-------------------------------------
+
+For this to work, you often need proxy ARP. 
+
+	# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp 
+
+eth0 here stands for the interface that connects to 'other hosts'.
+
+Chances are that you are trying this on a non-routing desktop computer, so
+you need to enable ip forwarding:
+
+	# echo 1 > /proc/sys/net/ipv4/ip_forward 
+
+You should now be able to ping 10.0.0.124 from other hosts on your
+10.0.0.0/8 subnet. If you are using public ip space, it should work from
+everywhere.
+
+ARP
+---
+
+If we were to take things very literally, your tcp/ip pseudo stack would
+also have to implement ARP and MAC addresses. This is often a bit silly as
+the ethertap device is a figment of our imagination anyway. However, should
+you want to go 'all the way', you can add the 'arp' flag to ifconfig:
+
+	# ifconfig tap0 10.0.0.123 up arp
+
+This may also be useful when implementing a bridge, which needs to bridge
+ARP packets as well.
+
+The sample program below will no longer work then, because it does not
+implement ARP. 
+
+Sample program
+--------------
+
+A sample program is included somewhere in the bowels of the netfilter
+source. I've extracted this program and list it here. It implements a very
+tiny part of the IP stack and can respond to any pings it receives. It gets
+confused if it receives ARP, as it tries to parse it by treating it as an IP
+packet.
+
+/* Simple program to listen to /dev/tap0 and reply to pings. */
+#include <fcntl.h>
+#include <netinet/ip.h>
+#include <netinet/ip_icmp.h>
+#if defined(__GLIBC__) && (__GLIBC__ == 2)
+#include <netinet/tcp.h>
+#include <netinet/udp.h>
+#else
+#include <linux/tcp.h>
+#include <linux/udp.h>
+#endif
+#include <string.h>
+#include <stdio.h>
+#include <errno.h>
+#include <unistd.h>
+
+u_int16_t csum_partial(void *buffer, unsigned int len, u_int16_t prevsum)
 {
-	int TapDevice, eth_pkt_len = 0;
-	unsigned char full_pkt_len[MAX_PKT_LEN];
+	u_int32_t sum = 0;
+	u_int16_t *ptr = buffer;
+
+	while (len > 1)  {
+		sum += *ptr++;
+		len -= 2;
+	}
+	if (len) {
+		union {
+			u_int8_t byte;
+			u_int16_t wyde;
+		} odd;
+		odd.wyde = 0;
+		odd.byte = *((u_int8_t *)ptr);
+		sum += odd.wyde;
+	}
+	sum = (sum >> 16) + (sum & 0xFFFF);
+	sum += prevsum;
+	return (sum + (sum >> 16));
+}
+
+int main()
+{
+	int fd, len;
+	union {
+		struct {
+			char etherhdr[16];
+			struct iphdr ip;
+		} fmt;
+		unsigned char raw[65536];
+	} u;
+
+	fd = open("/dev/tap0", O_RDWR);
+	if (fd < 0) {
+		perror("Opening `/dev/tap0'");
+		return 1;
+	}
+
+	/* u.fmt.ip.ihl in host order!  Film at 11. */
+	while ((len = read(fd, &u, sizeof(u))) > 0) {
+		u_int32_t tmp;
+ 		struct icmphdr *icmp
+			= (void *)((u_int32_t *)&u.fmt.ip + u.fmt.ip.ihl );
+		struct tcphdr *tcp = (void *)icmp;
+		struct udphdr *udp = (void *)icmp;
+		
+		fprintf(stderr, "SRC = %u.%u.%u.%u DST = %u.%u.%u.%u\n",
+			(ntohl(u.fmt.ip.saddr) >> 24) & 0xFF,
+			(ntohl(u.fmt.ip.saddr) >> 16) & 0xFF,
+			(ntohl(u.fmt.ip.saddr) >> 8) & 0xFF,
+			(ntohl(u.fmt.ip.saddr) >> 0) & 0xFF,
+			(ntohl(u.fmt.ip.daddr) >> 24) & 0xFF,
+			(ntohl(u.fmt.ip.daddr) >> 16) & 0xFF,
+			(ntohl(u.fmt.ip.daddr) >> 8) & 0xFF,
+			(ntohl(u.fmt.ip.daddr) >> 0) & 0xFF);
+
+		switch (u.fmt.ip.protocol) {
+		case IPPROTO_ICMP:
+			if (icmp->type == ICMP_ECHO) {
+				fprintf(stderr, "PONG! (iphdr = %u bytes)\n",
+					(unsigned int)((char *)icmp
+						       - (char *)&u.fmt.ip));
 
-	TapDevice = open("/dev/tap0", O_RDWR);
-        if(TapDevice < 0)
-        {
-                perror("Error opening device");
-                exit(1);
-        }
+				/* Turn it around */
+				tmp = u.fmt.ip.saddr;
+				u.fmt.ip.saddr = u.fmt.ip.daddr;
+				u.fmt.ip.daddr = tmp;
 
-	write(TapDevice, full_packet, eth_pkt_len);
+				icmp->type = ICMP_ECHOREPLY;
+				icmp->checksum = 0;
+				icmp->checksum
+					= ~csum_partial(icmp,
+							ntohs(u.fmt.ip.tot_len)
+							- u.fmt.ip.ihl*4, 0);
 
-	close(TapDevice);
+				{
+					unsigned int i;
+					for (i = 44;
+					     i < ntohs(u.fmt.ip.tot_len); i++){
+						printf("%u:0x%02X ", i,
+						       ((unsigned char *)
+							&u.fmt.ip)[i]);
+					}
+					printf("\n");
+				}
+				write(fd, &u, len);
+			}
+			break;
+		case IPPROTO_TCP:
+			fprintf(stderr, "TCP: %u -> %u\n", ntohs(tcp->source),
+				ntohs(tcp->dest));
+			break;
 
-	return;
+		case IPPROTO_UDP:
+			fprintf(stderr, "UDP: %u -> %u\n", ntohs(udp->source),
+				ntohs(udp->dest));
+			break;
+		}
+	}
+	if (len < 0)
+		perror("Reading from `/dev/tap0'");
+	else fprintf(stderr, "Empty read from `/dev/tap0'");
+	return len < 0 ? 1 : 0;
 }
+			
diff --git a/Documentation/vm/numa b/Documentation/vm/numa
index b28fb352b..21a3442b7 100644
--- a/Documentation/vm/numa
+++ b/Documentation/vm/numa
@@ -14,7 +14,7 @@ across nodes, and trying to house all the data structures that
 key components of the kernel need on memory on that node.
 
 Currently, all the numa support is to provide efficient handling
-of widely discontinuous physical memory, so architectures which 
+of widely discontiguous physical memory, so architectures which 
 are not NUMA but can have huge holes in the physical address space
 can use the same code. All this code is bracketed by CONFIG_DISCONTIGMEM.