Skip to content
  1. Jul 06, 2015
  3. Jul 04, 2015
  5. Jul 03, 2015
    • Hanjun Guo's avatar
      ARM64 / SMP: Switch pr_err() to pr_debug() for disabled GICC entry · f9058929
      Hanjun Guo authored 
      

It is normal that firmware presents GICC entry or entries (processors)
with disabled flag in ACPI MADT, taking a system of 16 cpus for example,
ACPI firmware may present 8 ebabled first with another 8 cpus disabled
in MADT, the disabled cpus can be hot-added later.

Firmware may also present more cpus than the hardware actually has, but
disabled the unused ones, and easily enable it when the hardware has such
cpus to make the firmware code scalable.

So that's not an error for disabled cpus in MADT, we can switch pr_err()
to pr_debug() to make the boot a little quieter by default.

Since hwid for disabled cpus often are invalid, and we check invalid hwid
first in the code, for use case that hot add cpus later will be filtered
out and will not be counted in possible cups, so move this check before
the hwid one to prepare the code to count for disabeld cpus when cpu
hot-plug is introduced.

Signed-off-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: default avatarAl Stone <ahs3@redhat.com>
Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f9058929
    • Tony Luck's avatar
      [IA64] Drop debug test/printk that some special pages are marked reserved · 43c518d1
      Tony Luck authored 
      In commit 92923ca3 "mm: meminit: only set page reserved in the memblock region"
we dropped setting the reserved bits for all pages. This results in some warnings
on ia64:

put_kernel_page: page at 0xe000000005588000 not in reserved memory
put_kernel_page: page at 0xe000000005588000 not in reserved memory
put_kernel_page: page at 0xe000000005580000 not in reserved memory
put_kernel_page: page at 0xe000000005580000 not in reserved memory
put_kernel_page: page at 0xe000000005580000 not in reserved memory
put_kernel_page: page at 0xe000000005580000 not in reserved memory

the two different pages match up with two objects from the loaded kernel
that get mapped by arch/ia64/mm/init.c:setup_gate()

a000000101588000 D __start_gate_section
a000000101580000 D empty_zero_page

In a discussion with Mel Gorman:
  http://lkml.kernel.org/r/20150526102219.GB13750%40suse.de


he suggested that while the preferred approach might be to
set the reserved bit for these pages, it would also be OK
to just drop the test:
   "as it's a debugging check that is ia-64 specific"

After hunting around a bit and failin to find a good place to mark these
pages as reserved - I decided to just delete the test.

Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      43c518d1
    • Jisheng Zhang's avatar
      arm64: cpuidle: add __init section marker to arm_cpuidle_init · ea389daa
      Jisheng Zhang authored 
      

It is not needed after booting, this patch moves the arm_cpuidle_init()
function to the __init section.

Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      ea389daa
  7. Jul 02, 2015
  9. Jul 01, 2015
  11. Jun 30, 2015
    • Peter Zijlstra's avatar
      perf/x86: Fix 'active_events' imbalance · 93472aff
      Peter Zijlstra authored 
      

Commit 1b7b938f ("perf/x86/intel: Fix PMI handling for Intel PT") conditionally
increments active_events in x86_add_exclusive() but unconditionally decrements in
x86_del_exclusive().

These extra decrements can lead to the situation where
active_events is zero and thus the PMI handler is 'disabled'
while we have active events on the PMU generating PMIs.

This leads to a truckload of:

  Uhhuh. NMI received for unknown reason 21 on CPU 28.
  Do you have a strange power saving mode enabled?
  Dazed and confused, but trying to continue

messages and generally messes up perf.

Remove the condition on the increment, double increment balanced
by a double decrement is perfectly fine.

Restructure the code a little bit to make the unconditional inc
a bit more natural.

Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: alexander.shishkin@linux.intel.com
Cc: brgerst@gmail.com
Cc: dvlasenk@redhat.com
Cc: luto@amacapital.net
Cc: oleg@redhat.com
Fixes: 1b7b938f ("perf/x86/intel: Fix PMI handling for Intel PT")
Link: http://lkml.kernel.org/r/20150624144750.GJ18673@twins.programming.kicks-ass.net


Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      93472aff
    • Ingo Molnar's avatar
      x86/fpu: Fix FPU related boot regression when CPUID masking BIOS feature is enabled · db52ef74
      Ingo Molnar authored 
      

Mike Galbraith reported:

  " My i7-4790 box is having one hell of a time with this merge
    window, dead in the water.

    BIOS setting "Limit CPUID Maximum" upsets new fpu code
    mightily. "

It turns out that Linux does a double workaround here, as per:

  066941bd ("x86: unmask CPUID levels on Intel CPUs")

it undoes the BIOS workaround - but as a side effect the CPUID
state is not completely constant during early init anymore,
and the new FPU init code did not take this into account.

So what happened is that the xstate init code did not have full
CPUID available, which broke subsequent attempts to use xstate
features.

Fix this by ordering the early FPU init code to after we've
stabilized the CPUID state.

Reported-bisected-and-tested-by: default avatarMike Galbraith <umgwanakikbuti@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150627082514.GA10894@gmail.com


Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      db52ef74
    • qipeng.zha's avatar
      intel_pmc_ipc: Add Intel Apollo Lake PMC IPC driver · 0a8b8353
      qipeng.zha authored 
      

This driver provides support for PMC control on Apollo Lake platforms.
The PMC is an ARC processor which defines some IPC commands for
communication with other entities in the CPU.

Signed-off-by: default avatarqipeng.zha <qipeng.zha@intel.com>
[fengguang.wu@intel.com: Fix Sparse and Cocinelle warnings]
Signed-off-by: default avatarFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      0a8b8353
  13. Jun 29, 2015
  15. Jun 28, 2015