into ppc970.osdl.org:/home/torvalds/v2.6/linux

into intel.com:/home/lenb/src/26-latest-dev

Now "max_cstate=" instead of "acpi_cstate_limit="
Delete redundant static cstate flags .c2 and .c3

http://bugme.osdl.org/show_bug.cgi?id=3549
   
   For static processor driver, boot cmdline:
   processor.max_cstate=2
   
   For processor module, /etc/modprobe.conf:
   options processor max_cstate=2
   or
   # modprobe processor max_cstate=2
   
   From kernel or kernel module:
   #include <linux/acpi.h>
   acpi_set_cstate_limit(2);
 
Suggested-by: Pavel Machek
Signed-off-by: Len Brown <len.brown@intel.com>

into intel.com:/home/lenb/src/26-latest-dev

http://bugzilla.kernel.org/show_bug.cgi?id=3643Signed-off-by: Alexey Y Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Len Brown <len.brown@intel.com>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into intel.com:/home/lenb/src/26-latest-dev

into intel.com:/home/lenb/src/26-latest-dev

Signed-off-by: Len Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=3669Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=3762Signed-off-by: Len Brown <len.brown@intel.com>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>

so call it ioapic_renumber_irq().

A note to google:
GSI is a Global System Interrupt -- a flat, linear, global IRQ number.

Suggested-by: Linus Torvalds
Signed-off-by: Len Brown <len.brown@intel.com>

Alternate workaround for blocking usage of select() by UDP applications.
The problem is Linux optimizes the UDP receive checksum path so that checksum
validation is not performed until the application read. This is a performance win
but can cause applications that do select with blocking file descriptors to get false
positives if the received message has a checksum error.
There is a long running thread about this on LKML.

This patch makes these applications work, but keeps the one-pass performance gain
for those applications smart enough to use non-blocking file descriptors with
select/poll. There is still a possibility to get a false positive if application does
select on non-blocking fd then makes it blocking before doing the receive, but that
is unlikely.

Tested by injecting bad packets with SOCK_RAW.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into intel.com:/home/lenb/src/26-latest-dev

into intel.com:/home/lenb/src/26-latest-dev

Signed-off-by: Len Brown <len.brown@intel.com>

into kroah.com:/home/greg/linux/BK/i2c-2.6

Check netlink socket being non NULL in error return path.
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

into kroah.com:/home/greg/linux/BK/pci-2.6

into kroah.com:/home/greg/linux/BK/usb-2.6

While looking at the SCM passing code in net/core/scm.c I noticed that there's
a 32-bit compat implementation of scm_detach_fds()'s called 
scm_detach_fds_compat() living in net/compat.c.  While these two functions
are mostly the same the latter does not include the call to the
security_file_receive() hook which is almost certainly a bug.
Signed-off-by: Mitchell Blank Jr <mitch@sfgoth.com>
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Scott Feldman <sfeldma@pobox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Asit Mallick pointed out that the ia64 idle loop needs a
"hint @pause" instruction in the cases where we don't
actually halt the cpu.
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>

In the absence of an HCDP, we used to assume there were legacy COM ports
at 0x3f8 and 0x2f8, but I recently removed that assumption.
 
"console=ttyS0" still works (assuming you have CONFIG_SERIAL_8250_ACPI
turned on so you can find the ttyS0 device), but the console doesn't
start working until the serial driver initializes.  If you need an
early console and you know where it lives, something like
"console=uart,io,0x3f8" will start working very early.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into iguana.be:/home/wim/BitKeeper/projects/linux-2.6-watchdog

This is a debug entry that isn't of much use to the generic user or on a
production system. Additionally it can also easy overflow the sysfs
PAGE_SIZE limitation, if you have many processes doing io. So kill the
entry.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

If we're waiting on a futex and we are woken up, it's either because
someone did FUTEX_WAKE, we timed out, or have been signalled.  However, the
WARN_ON(!signal_pending(current)) test is overzealous: with threads (a
common use of futexes), we share the signal handler and the other
thread might get to the signal before us.  In addition, exit_notify()
can do a recalc_sigpending_tsk() on us, which will then clear our
TIF_SIGPENDING bit, making signal_pending(current) return false.

Returning EINTR is a little strange in this case, since this thread
hasn't handled a signal.  However, with threads it's the best we can
do: there's always a race where another thread could have been the
actual one to handle the signal.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Patrick Caulfield <patrick@tykepenguin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>