into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

updates the _PPC handling. It is handled as a CPUfreq
policy notifier which adjusts the maximum CPU speed
according to the current platform limit.

from Dominik Brodowski

The acpi cpufreq driver includes a test at startup which detects whether
ACPI P-States are supported on any CPU, and whether transitions work.
However, this test is faulty: it is only run _after_ the acpi driver is
registered, causing race situations. Also, it doesn't save anything _as_ the
driver is already registered. So, it can safely be removed.

	from Dominik Brodowski

The current algorithm used by Linux ACPI for passive thermal management has
two shortcomings:

- if increasing the CPU processing power as a thermal situation goes away,
  throttling states are decreased later than performance states. This is
  not wise -- it should be the opposite ordering of going "up".

- only if the ACPI CPUfreq driver is used, performance states are used.
  A generalized approach would offer passive cooling even if the ACPI
  P-States cpufreq driver cannot be used (faulty BIOS, FixedHW access, etc.)

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

from Jes Sorensen

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

        from ia64 via Alex Williamson

	from Jes Sorensen

	from Jes Sorensen

  from Bjorn Helgaas

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

The purpose of this release is primarily to update the copyright years
in each module, thus causing a huge number of diffs.  There are a few
small functional changes, however.

Improved error messages when there is a problem finding one or more of
the required base ACPI tables

Reintroduced the definition of APIC_HEADER in actbl.h

Changed definition of MADT_ADDRESS_OVERRIDE to 64 bits (actbl.h)

Removed extraneous reference to NewObj in dsmthdat.c

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

	http://bugzilla.kernel.org/show_bug.cgi?id=1349
	from David Shaohua Li and Venatesh Pallipadi

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

into lips.borg.umn.edu:/export/music/bkroot/xfs-linux-2.6

We must not mark the process TASK_STOPPED early, because
that might allow a signal to wake it up before we actually
got to the "wake_up_forked_process()" state. Total confusion
would happen.

Make wake_up_forked_process() verify the new world order.

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

Spotted by Andreas Henriksson <andreas@scream.fjortis.info>

Also consolidate a bunch of convoluted if's into a single
"is this an r200 or r300" function.

From: Anton Blanchard <anton@samba.org>

For a laugh we moved the BSS and our world exploded. Turns out we zero
from __bss_start to _end. Add __bss_stop to our section definitions so
we can use it instead.

From: Anton Blanchard <anton@samba.org>

Linas Vepstas has audited the ppc64 proc code and found a number of issues.

This fixes loading of modules compiled with debugging on
some platforms.

From Rusty.

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

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

Get off the drugs, Linus.

constant expression properly.

into nuts.ninka.net:/disk1/davem/BK/net-2.6

into nuts.ninka.net:/disk1/davem/BK/sparc-2.6

From: Christoph Hellwig <hch@lst.de>

JFS currently clears i_sb in some error pathes which can make the
core kernel OOPS because it may never be NULL.  Noticed because some
IBM people try to "fix" the core kernel for it now..

From: Ingo Molnar <mingo@elte.hu>,

Voyager is getting odd deadlocks due to the taking of xtime_lock() in
sched_clock()->get_jiffies_64().

I had this patch queued up to fix a different deadlock, which occurs when we
relax the requirement that TSC's be synchronised across CPUs.  But it will
fix James' deadlock too.

From: Michael Hunold <hunold@convergence.de>

- move around sp887x firmware file entry to be close to sp887x selection

- fix a bunch of filenames to point to /usr/lib/hotplug/firmware/ rather
  then /etc/dvb

- fix the av7110 firmware config entry for "make allyesconfig"

From: Dave Kleikamp <shaggy@austin.ibm.com>

After Jose debugged the problem down to the routine jfs_get_parent, we
were able to find the problem.  I believe it only affects users of
NFS-exported JFS file systems on big-endian hardware.

The problem was a missing le32_to_cpu macro.  The patch also fixes a
return code to be more consistent other implementations of get_parent.