1. 06 Sep, 2008 6 commits
  2. 05 Sep, 2008 1 commit
    • Russell King's avatar
      [ARM] sparse: fix several warnings · 09d9bae0
      Russell King authored
      arch/arm/kernel/process.c:270:6: warning: symbol 'show_fpregs' was not declared. Should it be static?
      This function isn't used, so can be removed.
      arch/arm/kernel/setup.c:532:9: warning: symbol 'len' shadows an earlier one
      arch/arm/kernel/setup.c:524:6: originally declared here
      A function containing two 'len's.
      arch/arm/mm/fault-armv.c:188:13: warning: symbol 'check_writebuffer_bugs' was not declared. Should it be static?
      arch/arm/mm/mmap.c:122:5: warning: symbol 'valid_phys_addr_range' was not declared. Should it be static?
      arch/arm/mm/mmap.c:137:5: warning: symbol 'valid_mmap_phys_addr_range' was not declared. Should it be static?
      Missing includes.
      arch/arm/kernel/traps.c:71:77: warning: Using plain integer as NULL pointer
      arch/arm/mm/ioremap.c:355:46: error: incompatible types in comparison expression (different address spaces)
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  3. 01 Sep, 2008 13 commits
  4. 25 Aug, 2008 5 commits
    • Linus Torvalds's avatar
      [x86] Clean up MAXSMP Kconfig, and limit NR_CPUS to 512 · d25e26b6
      Linus Torvalds authored
      This fixes a regression that was indirectly caused by commit
      1184dc2f ("x86: modify Kconfig to allow
      up to 4096 cpus").
      Allowing 4k CPU's is not practical at this time, because we still have a
      number of places that have several 'cpumask_t's on the stack, and a
      4k-bit cpumask is 512 bytes of stack-space for each such variable.  This
      literally caused functions like 'smp_call_function_mask' to have a 2.5kB
      stack frame, and several functions to have 2kB stackframes.
      With an 8kB stack total, smashing the stack was simply much too likely.
      At least bugzilla entry
      was due to this.
      The earlier commit to not inline load_module() into sys_init_module()
      fixed the particular symptoms of this that Alan Brunelle saw in that
      bugzilla entry, but the huge stack waste by cpumask_t's was the more
      direct cause.
      Some day we'll have allocation helpers that allocate large CPU masks
      dynamically, but in the meantime we simply cannot allow cpumasks this
      Cc: Alan D. Brunelle <Alan.Brunelle@hp.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Avi Kivity's avatar
      KVM: MMU: Fix torn shadow pte · cd5998eb
      Avi Kivity authored
      The shadow code assigns a pte directly in one place, which is nonatomic on
      i386 can can cause random memory references.  Fix by using an atomic setter.
      Signed-off-by: default avatarAvi Kivity <avi@qumranet.com>
    • Peter Zijlstra's avatar
      x86: fix cpufreq + sched_clock() regression · 52a8968c
      Peter Zijlstra authored
      I noticed that my sched_clock() was slow on a number of machine, so I
      started looking at cpufreq.
      The below seems to fix the problem for me.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Yinghai Lu's avatar
      x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3 · a2bd7274
      Yinghai Lu authored
      David Witbrodt tracked down (and bisected) a hpet bootup hang on his
      system to the following problem: a BIOS bug made the hpet device
      visible as a generic PCI device. If e820 reserved entries happen to
      be registered first in the resource tree [which v2.6.26 started doing],
      then the PCI code will reallocate that device's BAR to some other
      address - breaking timer IRQs and hanging the system.
      ( Normally hpet devices are hidden by the BIOS from the OS's PCI
        discovery via chipset magic. Sometimes the hpet is not a PCI device
        at all. )
      Solve this fundamental fragility by making non-PCI platform drivers
      insert resources into the resource tree even if it overlaps the e820
      reserved entry, to keep the resource manager from updating the BAR.
      Also do these checks for the ioapic and mmconfig addresses, and emit
      a warning if this happens.
      Bisected-by: default avatarDavid Witbrodt <dawitbro@sbcglobal.net>
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Tested-by: default avatarDavid Witbrodt <dawitbro@sbcglobal.net>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Linus Torvalds's avatar
      x86: do not enable TSC notifier if we don't need it · 060700b5
      Linus Torvalds authored
      Impact: crash on non-TSC-equipped CPUs
      Don't enable the TSC notifier if we *either*:
      1. don't have a CPU, or
      2. have a CPU with constant TSC.
      In either of those cases, the notifier is either damaging (1) or useless(2).
      From: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
  5. 23 Aug, 2008 4 commits
    • Adrian Bunk's avatar
      removed unused #include <linux/version.h>'s · 7a8fc9b2
      Adrian Bunk authored
      This patch lets the files using linux/version.h match the files that
      #include it.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • 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>
    • 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>
    • 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>
  6. 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
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • 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>
    • 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>
    • 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
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • 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
      - 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
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • 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>
  7. 21 Aug, 2008 5 commits