Some PnPBIOSes do not follow the specifications with regard to
disabling devices.  This patch preserves the tag bits, while zeroing
the resource settings.  Previously we would zero the entire buffer.
It has been tested and appears to correct the issue while remaining
compatible with unbroken PnPBIOSes.

This patch reorganizes resource flags to ensure that manual resource
settings are properly recognized.  This fix is necessary for many ALSA
drivers.  It also prevents comparisons between unset resource
structures.  The bug was discovered by Rene Herman
<rene.herman@keyaccess.nl>, who also wrote an initial version of this
patch.  I made further improvements to ensure that the pnp subsystem 
was compatible with this initial change.

The serial driver currently fails to unregister its pnp driver upon
module unload.  This patch corrects the problem by calling
pnp_unregister_driver and implementing a proper remove function.

We're actually much better off resetting system call restart at signal
return.

This makes all other resets unnecessary.

Here's the ppc version of it.

invoking the signal. This fixes all races.

As per discussion with Paul Mackerras on linux-kernel.

into home.osdl.org:/home/torvalds/v2.5/linux

This patch ensures that the PPC kernel cancels any pending restarted
system call when it delivers a signal.  This is the PPC counterpart of
the change that has recently gone into i386 and other architectures.

This patch fixes a bug on PPC where the kernel will oops if a process
does a system call and the system call number is out of range.

While fixing that, I noticed that if the process is being ptraced, an
out-of-range system call will not get traced on the way in but will on
the way out.  This patch fixes that too, by making it get traced on
the way in as well as the way out.  It turned out to be less change,
and fewer instructions overall, to do that than to make the
out-of-range system call not be traced at all.

Early ACPI table parse for HPET tables has a bug, where in it
does not do proper set_fixmap for ACPI-HPET table.

This bug was lost in oversight, and was not noticed during
my testing too, as the ACPI-HPET table on all my test
systems happened to be in 1st Gig of memory (where __va()
will do the job).

The 2.4 megaraid driver recognizes the Intel PCI vendor id whereas the
2.6 driver does not.  The attached patch against 2.6.0-test9 adds the
missing two lines from the 2.4 driver to enable this.

into home.osdl.org:/home/torvalds/v2.5/linux

into cantab.net:/home/aia21/ntfs-2.6

So just print a warning and continue.

into home.osdl.org:/home/torvalds/v2.5/linux

The #ifdef CONFIG_SMP around the call to schedule_tail was removed a
long time ago for native ia64, but ia32 emulation continues to have a
#ifdef.  We saw a bunch of weird behavior with respect to getpid() on
multithreaded programs (they behave ok on SMP, but break on UP). 

into home.osdl.org:/home/torvalds/v2.5/linux

into redhat.com:/spare/repo/net-drivers-2.5

(fixes crash)

into hera.kernel.org:/home/davem/BK/net-2.5

This forward-ports some more of the ALI IDE sanity checks from the 2.4.x
tree. 

In particular, we only do the enable bits for revisions < 0xC5

We've resolved some bugs in legacy ALi5455 audio driver.

into home.osdl.org:/home/torvalds/v2.5/linux

This leaves just the minimal oops protection in place, and
maintains the logic that "if we have a non-ALI northbridge,
we shouldn't touch any of the GPIOs because we don't know
what they might be connected to".

I/O errors on "ls" of certain fragmented files found by at least two
people running Windows XP.

- Mucking with the original skb pointers with push/pull around
  the packet quoting was wrong, muching with these pointers could
  cause problems with others using the SKB.

  It was also buggy, it only handled the case where skb->nh.raw was
  ahead of or equal to skb->data

- The fix is to record skb->nh.raw - skb->data and use this as
  a base offset in calls to skb_copy_and_csum_bits().  This is
  what the pre-IPSEC code did.

This fixes IPV6 oopses and packet corruption on 64-bit platforms
when sending UDP port unreachable ICMP messages.

Reported and analyzed by Jan Oravec (jan.oravec@6com.sk)

	signal handler.  Otherwise, a restarted system call that gets
	interrupted before the restart has taken effect by _another_
	signal will potentially restart the wrong system call.

Otherwise, a restarted system call that gets interrupted before
the restart has taken effect by _another_ signal will potentially
restart the wrong system call.

It would oops on any machines that had an ALI northbridge but
didn't have the exact ISA bridge we expected.

The problem with clock_nanosleep() restarting was that the address of
the users return timespec was being saved at the wrong place.  In needs
to be saved in the sys call interface code rather than the
do_clock_nanosleep().  My original tests were a bit weak as they only
did one signal rather than two or more which were required to break it. 

The attached patch fixes the problem.

I also added a few comments about how restart works, and added my name
to the MAINTAINERS list.

Without this patch, SN machines which have nodes that contain memory only (no
CPUs will hang.

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

The bug is probably impossible to trigger on x86, due to its
fairly strong coherency model (the SMP-safe bitops end up being
memory barriers etc), but other architectures - notably ppc64 -
can apparently trigger a race whereby the signal sender doesn't
wake up the target because it doesn't notice that it has gone to
sleep.

The optimization also optimizes only what appears to be the
uncommon case, where the signal happens for an already-running
process.