linux-stable.git/arch, branch linux-2.6.35.y Linux kernel stable tree x86, mtrr: lock stop machine during MTRR rendezvous sequence 2011-08-01T20:55:04+00:00 Suresh Siddha suresh.b.siddha@intel.com 2011-06-23T18:19:26+00:00 22950d253543188b3e6488a0dbd5cad9eb71bef7 [ upstream commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 ] MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially happen in parallel with another system wide rendezvous using stop_machine(). This can lead to deadlock (The order in which works are queued can be different on different cpu's. Some cpu's will be running the first rendezvous handler and others will be running the second rendezvous handler. Each set waiting for the other set to join for the system wide rendezvous, leading to a deadlock). MTRR rendezvous sequence is not implemented using stop_machine() as this gets called both from the process context aswell as the cpu online paths (where the cpu has not come online and the interrupts are disabled etc). stop_machine() works with only online cpus. For now, take the stop_machine mutex in the MTRR rendezvous sequence that gets called from an online cpu (here we are in the process context and can potentially sleep while taking the mutex). And the MTRR rendezvous that gets triggered during cpu online doesn't need to take this stop_machine lock (as the stop_machine() already ensures that there is no cpu hotplug going on in parallel by doing get_online_cpus()) TBD: Pursue a cleaner solution of extending the stop_machine() infrastructure to handle the case where the calling cpu is still not online and use this for MTRR rendezvous sequence. fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008 Reported-by: Vadim Kotelnikov <vadimuzzz@inbox.ru> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com Cc: stable@kernel.org # 2.6.35+, backport a week or two after this gets more testing in mainline Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> 
[ upstream commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 ]

MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
happen in parallel with another system wide rendezvous using
stop_machine(). This can lead to deadlock (The order in which
works are queued can be different on different cpu's. Some cpu's
will be running the first rendezvous handler and others will be running
the second rendezvous handler. Each set waiting for the other set to join
for the system wide rendezvous, leading to a deadlock).

MTRR rendezvous sequence is not implemented using stop_machine() as this
gets called both from the process context aswell as the cpu online paths
(where the cpu has not come online and the interrupts are disabled etc).
stop_machine() works with only online cpus.

For now, take the stop_machine mutex in the MTRR rendezvous sequence that
gets called from an online cpu (here we are in the process context
and can potentially sleep while taking the mutex). And the MTRR rendezvous
that gets triggered during cpu online doesn't need to take this stop_machine
lock (as the stop_machine() already ensures that there is no cpu hotplug
going on in parallel by doing get_online_cpus())

    TBD: Pursue a cleaner solution of extending the stop_machine()
         infrastructure to handle the case where the calling cpu is
         still not online and use this for MTRR rendezvous sequence.

fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008

Reported-by: Vadim Kotelnikov <vadimuzzz@inbox.ru>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
Cc: stable@kernel.org # 2.6.35+, backport a week or two after this gets more testing in mainline
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
ARM: 6989/1: perf: do not start the PMU when no events are 2011-08-01T20:55:04+00:00 Will Deacon will.deacon@arm.com 2011-07-01T13:38:12+00:00 64779cb190a6ba7a03b658cd0584cef74fb9c208 [ upstream commit f4f38430c94c38187db73a2cf3892cc8b12a2713 ] present armpmu_enable can be called in situations where no events are present (for example, from the event rotation tick after a profiled task has exited). In this case, we currently start the PMU anyway which may leave it active inevitably without any events being monitored. This patch adds a simple check to the enabling code so that we avoid starting the PMU when no events are present. Cc: <stable@kernel.org> Reported-by: Ashwin Chaugle <ashwinc@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andi Kleen <ak@linux.intel.com> 
[ upstream commit f4f38430c94c38187db73a2cf3892cc8b12a2713 ]
 present

armpmu_enable can be called in situations where no events are present
(for example, from the event rotation tick after a profiled task has
exited). In this case, we currently start the PMU anyway which may
leave it active inevitably without any events being monitored.

This patch adds a simple check to the enabling code so that we avoid
starting the PMU when no events are present.

