http://bugzilla.kernel.org/show_bug.cgi?id=1390

http://bugzilla.kernel.org/show_bug.cgi?id=1177

into intel.com:/home/lenb/bk/linux-acpi-test-2.6.0

Russell King reports:
 "With previous kernels, the nodes are added to the list in reverse order,
  so architecture code knew we had to add the highest PFN first and the
  lowest PFN node last.

  Unfortunately, init_bootmem_core() now sorts the nodes according to
  their start pfn. This active sorting broke ARM discontig memory support."

Andrew Morton chimes in:
 "It looks to be bogus on ia64 as well, for which the patch was written"

Yep, I think it is bogus.  There's only one caller on ia64 that would be
affected--swiotlb_init(), and afaik multi-node systems won't be using
that code (except maybe NEC?), so even if the pgdat list is out of order
we should be ok.  If not I'll fix the ia64 discontig code.

kernel_thread() returns the pid if successful, so the test for
errors is to test for _negative_ values.

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

It is using local variable `i' in both the inner and outer loop.

Need to bring the for loop outside the loop.  Otherwise we need to reset the
setup_frame to tp->setup_frame after every loop.  You do not need to set the
setup_frm for every mc address, we can set once after the complete has_table
is ready.

Always disable system call restart when returning from a signal
handler.  This follows the new x86 behaviour.

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.