1. 30 12月, 2009 1 次提交
  2. 29 12月, 2009 1 次提交
    • M
      x86: SGI UV: Fix writes to led registers on remote uv hubs · 39d30770
      Mike Travis 提交于
      The wrong address was being used to write the SCIR led regs on
      remote hubs.  Also, there was an inconsistency between how BIOS
      and the kernel indexed these regs.  Standardize on using the
      lower 6 bits of the APIC ID as the index.
      
      This patch fixes the problem of writing to an errant address to
      a cpu # >= 64.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NJack Steiner <steiner@sgi.com>
      Cc: Robin Holt <holt@sgi.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: stable@kernel.org
      LKML-Reference: <4B3922F9.3060905@sgi.com>
      [ v2: fix a number of annoying checkpatch artifacts and whitespace noise ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      39d30770
  3. 28 12月, 2009 3 次提交
    • P
      x86, kmemcheck: Use KERN_WARNING for error reporting · c0ca9da4
      Pekka Enberg 提交于
      As suggested by Vegard Nossum, use KERN_WARNING for error
      reporting to make sure kmemcheck reports end up in syslog.
      Suggested-by: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <1261990935.4641.7.camel@penberg-laptop>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c0ca9da4
    • P
      x86: Use KERN_DEFAULT log-level in __show_regs() · d015a092
      Pekka Enberg 提交于
      Andrew Morton reported a strange looking kmemcheck warning:
      
        WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88004fba6c20)
        0000000000000000310000000000000000000000000000002413000000c9ffff
         u u u u u u u u u u u u u u u u i i i i i i i i u u u u u u u u
      
         [<ffffffff810af3aa>] kmemleak_scan+0x25a/0x540
         [<ffffffff810afbcb>] kmemleak_scan_thread+0x5b/0xe0
         [<ffffffff8104d0fe>] kthread+0x9e/0xb0
         [<ffffffff81003074>] kernel_thread_helper+0x4/0x10
         [<ffffffffffffffff>] 0xffffffffffffffff
      
      The above printout is missing register dump completely. The
      problem here is that the output comes from syslog which doesn't
      show KERN_INFO log-level messages. We didn't see this before
      because both of us were testing on 32-bit kernels which use the
      _default_ log-level.
      
      Fix that up by explicitly using KERN_DEFAULT log-level for
      __show_regs() printks.
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <1261988819.4641.2.camel@penberg-laptop>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d015a092
    • I
      Merge branch 'iommu/fixes' of... · 605c1a18
      Ingo Molnar 提交于
      Merge branch 'iommu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux-2.6-iommu into x86/urgent
      605c1a18
  4. 26 12月, 2009 1 次提交
    • H
      x86, compress: Force i386 instructions for the decompressor · 17a2a9b5
      H. Peter Anvin 提交于
      Recently, some distros have started shipping versions of gcc which
      default to -march=i686.  This breaks building kernels for pre-i686
      machines, even if they have been selected in Kconfig, due to the
      generation of CMOV instructions.
      
      There isn't enough benefit to try to preserve the generation of these
      instructions even when selected, so simply force -march=i386 for the
      decompressor when building a 32-bit kernel.
      Reported-and-tested-by: NChris Rankin <rankincj@yahoo.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <219280.97558.qm@web52907.mail.re2.yahoo.com>
      17a2a9b5
  5. 21 12月, 2009 3 次提交
    • J
    • J
      x86/amd-iommu: Fix initialization failure panic · 0f764806
      Joerg Roedel 提交于
      The assumption that acpi_table_parse passes the return value
      of the hanlder function to the caller proved wrong
      recently. The return value of the handler function is
      totally ignored. This makes the initialization code for AMD
      IOMMU buggy in a way that could cause a kernel panic on
      initialization. This patch fixes the issue in the AMD IOMMU
      driver.
      
      Cc: stable@kernel.org
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      0f764806
    • S
      dma-debug: Do not add notifier when dma debugging is disabled. · f797d988
      Shaun Ruffell 提交于
      If CONFIG_HAVE_DMA_API_DEBUG is defined and "dma_debug=off" is
      specified on the kernel command line, when you detach a driver from a
      device you can cause the following NULL pointer dereference:
      
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<c0580d35>] dma_debug_device_change+0x5d/0x117
      
      The problem is that the dma_debug_device_change notifier function is
      added to the bus notifier chain even though the dma_entry_hash array
      was never initialized.  If dma debugging is disabled, this patch both
      prevents dma_debug_device_change notifiers from being added to the
      chain, and additionally ensures that the dma_debug_device_change
      notifier function is a no-op.
      
      Cc: stable@kernel.org
      Signed-off-by: NShaun Ruffell <sruffell@digium.com>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      f797d988
  6. 19 12月, 2009 1 次提交
  7. 18 12月, 2009 30 次提交