Skip to content

L
linux
Switch branch/tag
  1. 25 Aug, 2008 3 commits
  3. 23 Aug, 2008 3 commits
    • Rafael J. Wysocki's avatar
      x86 MCE: Fix CPU hotplug problem with multiple multicore AMD CPUs · 8735728e
      Rafael J. Wysocki authored 
      During CPU hot-remove the sysfs directory created by
threshold_create_bank(), defined in
arch/x86/kernel/cpu/mcheck/mce_amd_64.c, has to be removed before
its parent directory, created by mce_create_device(), defined in
arch/x86/kernel/cpu/mcheck/mce_64.c .  Moreover, when the CPU in
question is hotplugged again, obviously the latter has to be created
before the former.  At present, the right ordering is not enforced,
because all of these operations are carried out by CPU hotplug
notifiers which are not appropriately ordered with respect to each
other.  This leads to serious problems on systems with two or more
multicore AMD CPUs, among other things during suspend and hibernation.

Fix the problem by placing threshold bank CPU hotplug callbacks in
mce_cpu_callback(), so that they are invoked at the right places,
if defined.  Additionally, use kobject_del() to remove the sysfs
directory associated with the kobject created by
kobject_create_and_add() in threshold_create_bank(), to prevent the
kernel from crashing during CPU hotplug operations on systems with
two or more multicore AMD CPUs.

This patch fixes bug #11337.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Acked-by: default avatarAndi Kleen <andi@firstfloor.org>
Tested-by: default avatarMark Langsdorf <mark.langsdorf@amd.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8735728e
    • Robert Richter's avatar
      x86: fix: make PCI ECS for AMD CPUs hotplug capable · 91ede005
      Robert Richter authored 
      Until now, PCI ECS setup was performed at boot time only and for cpus
that are enabled then. This patch fixes this and adds cpu hotplug.

Tests sequence (check if ECS bit is set when bringing cpu online again):

 # ( perl -e 'sysseek(STDIN, 0xC001001F, 0)'; hexdump -n 8 -e '2/4 "%08x " "\n"' )   < /dev/cpu/1/msr
 00000008 00404010
 # ( perl -e 'sysseek(STDOUT, 0xC001001F, 0); print pack "l*", 8, 0x00400010' ) > /dev/cpu/1/msr
 # ( perl -e 'sysseek(STDIN, 0xC001001F, 0)'; hexdump -n 8 -e '2/4 "%08x " "\n"' )   < /dev/cpu/1/msr
 00000008 00400010
 # echo 0 > /sys/devices/system/cpu/cpu1/online
 # echo 1 > /sys/devices/system/cpu/cpu1/online
 # ( perl -e 'sysseek(STDIN, 0xC001001F, 0)'; hexdump -n 8 -e '2/4 "%08x " "\n"' )   < /dev/cpu/1/msr
 00000008 00404010
Reported-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      91ede005
    • Robert Richter's avatar
      x86: fix: do not run code in amd_bus.c on non-AMD CPUs · 9b4e27b5
      Robert Richter authored 
      Jan Beulich wrote:

> Even worse - this would even try to access the MSR on non-AMD CPUs
> (currently probably prevented just by the fact that only AMD ones use
> family values of 0x10 or higher).

This patch adds cpu vendor check to the postcore_initcalls.
Reported-by: default avatarJan Beulich <jbeulich@novell.com>
Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9b4e27b5
  5. 22 Aug, 2008 6 commits
    • Ingo Molnar's avatar
      x86: work around MTRR mask setting, v2 · 9754a5b8
      Ingo Molnar authored 
      improve the debug printout:

- make it actually display something
- print it only once

would be nice to have a WARN_ONCE() facility, to feed such things to
kerneloops.org.
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9754a5b8
    • Marcin Slusarz's avatar
      x86: fix section mismatch warning - uv_cpu_init · c4bd1fda
      Marcin Slusarz authored 
      WARNING: vmlinux.o(.cpuinit.text+0x3cc4): Section mismatch in reference from the function uv_cpu_init() to the function .init.text:uv_system_init()
The function __cpuinit uv_cpu_init() references
a function __init uv_system_init().
If uv_system_init is only used by uv_cpu_init then
annotate uv_system_init with a matching annotation.

uv_system_init was ment to be called only once, so do it from codepath
(native_smp_prepare_cpus) which is called once, right before activation
of other cpus (smp_init).

Note: old code relied on uv_node_to_blade being initialized to 0,
but it'a not initialized from anywhere.
Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
Acked-by: default avatarJack Steiner <steiner@sgi.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c4bd1fda
    • Alok Kataria's avatar
      x86: fix VMI for early params · 3a6ddd5f
      Alok Kataria authored 
      while fixing a different bug i moved the call to vmi_init before
early params could be parsed.

This broke the vmi specific commandline parameters.
Fix that, by moving vmi initialization after kernel has got a chance to
parse early parameters.
Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3a6ddd5f
    • Jan Beulich's avatar
      x86: fix two modpost warnings in mm/init_64.c · 9482ac6e
      Jan Beulich authored 
      early_io{re,un}map() are __init and hence can't be called from __meminit
functions.
Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9482ac6e
    • Jan Beulich's avatar
      x86: fix 1:1 mapping init on 64-bit (memory hotplug case) · 8ae3a5a8
      Jan Beulich authored 
      While I don't have a hotplug capable system at hand, I think two issues need
fixing:

- pud_phys (in kernel_physical_ampping_init()) would remain uninitialized in
  the after_bootmem case

- the locking done just around phys_pmd_{init,update}() would leave out pgd
  updates, and it was needlessly covering code portions that do allocations
  (perhaps using a more friendly gfp value in alloc_low_page() would then be
  possible)
Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8ae3a5a8
    • Yinghai Lu's avatar
      x86: work around MTRR mask setting · 38cc1c3d
      Yinghai Lu authored 
      Joshua Hoblitt reported that only 3 GB of his 16 GB of RAM is
usable. Booting with mtrr_show showed us the BIOS-initialized
MTRR settings - which are all wrong.

So the root cause is that the BIOS has not set the mask correctly:

>               [    0.429971]  MSR00000200: 00000000d0000000
>               [    0.433305]  MSR00000201: 0000000ff0000800
> should be ==> [    0.433305]  MSR00000201: 0000003ff0000800
>
>               [    0.436638]  MSR00000202: 00000000e0000000
>               [    0.439971]  MSR00000203: 0000000fe0000800
> should be ==> [    0.439971]  MSR00000203: 0000003fe0000800
>
>               [    0.443304]  MSR00000204: 0000000000000006
>               [    0.446637]  MSR00000205: 0000000c00000800
> should be ==> [    0.446637]  MSR00000205: 0000003c00000800
>
>               [    0.449970]  MSR00000206: 0000000400000006
>               [    0.453303]  MSR00000207: 0000000fe0000800
> should be ==> [    0.453303]  MSR00000207: 0000003fe0000800
>
>               [    0.456636]  MSR00000208: 0000000420000006
>               [    0.459970]  MSR00000209: 0000000ff0000800
> should be ==> [    0.459970]  MSR00000209: 0000003ff0000800

So detect this borkage and add the prefix 111.
Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      38cc1c3d
  7. 21 Aug, 2008 11 commits
  9. 20 Aug, 2008 8 commits
  11. 19 Aug, 2008 4 commits
  13. 18 Aug, 2008 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7