1) Fix the comments for the migration_thread.  A while back Ingo
   agreed they were exactly wrong, IIRC. 8).

2) Changed spin_lock_irqsave to spin_lock_irq, since it's in a
   kernel thread.

3) Don't repeat if the task has moved off the original CPU, just finish.
   This is because we are simply trying to push the task off this CPU:
   if it's already moved, great.  Currently we might theoretically move
   a task which is actually running on another CPU, which is v. bad.

4) Replace the __ffs(p->cpus_allowed) with any_online_cpu(), since
   that's what it's for, and __ffs() can give the wrong answer, eg. if
   there's no CPU 0.

5) Move the core functionality of migrate_task into a separate function,
   move_task_away, which I want for the hotplug CPU patch.

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

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

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

It was broken on at least ppc32 & sparc32, and the debugging it
offered wasn't worth it any more anyway.

local_irq_save() is called at the beginning of speedstep_detect_speeds,
but local_irq_restore() is not called on I/O errors.

Intel seems to have changed their mind, and now document the detection
process for speedstep-enabled Pentium III Coppermines:

	http://www.intel.com/support/processors/sb/cs-003779-prd24.htm

Here is a patch.

I kept the setup parameter, but it might be removed now?

This patch moves the old board-specific SH code

This gets the toplevel arch/sh stuff in sync with the current SH 2.5
tree.

This bit is left from the zlib changes.  According to Paul, the zlib
bug is already caught in userspace pppd, but not in the kernel ppp
code.  With this patch, there is one potential hickup less in ppp.

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

into samba.org:/scratch/anton/linux-2.5_ppc64

into samba.org:/scratch/anton/tmp3

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

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

into samba.org:/home/anton/ppc64/for-linus-ppc64

into samba.org:/scratch/anton/tmp3

 OHCI1394: Merge CONFIG_PPC_ALL changes.
 DV1394  : Fix broken endian conversions.
 ETH1394 : Fix oopses due to non-linear sk_buff's.

Spotted by Dominik.

scsi_add_lun doesn't set sdp->devfs_name before calling
scsi_register_device().  Since scsi_register_device calls down to things
like sd_probe, which do try to use sdp->devfs_name, things fail.

Just an easy change, moving the sdp->devfs_name creation before calling
scsi_register_device().

This brings the x86-64 port uptodate.  Only architecture specific
changes.

The biggest change is the forward port of the 2.4 timing code with full
HPET support.  This should improve timing stability on some Opteron
boxes considerably.

Also add the optimized low level functions from 2.4 (clear_page,
copy_page, memcpy, csum_copy etc.) They were supposed to be merged
earlier, but got dropped due to some SNAFU.  Especially the clear_page
changes should improve performance considerably, because the old version
used write combining writes which put all the new process data out of
cache.  New version serves cache hot.

Also some other bugfixes.

Full changelog:
- Re-add some lost patches: improved copy_page, clear_page, memset, memcpy,
  csum_copy from 2.4.
- New timing code from 2.4 (Bryan O'Sullivan, John Stultz, Vojtech Pavlik)
- Use correct MSR to write northbridge MCE configuration
- Fix and reenable simics check in APIC timer calibration
- Check if BIOS enabled APIC and don't use APIC mode if not.
- Remove some obsolete code in APIC handling.
- Fix potential races in the IOMMU code.
- Don't print backtrace twice on oops.
- Fix compilation of swsuspend (Pavel Machek)
- Add oops locking to kernel page faults.
- Use prefetcht0 for C level kernel prefetches.

Patch from Jakub Jelínek <jakub@redhat.com>

Make sure setfsuid/setfsgid return values are right.  Before
include/linux/security.h was added, setfsuid/setfsgid always returned
old_fsuid, no matter if the fsuid was actually changed or not.

With the default security ops it seems to do the same, because both
security_task_setuid and security_task_post_setuid return 0, but these
are hooks which seem to return 0 on success, -errno on failure, so if
some non-default security hook is installed and ever returns -errno in
setfsuid/setfsgid, -errno will be returned from the syscall instead of
the expected old_fsuid.  This makes it hard to distinguish uids
0xfffff001 ..  0xffffffff from errors of security hooks.