Check if DAD does not have source link-layer address option;
RFC2461 7.1.1.

Check if DAD is destined for solicited node multicast address
as RFC2461 required.

These patches fix ip multicast route (ipmr) on 2.5.73.

1 - Trivial C99 initialization
2 - Change functions/variables to static
3 - Drop and reacquire RTNL in error path
4 - Use time_after()
5 - Use alloc_netdev
6 - Fix OOPS on dropped packets
7 - Get rid of skb_linearize

Tested on 8-way SMP by bringing up pimd.

into osdl.org:/home/jmorris/bk/net/work-2.5

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

This error is handled in the signal delivery code and should never be
returned from a syscall unless a signal is pending.  Grepping seems to
indicate that that is in fact the case (but not for ERESTARTSYS, but
that is another problem).

into samba.org:/stuff/paulus/kernel/for-linus-ppc

Recently there has been a rash of Unexpected IO APIC reports on the
linux-smp mailing list.  Most of the most recent ones are due to some
newer Intel chipsets (865, 875).

The IO APIC Version register doesn't indicate the differences in these
IO APICs.

I have an patch that addresses these chipsets.  It has been tested by a
few people with good results and has been blessed by Maciej Rozycki.

Other than conditionally decoding IO APIC registers 2 and 3, we could
alternately ignore them since Linux doesn't use the values for anything
other than printing them.

This patch ignores IO APIC register 2 if it's the same value as IO APIC
register 1.  It also reads IO APIC register 3 if the IO APIC version is
>= 0x20, but some chipsets don't support this register, so it is also
ignored if its value if the same as IO APIC register 1 or 2.

Another possible(?) alternative is to read the PID/VID of the device to
determine which registers it supports.  However, PCI devices have not
been scanned at this point in init, so it would require scanning PCI
config space directly and I don't yet see the point of doing that.

Oh, and the UNEXPECTED_IO_APIC() function doesn't print anything in
2.5.current and I didn't change that.

This does the following:

 - IV value is current 512-byte sector relative to start of loop
   container file.  This is what all cryptoloop people have done, if I
   am not mistaken.  Andi or others - if you can demonstrate the need
   for a more flexible setup an additional ioctl field may be needed.  I
   hope we can do without.

 - made some things static

 - made lo_offset a loff_t

 - added lo_sizelimit

   If one wanted a (crypto)loop somewhere inside a container file, the
   old code allowed a starting offset, but no size, so that the
   cryptoloop always extended to the end of the container file.  This
   field allows one to select an arbitrary interval.  Note that this
   changes struct loop_info64.

 - improve error handling of loop_init()

 - removed the unused typedef transfer_proc_t.

 - added a define for LO_CRYPT_CRYPTOAPI

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

The semaphore in pnp_init_resource_table is not needed and, in some
cases, can cause resource management lockups.  This patch removes the
improperly placed semaphore.

In the last release, this api was accidently changed and therefore 
affected some drivers.  This patch corrects the issue by renaming
the api back to pnp_init_resource_table.

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

into kroah.com:/home/greg/linux/BK/gregkh-2.5

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

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

There were two errors in length check in the output path.
We could not send large packet (65535bytes).

This patch fixes the problem.

into intercode.com.au:/home/jmorris/bk/net/net-2.5

into intercode.com.au:/home/jmorris/bk/net/net-2.5

this fixes the logic kaweth uses to deal with ENOMEM from
usb_submit_urb(). Using the interrupt endpoint's completion
handller is longer an option because automagic resubmission
has been removed. Thus we use workqueues which can be delayed
so that kswapd can do its job and can use GFP_NOIO which is much
likelier to succeed.

 This is for 2.5.72 with the US_PR_DEVICE / US_SC_DEVICE patch in place.
 Tested and working.

The current local APIC code refuses to enable the local APIC
on a P4 if the BIOS booted us with the local APIC disabled.
This patch removes this unnecessary restriction. Please apply.

Most P4 machines do boot with the local APIC enabled, but
Keith Owens reported that the P4 based Compaq Evo N800v
disables the local APIC, even though the machine actually
works if Linux enables it.

It is possible that some P4 machines with broken BIOSen
were saved by our refusal to enable the local APIC. We
can handle them via the DMI blacklist rules instead.