Cc: <stable@kernel.org>
Reported-by: Ashwin Chaugle <ashwinc@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
iommu/amd: Don't use MSI address range for DMA addresses 2011-08-01T20:55:03+00:00 Joerg Roedel joerg.roedel@amd.com 2011-07-06T15:14:44+00:00 08b751d515c0f2745b3e3c6bc7ca5a3f2747fe28 [ upstream commit 17f5b569e09cfa3488eaa663cbf9feada2e789f5 ] Reserve the MSI address range in the address allocator so that MSI addresses are not handed out as dma handles. Cc: stable@kernel.org Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> 
[ upstream commit 17f5b569e09cfa3488eaa663cbf9feada2e789f5 ]

Reserve the MSI address range in the address allocator so
that MSI addresses are not handed out as dma handles.

Cc: stable@kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
ARM: pxa: fix PGSR register address calculation 2011-08-01T20:55:03+00:00 Paul Parsons lost.distance@yahoo.com 2011-05-08T01:54:33+00:00 dd4e598f13dd3e9c871034dd22ace5977fa4c37a [ upstream commit beb0c9b056b1c23d2029b46a425362e9ccbeba01 ] The file mfp-pxa2xx.c defines a macro, PGSR(), which translates a gpio bank number to a PGSR register address. The function pxa2xx_mfp_suspend() erroneously passed in a gpio number instead of a gpio bank number. Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Cc: stable@kernel.org Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> 
[ upstream commit beb0c9b056b1c23d2029b46a425362e9ccbeba01 ]

The file mfp-pxa2xx.c defines a macro, PGSR(), which translates a gpio
bank number to a PGSR register address. The function pxa2xx_mfp_suspend()
erroneously passed in a gpio number instead of a gpio bank number.

Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
Cc: stable@kernel.org
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
ARM: pxa/cm-x300: fix V3020 RTC functionality 2011-08-01T20:55:02+00:00 Igor Grinberg grinberg@compulab.co.il 2011-05-09T11:41:46+00:00 16b9eeed2a368c85e42c680d7a25fee50c3ad828 [ upstream commit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 ] While in sleep mode the CS# and other V3020 RTC GPIOs must be driven high, otherwise V3020 RTC fails to keep the right time in sleep mode. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> Cc: stable@kernel.org Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> 
[ upstream commit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 ]

While in sleep mode the CS# and other V3020 RTC GPIOs must be driven
high, otherwise V3020 RTC fails to keep the right time in sleep mode.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Cc: stable@kernel.org
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS 2011-08-01T20:55:02+00:00 Len Brown len.brown@intel.com 2011-07-14T04:53:24+00:00 fb20c39467bbc0610039152704b8500f3539d666 [ upstream commit abe48b108247e9b90b4c6739662a2e5c765ed114 ] Since 2.6.36 (23016bf0d25), Linux prints the existence of "epb" in /proc/cpuinfo, Since 2.6.38 (d5532ee7b40), the x86_energy_perf_policy(8) utility has been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS. However, the typical BIOS fails to initialize the MSR, presumably because this is handled by high-volume shrink-wrap operating systems... Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8). As a result, WSM-EP, SNB, and later hardware from Intel will run in its default hardware power-on state (performance), which assumes that users care for performance at all costs and not for energy efficiency. While that is fine for performance benchmarks, the hardware's intended default operating point is "normal" mode... Initialize the MSR to the "normal" by default during kernel boot. x86_energy_perf_policy(8) is available to change the default after boot, should the user have a different preference. Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980 Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: <stable@kernel.org> 
[ upstream commit abe48b108247e9b90b4c6739662a2e5c765ed114 ]

Since 2.6.36 (23016bf0d25), Linux prints the existence of "epb" in /proc/cpuinfo,
Since 2.6.38 (d5532ee7b40), the x86_energy_perf_policy(8) utility has
been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS.

However, the typical BIOS fails to initialize the MSR, presumably
because this is handled by high-volume shrink-wrap operating systems...

Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8).
As a result, WSM-EP, SNB, and later hardware from Intel will run in its
default hardware power-on state (performance), which assumes that users
care for performance at all costs and not for energy efficiency.
While that is fine for performance benchmarks, the hardware's intended default
operating point is "normal" mode...

Initialize the MSR to the "normal" by default during kernel boot.

