Bug discovered by Mandred Spraul.

into nuts.ninka.net:/home/davem/src/BK/net-2.5

Thanks to Adrian Bunk for reporting.

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

The patch below removes obsolete #if'd code for kernel 2.0 and 2.2 from
drivers/net/wan/lmc/* (this includes the expansion of some #define's 
that were definded differently for different kernel versions).

This fix makes bonding not commit to a specific ABI version if the ioctl
command is not supported by bonding.

(It also removes the '\n' in the continuous printk reporting the link down
event in bond_mii_monitor - it got in there by mistake in our previous
patch set and caused log messages to appear funny in some situations).

This patch fixes the bug reported by Jay on April 3rd regarding long
failover time when releasing the last slave in the active aggregator. The
fix, as suggested by Jay, is to follow the spec recommendation and send a
LACPDU to the partner saying this port is no longer aggregatable and
therefore trigger an immediate re-selection of a new aggregator instead of
waiting the entire expiration timeout.

Add the m68knommu/Coldfire specific ints.c to build list.

Modify m68knommu/kernel Makefile to no longer compile removed
common ints.c.

Remove the m68knommu common ints.c. No longer needed with each
sub-architecture now having its own.

Create a m68knommu/ColdFire specific ints.c. It is just simpler to
have one for each sub-architecture (which means we currently need 3
for the 3 prominant m68knommu families). Each can handle the hardware
setup differences, and there is a few at this level.

Linear uses one array sized by MD_SB_DISKS inside a structure.
We move it to the end of the structure, declare it as size 0,
and arrange for approprate extra space to be allocated on
structure allocation.

raid1 uses MD_SB_DISKS to size two data structures,
but the new version-1 superblock allows for more than
this number of disks (and most actual arrays use many
fewer).
This patch sizes to two arrays dynamically.
One becomes a separate kmalloced array.
The other is moved to the end of the containing structure
and appropriate extra space is allocated.

Also, change r1buf_pool_alloc (which allocates buffers for
a mempool for doing re-sync) to not get r1bio structures
from the r1bio pool (which could exhaust the pool) but instead
to allocate them separately.

Arrays with type-1 superblock can have more than
MD_SB_DISKS, so we remove the dependancy on that number from
raid0, replacing several fixed sized arrays with one
dynamically allocated array.

One embeded array gets moved to end of structure and
sized dynamically.

Multipath has a dependancy on MD_SB_DISKS which is no
longer authoritative.  We change it to use a separately
allocated array.

To cope with a raid0 array with differing sized devices,
raid0 divides an array into "strip zones".
The first zone covers the start of all devices, upto an offset
equal to the size of the smallest device.

The second strip zone covers the remaining devices upto the size of the
next smallest size, etc.

In order to determing which strip zone a given address is in,
the array is logically divided into slices the size of the smallest
zone, and a 'hash' table is created listing the first and, if relevant,
second zone in each slice.

As the smallest slice can be very small (imagine an array with a
76G drive and a 75.5G drive) this hash table can be rather large.

With this patch, we limit the size of the hash table to one page,
at the possible cost of making several probes into the zone list
before we find the correct zone.

We also cope with the possibility that a zone could be larger than
a 32bit sector address would allow.

When starting an array fails, we have to tear it down, but
in some circumstances (particularly autostart_array) the
reference count will be 3, so do_md_stop will fail.

With this patch we only worry about the number of users
is the array has been fully started.

raid0 currently uses vmalloc instead of kmalloc.  This patch
changes to kmalloc.
There is one allocation that can occasionally be very large - the hash_table.
A subsequent patch will address this issue.