1. 26 8月, 2008 2 次提交
  2. 25 8月, 2008 4 次提交
  3. 24 8月, 2008 1 次提交
  4. 23 8月, 2008 3 次提交
    • R
      x86 MCE: Fix CPU hotplug problem with multiple multicore AMD CPUs · 8735728e
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NAndi Kleen <andi@firstfloor.org>
      Tested-by: NMark Langsdorf <mark.langsdorf@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8735728e
    • R
      x86: fix: make PCI ECS for AMD CPUs hotplug capable · 91ede005
      Robert Richter 提交于
      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: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      91ede005
    • R
      x86: fix: do not run code in amd_bus.c on non-AMD CPUs · 9b4e27b5
      Robert Richter 提交于
      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: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9b4e27b5
  5. 22 8月, 2008 10 次提交
    • I
      x86: work around MTRR mask setting, v2 · 9754a5b8
      Ingo Molnar 提交于
      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: NIngo Molnar <mingo@elte.hu>
      9754a5b8
    • 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
    • M
      cce7496d
    • E
      [S390] fix ext2_find_next_bit · 152382af
      Eric Sandeen 提交于
      ext4 does not work on s390 because ext2_find_next_bit is broken. Fortunately
      this function is only used by ext4. The function uses ffs which does not work
      analog to ffz. The result of ffs has an offset of 1 which is not taken into
      account. To fix this use the low level __ffs_word function directly instead
      of the ill defined ffs.
      
      In addition the patch improves find_next_zero_bit and ext2_find_next_zero_bit
      by passing the bit offset into __ffz_word instead of adding it after the
      function call returned.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      152382af
    • H
      [S390] Remove unneeded spinlock initialization. · 8853e505
      Heiko Carstens 提交于
      Remove the now unneeded s390_idle.lock spinlock initialization after
      Josef Sipek did it the right way in arch/s390/kernel/process.c.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8853e505
    • J
      [S390] Fix uninitialized spinlock use · 3e972394
      Josef 'Jeff' Sipek 提交于
      Ever since commit 43ca5c3a ([S390] Convert
      monitor calls to function calls.), the kernel refused to IPL with spinlock
      debugging enabled.
      
      BUG: spinlock bad magic on CPU#0, swapper/0
       lock: 00000000003a4668, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
      CPU: 0 Not tainted 2.6.25 #1
      Process swapper (pid: 0, task: 000000000034f958, ksp: 0000000000377d60)
      0000000000377ab8 0000000000352628 0000000000377d60 0000000000377d60
             0000000000016af4 00000000fffff7b5 0000000000377d60 0000000000000000
             0000000000000000 0000000000377a18 0000000000000009 0000000000377a18
             0000000000377a78 000000000023c920 0000000000016af4 0000000000377a18
             0000000000000005 0000000000000000 0000000000377b58 0000000000377ab8
      Call Trace:
      ([<0000000000016a60>] show_trace+0xdc/0x108)
       [<0000000000016b4e>] show_stack+0xc2/0xfc
       [<0000000000016c9a>] dump_stack+0xb2/0xc0
       [<0000000000172dd4>]
      Signed-off-by: NJosef 'Jeff' Sipek <jeffpc@josefsipek.net>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      3e972394
  6. 21 8月, 2008 10 次提交
  7. 20 8月, 2008 8 次提交
    • 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
    • B
      powerpc: Fix vio_bus_probe oops on probe error · cd5aeb9f
      Brian King 提交于
      When CMO is enabled and booted on a non CMO system and the VIO
      device's probe function fails, an oops can result since
      vio_cmo_bus_remove is called when it should not.  This fixes it by
      avoiding the vio_cmo_bus_remove call on platforms that don't implement
      CMO.
      
      cpu 0x0: Vector: 300 (Data Access) at [c00000000e13b3d0]
          pc: c000000000020d34: .vio_cmo_bus_remove+0xc0/0x1f4
          lr: c000000000020ca4: .vio_cmo_bus_remove+0x30/0x1f4
          sp: c00000000e13b650
         msr: 8000000000009032
         dar: 0
       dsisr: 40000000
        current = 0xc00000000e0566c0
        paca    = 0xc0000000006f9b80
          pid   = 2428, comm = modprobe
      enter ? for help
      [c00000000e13b6e0] c000000000021d94 .vio_bus_probe+0x2f8/0x33c
      [c00000000e13b7a0] c00000000029fc88 .driver_probe_device+0x13c/0x200
      [c00000000e13b830] c00000000029fdac .__driver_attach+0x60/0xa4
      [c00000000e13b8c0] c00000000029f050 .bus_for_each_dev+0x80/0xd8
      [c00000000e13b980] c00000000029f9ec .driver_attach+0x28/0x40
      [c00000000e13ba00] c00000000029f630 .bus_add_driver+0xd4/0x284
      [c00000000e13baa0] c0000000002a01bc .driver_register+0xc4/0x198
      [c00000000e13bb50] c00000000002168c .vio_register_driver+0x40/0x5c
      [c00000000e13bbe0] d0000000003b3f1c .ibmvfc_module_init+0x70/0x109c [ibmvfc]
      [c00000000e13bc70] c0000000000acf08 .sys_init_module+0x184c/0x1a10
      [c00000000e13be30] c000000000008748 syscall_exit+0x0/0x40
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cd5aeb9f
    • J
      powerpc/ibmebus: Restore "name" sysfs attribute on ibmebus devices · 4589f1fe
      Joachim Fenkes 提交于
      Recent of_platform changes made of_bus_type_init() overwrite the bus
      type's .dev_attrs list, meaning that the "name" attribute that ibmebus
      devices previously had is no longer present.  This is a user-visible
      regression which breaks the userspace eHCA support, since the eHCA
      userspace driver relies on the name attribute to check for valid
      adapters.
      
      This fixes it by providing the "name" attribute in the generic OF
      device code instead.  Tested on POWER.
      Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4589f1fe
    • M
      powerpc: Fix /dev/oldmem interface for kdump · 7230ced4
      Michael Ellerman 提交于
      A change to __ioremap() broke reading /dev/oldmem because we're no
      longer able to ioremap pfn 0 (d177c207, "[PATCH] powerpc: IOMMU: don't
      ioremap null addresses").
      
      We actually don't need to ioremap for anything that's part of the linear
      mapping, so just read it directly.
      
      Also make sure we're only reading one page or less at a time.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NSachin Sant <sachinp@in.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7230ced4
    • L
      Revert "[CPUFREQ][2/2] preregister support for powernow-k8" · f607e3a0
      Linus Torvalds 提交于
      This reverts commit 34ae7f35, which has
      been reported to cause a number of problems.  During suspend and resume,
      it apparently causes a crash in a CPU hotplug notifier to happen,
      although the exact details are sketchy because of the inability to get
      good traces during the suspend sequence.
      
      See buzilla entries
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=11296
      	http://bugzilla.kernel.org/show_bug.cgi?id=11339
      
      for more examples and details.
      
      [ Mark: "Revert the patch for now.  I'm still looking into getting a
        reliable reproduction and I do not have a fix at this time." ]
      Requested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NMark Langsdorf <mark.langsdorf@amd.com>
      Acked-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@inux-foundation.org>
      f607e3a0
  8. 19 8月, 2008 2 次提交