x86_energy_perf_policy(8) is available to change the default after boot,
should the user have a different preference.

Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@kernel.org>
x86: Look for IA32_ENERGY_PERF_BIAS support 2011-08-01T20:55:02+00:00 Venkatesh Pallipadi venki@google.com 2010-06-04T03:22:28+00:00 ec43b20a4e00cccdf8705b60e3ddef95349fff6b [ upstream commit 23016bf0 ] The new IA32_ENERGY_PERF_BIAS MSR allows system software to give hardware a hint whether OS policy favors more power saving, or more performance. This allows the OS to have some influence on internal hardware power/performance tradeoffs where the OS has previously had no influence. The support for this feature is indicated by CPUID.06H.ECX.bit3, as documented in the Intel Architectures Software Developer's Manual. This patch discovers support of this feature and displays it as "epb" in /proc/cpuinfo. Signed-off-by: Venkatesh Pallipadi <venki@google.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> LKML-Reference: <alpine.LFD.2.00.1006032310160.6669@localhost.localdomain> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> 
[ upstream commit 23016bf0 ]

The new IA32_ENERGY_PERF_BIAS MSR allows system software to give
hardware a hint whether OS policy favors more power saving,
or more performance.  This allows the OS to have some influence
on internal hardware power/performance tradeoffs where the OS
has previously had no influence.

The support for this feature is indicated by CPUID.06H.ECX.bit3,
as documented in the Intel Architectures Software Developer's Manual.

This patch discovers support of this feature and displays it
as "epb" in /proc/cpuinfo.

Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
LKML-Reference: <alpine.LFD.2.00.1006032310160.6669@localhost.localdomain>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
powerpc/kdump: Fix timeout in crash_kexec_wait_realmode 2011-08-01T20:55:01+00:00 Michael Neuling mikey@neuling.org 2011-07-04T20:40:10+00:00 5d9a9233b7fe68dc51ee41a4d35798cfee682444 [ upstream commit 63f21a56f1cc0b800a4c00349c59448f82473d19 ] The existing code it pretty ugly. How about we clean it up even more like this? From: Anton Blanchard <anton@samba.org> We check for timeout expiry in the outer loop, but we also need to check it in the inner loop or we can lock up forever waiting for a CPU to hit real mode. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Cc: <stable@kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andi Kleen <ak@linux.intel.com> 
[ upstream commit 63f21a56f1cc0b800a4c00349c59448f82473d19 ]

The existing code it pretty ugly.  How about we clean it up even more
like this?

From: Anton Blanchard <anton@samba.org>

We check for timeout expiry in the outer loop, but we also need to
check it in the inner loop or we can lock up forever waiting for a
CPU to hit real mode.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@kernel.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
powerpc/pseries/hvconsole: Fix dropped console output 2011-08-01T20:55:01+00:00 Anton Blanchard anton@samba.org 2011-07-05T21:51:36+00:00 bf7b6215667dd484edf6aa03b764927afc6a6c76 [ upstream commit 51d33021425e1f905beb4208823146f2fb6517da ] Return -EAGAIN when we get H_BUSY back from the hypervisor. This makes the hvc console driver retry, avoiding dropped printks. Signed-off-by: Anton Blanchard <anton@samba.org> Cc: <stable@kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andi Kleen <ak@linux.intel.com> 
[ upstream commit 51d33021425e1f905beb4208823146f2fb6517da ]

Return -EAGAIN when we get H_BUSY back from the hypervisor. This
makes the hvc console driver retry, avoiding dropped printks.

Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
davinci: DM365 EVM: fix video input mux bits 2011-08-01T20:55:01+00:00 Jon Povey jon.povey@racelogic.co.uk 2011-07-19T03:30:11+00:00 5671ba64a10a8150de56a8131cf0084381ca79ba [ upstream commit 9daedd833a38edd90cf7baa1b1fcf61c3a0721e3 ] Video input mux settings for tvp7002 and imager inputs were swapped. Comment was correct. Tested on EVM with tvp7002 input. Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk> Acked-by: Manjunath Hadli <manjunath.hadli@ti.com> Cc: stable@kernel.org Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> 
[ upstream commit 9daedd833a38edd90cf7baa1b1fcf61c3a0721e3 ]

Video input mux settings for tvp7002 and imager inputs were swapped.
Comment was correct.

Tested on EVM with tvp7002 input.

Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Acked-by: Manjunath Hadli <manjunath.hadli@ti.com>
Cc: stable@kernel.org
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>