into hostme.bitkeeper.com:/repos/c/cifs/linux-2.5cifs

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

into stevef95.austin.ibm.com:/home/stevef/bk/linux-2.5cifs

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.

into hostme.bitkeeper.com:/repos/c/cifs/linux-2.5cifs

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 hostme.bitkeeper.com:/repos/c/cifs/linux-2.5cifs

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

finish off move from reopening all files on reconnection (which takes too long under heavy stress) to reopen file as needed after reconnection to server.

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.