linux-toradex.git/arch/x86/kernel/cpu, branch v3.0.22

perf/x86: Fix PEBS instruction unwind

2011-12-09T16:52:44+00:00

commit 57d1c0c03c6b48b2b96870d831b9ce6b917f53ac upstream.

Masami spotted that we always try to decode the instruction stream as
64bit instructions when running a 64bit kernel, this doesn't work for
ia32-compat proglets.

Use TIF_IA32 to detect if we need to use the 32bit instruction
decoder.

Reported-by: Masami Hiramatsu 
Signed-off-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf, x86: Add model 45 SandyBridge support

2011-10-03T18:40:49+00:00

commit a34668f6beb4ab01e07683276d6a24bab6c175e0 upstream.

Add support to Romely-EP SandyBridge.

Signed-off-by: Youquan Song 
Signed-off-by: Anhua Xu 
Signed-off-by: Lin Ming 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1312264895-2010-1-git-send-email-youquan.song@intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, perf: Check that current->mm is alive before getting user callchain

2011-10-03T18:40:09+00:00

commit 20afc60f892d285fde179ead4b24e6a7938c2f1b upstream.

An event may occur when an mm is already released.

I added an event in dequeue_entity() and caught a panic with
the following backtrace:

[  434.421110] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
[  434.421258] IP: [] __get_user_pages_fast+0x9c/0x120
...
[  434.421258] Call Trace:
[  434.421258]  [] copy_from_user_nmi+0x51/0xf0
[  434.421258]  [] ? sched_clock_local+0x25/0x90
[  434.421258]  [] perf_callchain_user+0x128/0x170
[  434.421258]  [] ? __perf_event_header__init_id+0xed/0x100
[  434.421258]  [] perf_prepare_sample+0x200/0x280
[  434.421258]  [] __perf_event_overflow+0x1b8/0x290
[  434.421258]  [] ? tg_shares_up+0x0/0x670
[  434.421258]  [] ? walk_tg_tree+0x6a/0xb0
[  434.421258]  [] perf_swevent_overflow+0xc4/0xf0
[  434.421258]  [] do_perf_sw_event+0x1e0/0x250
[  434.421258]  [] perf_tp_event+0x44/0x70
[  434.421258]  [] ftrace_profile_sched_block+0xdf/0x110
[  434.421258]  [] dequeue_entity+0x2ad/0x2d0
[  434.421258]  [] dequeue_task_fair+0x1c/0x60
[  434.421258]  [] dequeue_task+0x9a/0xb0
[  434.421258]  [] deactivate_task+0x42/0xe0
[  434.421258]  [] thread_return+0x191/0x808
[  434.421258]  [] ? switch_task_namespaces+0x24/0x60
[  434.421258]  [] do_exit+0x464/0x910
[  434.421258]  [] do_group_exit+0x58/0xd0
[  434.421258]  [] sys_exit_group+0x17/0x20
[  434.421258]  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Andrey Vagin 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1314693156-24131-1-git-send-email-avagin@openvz.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, mtrr: lock stop machine during MTRR rendezvous sequence

2011-08-29T20:29:08+00:00

commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 upstream.

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 
Signed-off-by: Suresh Siddha 
Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message

2011-08-29T20:29:07+00:00

commit 17edf2d79f1ea6dfdb4c444801d928953b9f98d6 upstream.

Fix the printk_once() so that it actually prints (didn't print before
due to a stray comma.)

[ hpa: changed to an incremental patch and adjusted the description
  accordingly. ]

Signed-off-by: Len Brown 
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107151732480.18606@x980
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS

2011-08-05T04:58:35+00:00

commit abe48b108247e9b90b4c6739662a2e5c765ed114 upstream.

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 
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980
Acked-by: Rafael J. Wysocki 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6

2011-05-29T18:18:09+00:00

* 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6:
  x86 idle: deprecate mwait_idle() and "idle=mwait" cmdline param
  x86 idle: deprecate "no-hlt" cmdline param
  x86 idle APM: deprecate CONFIG_APM_CPU_IDLE
  x86 idle floppy: deprecate disable_hlt()
  x86 idle: EXPORT_SYMBOL(default_idle, pm_idle) only when APM demands it
  x86 idle: clarify AMD erratum 400 workaround
  idle governor: Avoid lock acquisition to read pm_qos before entering idle
  cpuidle: menu: fixed wrapping timers at 4.294 seconds

x86 idle: deprecate "no-hlt" cmdline param

2011-05-29T07:39:16+00:00

We'd rather that modern machines not check if HLT works on
every entry into idle, for the benefit of machines that had
marginal electricals 15-years ago.  If those machines are still running
the upstream kernel, they can use "idle=poll".  The only difference
will be that they'll now invoke HLT in machine_hlt().

cc: x86@kernel.org # .39.x
Signed-off-by: Len Brown

x86 idle: clarify AMD erratum 400 workaround

2011-05-29T07:38:57+00:00

The workaround for AMD erratum 400 uses the term "c1e" falsely suggesting:
1. Intel C1E is somehow involved
2. All AMD processors with C1E are involved

Use the string "amd_c1e" instead of simply "c1e" to clarify that
this workaround is specific to AMD's version of C1E.
Use the string "e400" to clarify that the workaround is specific
to AMD processors with Erratum 400.

This patch is text-substitution only, with no functional change.

cc: x86@kernel.org
Acked-by: Borislav Petkov 
Signed-off-by: Len Brown

x86, amd: Do not enable ARAT feature on AMD processors below family 0x12

2011-05-26T17:38:30+00:00

Commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 added support for
ARAT (Always Running APIC timer) on AMD processors that are not
affected by erratum 400. This erratum is present on certain processor
families and prevents APIC timer from waking up the CPU when it
is in a deep C state, including C1E state.

Determining whether a processor is affected by this erratum may
have some corner cases and handling these cases is somewhat
complicated. In the interest of simplicity we won't claim ARAT
support on processor families below 0x12 and will go back to
broadcasting timer when going idle.

Signed-off-by: Boris Ostrovsky 
Link: http://lkml.kernel.org/r/1306423192-19774-1-git-send-email-ostr@amd64.org
Tested-by: Boris Petkov 
Cc: Hans Rosenfeld 
Cc: Andreas Herrmann 
Cc: Chuck Ebbert 
Cc: stable@kernel.org # 32.x, 38.x, 39.x
Signed-off-by: H. Peter Anvin