1. 22 8月, 2008 5 次提交
    • M
      x86: fix section mismatch warning - uv_cpu_init · c4bd1fda
      Marcin Slusarz 提交于
      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: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Acked-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c4bd1fda
    • A
      x86: fix VMI for early params · 3a6ddd5f
      Alok Kataria 提交于
      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: NAlok N Kataria <akataria@vmware.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3a6ddd5f
    • J
      x86: fix two modpost warnings in mm/init_64.c · 9482ac6e
      Jan Beulich 提交于
      early_io{re,un}map() are __init and hence can't be called from __meminit
      functions.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9482ac6e
    • J
      x86: fix 1:1 mapping init on 64-bit (memory hotplug case) · 8ae3a5a8
      Jan Beulich 提交于
      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: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8ae3a5a8
    • Y
      x86: work around MTRR mask setting · 38cc1c3d
      Yinghai Lu 提交于
      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: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      38cc1c3d
  2. 21 8月, 2008 9 次提交
  3. 20 8月, 2008 4 次提交
    • A
      x86: fix oprofile + hibernation badness · 80a8c9ff
      Andi Kleen 提交于
      Vegard Nossum reported oprofile + hibernation problems:
      
      > Now some warnings:
      >
      > ------------[ cut here ]------------
      > WARNING: at /uio/arkimedes/s29/vegardno/git-working/linux-2.6/kernel/smp.c:328 s
      > mp_call_function_mask+0x194/0x1a0()
      
      The usual problem: the suspend function when interrupts are
      already disabled calls smp_call_function which is not allowed with
      interrupt off. But at this point all the other CPUs should be already
      down anyways, so it should be enough to just drop that.
      
      This patch should fix that problem at least by fixing cpu hotplug&
      suspend support.
      
      [ mingo@elte.hu: fixed 5 coding style errors. ]
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Tested-by: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      80a8c9ff
    • C
      x86, SGI UV: hardcode the TLB flush interrupt system vector · 99dd8713
      Cliff Wickman 提交于
      The UV TLB shootdown mechanism needs a system interrupt vector.
      
      Its vector had been hardcoded as 200, but needs to moved to the reserved
      system vector range so that it does not collide with some device vector.
      
      This is still temporary until dynamic system IRQ allocation is provided.
      But it will be needed when real UV hardware becomes available and runs 2.6.27.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      99dd8713
    • V
      x86: fix Xorg startup/shutdown slowdown with PAT · 80c5e73d
      Venki Pallipadi 提交于
      Rene Herman reported significant Xorg startup/shutdown slowdown due
      to PAT. It turns out that the memtype list has thousands of entries.
      
      Add cached_entry to list add routine, in order to speed up the
      lookup for sequential reserve_memtype calls.
      Reported-by: NRene Herman <rene.herman@keyaccess.nl>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      80c5e73d
    • S
      x86: fix "kernel won't boot on a Cyrix MediaGXm (Geode)" · c6744955
      Samuel Sieb 提交于
      Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B has stopped
      booting starting at v2.6.22.
      
      The reason is this commit:
      
      > commit f25f64ed
      > Author: Juergen Beisert <juergen@kreuzholzen.de>
      > Date:   Sun Jul 22 11:12:38 2007 +0200
      >
      >     x86: Replace NSC/Cyrix specific chipset access macros by inlined functions.
      
      this commit activated a macro which was dormant before due to (buggy)
      macro side-effects.
      
      I've looked through various datasheets and found that the GXm and GXLV
      Geode processors don't have an incrementor.
      
      Remove the incrementor setup entirely.  As the incrementor value
      differs according to clock speed and we would hope that the BIOS
      configures it correctly, it is probably the right solution.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c6744955
  4. 19 8月, 2008 1 次提交
  5. 18 8月, 2008 17 次提交
  6. 17 8月, 2008 1 次提交
  7. 16 8月, 2008 3 次提交