1. 11 Oct, 2010 2 commits
    • Yinghai Lu's avatar
      x86, numa: For each node, register the memory blocks actually used · 73cf624d
      Yinghai Lu authored
      Russ reported SGI UV is broken recently. He said:
      
      | The SRAT table shows that memory range is spread over two nodes.
      |
      | SRAT: Node 0 PXM 0 100000000-800000000
      | SRAT: Node 1 PXM 1 800000000-1000000000
      | SRAT: Node 0 PXM 0 1000000000-1080000000
      |
      |Previously, the kernel early_node_map[] would show three entries
      |with the proper node.
      |
      |[    0.000000]     0: 0x00100000 -> 0x00800000
      |[    0.000000]     1: 0x00800000 -> 0x01000000
      |[    0.000000]     0: 0x01000000 -> 0x01080000
      |
      |The problem is recent community kernel early_node_map[] shows
      |only two entries with the node 0 entry overlapping the node 1
      |entry.
      |
      |    0: 0x00100000 -> 0x01080000
      |    1: 0x00800000 -> 0x01000000
      
      After looking at the changelog, Found out that it has been broken for a while by
      following commit
      
      |commit 8716273c
      |Author: David Rientjes <rientjes@google.com>
      |Date:   Fri Sep 25 15:20:04 2009 -0700
      |
      |    x86: Export srat physical topology
      
      Before that commit, register_active_regions() is called for every SRAT memory
      entry right away.
      
      Use nodememblk_range[] instead of nodes[] in order to make sure we
      capture the actual memory blocks registered with each node.  nodes[]
      contains an extended range which spans all memory regions associated
      with a node, but that does not mean that all the memory in between are
      included.
      Reported-by: default avatarRuss Anderson <rja@sgi.com>
      Tested-by: default avatarRuss Anderson <rja@sgi.com>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CB27BDF.5000800@kernel.org>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: <stable@kernel.org> 2.6.33 .34 .35 .36
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      73cf624d
    • Borislav Petkov's avatar
      x86, AMD, MCE thresholding: Fix the MCi_MISCj iteration order · 6dcbfe4f
      Borislav Petkov authored
      This fixes possible cases of not collecting valid error info in
      the MCE error thresholding groups on F10h hardware.
      
      The current code contains a subtle problem of checking only the
      Valid bit of MSR0000_0413 (which is MC4_MISC0 - DRAM
      thresholding group) in its first iteration and breaking out if
      the bit is cleared.
      
      But (!), this MSR contains an offset value, BlkPtr[31:24], which
      points to the remaining MSRs in this thresholding group which
      might contain valid information too. But if we bail out only
      after we checked the valid bit in the first MSR and not the
      block pointer too, we miss that other information.
      
      The thing is, MC4_MISC0[BlkPtr] is not predicated on
      MCi_STATUS[MiscV] or MC4_MISC0[Valid] and should be checked
      prior to iterating over the MCI_MISCj thresholding group,
      irrespective of the MC4_MISC0[Valid] setting.
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6dcbfe4f
  2. 08 Oct, 2010 1 commit
  3. 07 Oct, 2010 23 commits
  4. 06 Oct, 2010 6 commits
  5. 05 Oct, 2010 8 commits
    • Thomas Hellstrom's avatar
      drm/ttm: Fix two race conditions + fix busy codepaths · 1df6a2eb
      Thomas Hellstrom authored
      This fixes a race pointed out by Dave Airlie where we don't take a buffer
      object about to be destroyed off the LRU lists properly. It also fixes a rare
      case where a buffer object could be destroyed in the middle of an
      accelerated eviction.
      
      The patch also adds a utility function that can be used to prematurely
      release GPU memory space usage of an object waiting to be destroyed.
      For example during eviction or swapout.
      
      The above mentioned commit didn't queue the buffer on the delayed destroy
      list under some rare circumstances. It also didn't completely honor the
      remove_all parameter.
      
      Fixes:
      https://bugzilla.redhat.com/show_bug.cgi?id=615505
      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591061Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      1df6a2eb
    • Linus Torvalds's avatar
      Merge branch 'core-fixes-for-linus' of... · e1d9694c
      Linus Torvalds authored
      Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        rcu: rcu_read_lock_bh_held(): disabling irqs also disables bh
        generic-ipi: Fix deadlock in __smp_call_function_single
      e1d9694c
    • Linus Torvalds's avatar
      Merge branch 'perf-fixes-for-linus' of... · 39c12be8
      Linus Torvalds authored
      Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        perf trace scripting: Fix extern struct definitions
        perf ui hist browser: Fix segfault on 'a' for annotate
        perf tools: Fix build breakage
        perf, x86: Handle in flight NMIs on P4 platform
        oprofile, ARM: Release resources on failure
        oprofile: Add Support for Intel CPU Family 6 / Model 29
      39c12be8
    • Evgeny Kuznetsov's avatar
      wait: using uninitialized member of wait queue · 231d0aef
      Evgeny Kuznetsov authored
      The "flags" member of "struct wait_queue_t" is used in several places in
      the kernel code without beeing initialized by init_wait().  "flags" is
      used in bitwise operations.
      
      If "flags" not initialized then unexpected behaviour may take place.
      Incorrect flags might used later in code.
      
      Added initialization of "wait_queue_t.flags" with zero value into
      "init_wait".
      Signed-off-by: default avatarEvgeny Kuznetsov <EXT-Eugeny.Kuznetsov@nokia.com>
      [ The bit we care about does end up being initialized by both
         prepare_to_wait() and add_to_wait_queue(), so this doesn't seem to
         cause actual bugs, but is definitely the right thing to do -Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      231d0aef
    • Linus Torvalds's avatar
      modules: Fix module_bug_list list corruption race · 5336377d
      Linus Torvalds authored
      With all the recent module loading cleanups, we've minimized the code
      that sits under module_mutex, fixing various deadlocks and making it
      possible to do most of the module loading in parallel.
      
      However, that whole conversion totally missed the rather obscure code
      that adds a new module to the list for BUG() handling.  That code was
      doubly obscure because (a) the code itself lives in lib/bugs.c (for
      dubious reasons) and (b) it gets called from the architecture-specific
      "module_finalize()" rather than from generic code.
      
      Calling it from arch-specific code makes no sense what-so-ever to begin
      with, and is now actively wrong since that code isn't protected by the
      module loading lock any more.
      
      So this commit moves the "module_bug_{finalize,cleanup}()" calls away
      from the arch-specific code, and into the generic code - and in the
      process protects it with the module_mutex so that the list operations
      are now safe.
      
      Future fixups:
       - move the module list handling code into kernel/module.c where it
         belongs.
       - get rid of 'module_bug_list' and just use the regular list of modules
         (called 'modules' - imagine that) that we already create and maintain
         for other reasons.
      Reported-and-tested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Adrian Bunk <bunk@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5336377d
    • Stefano Stabellini's avatar
      xen: do not initialize PV timers on HVM if !xen_have_vector_callback · 31e7e931
      Stefano Stabellini authored
      if !xen_have_vector_callback do not initialize PV timer unconditionally
      because we still don't know how many cpus are available and if there is
      more than one we won't be able to receive the timer interrupts on
      cpu > 0.
      
      This patch fixes an hang at boot when Xen does not support vector
      callbacks and the guest has multiple vcpus.
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      31e7e931
    • Stefano Stabellini's avatar
      xen: do not set xenstored_ready before xenbus_probe on hvm · a947f0f8
      Stefano Stabellini authored
      Register_xenstore_notifier should guarantee that the caller gets
      notified even if xenstore is already up.
      Therefore we revert "do not notify callers from
      register_xenstore_notifier" and set xenstored_read at the right time for
      PV on HVM guests too.
      In fact in case of PV on HVM guests xenstored is ready only after the
      platform pci driver has completed the initialization, so do not set
      xenstored_ready before the call to xenbus_probe().
      
      This patch fixes a shutdown_event watcher registration bug that causes
      "xm shutdown" not to work properly.
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      a947f0f8
    • Dmitry Torokhov's avatar
      Input: wacom - fix runtime PM related deadlock · f6cd3783
      Dmitry Torokhov authored
      When runtime PM is enabled by default for input devices, X hangs in
      wacom open:
      [<ffffffff814a00ea>] mutex_lock+0x1a/0x40
      [<ffffffffa02bc94b>] wacom_resume+0x3b/0x90 [wacom]
      [<ffffffff81327a32>] usb_resume_interface+0xd2/0x190
      [<ffffffff81327b5d>] usb_resume_both+0x6d/0x110
      [<ffffffff81327c24>] usb_runtime_resume+0x24/0x40
      [<ffffffff8130a2cf>] __pm_runtime_resume+0x26f/0x450
      [<ffffffff8130a23a>] __pm_runtime_resume+0x1da/0x450
      [<ffffffff8130a53a>] pm_runtime_resume+0x2a/0x50
      [<ffffffff81328176>] usb_autopm_get_interface+0x26/0x60
      [<ffffffffa02bc626>] wacom_open+0x36/0x90 [wacom]
      
      wacom_open() takes wacom->lock and calls usb_autopm_get_interface(),
      which in turn calls wacom_resume() which tries to acquire the lock
      again.
      
      The fix is to call usb_autopm_get_interface() first, before we take
      the lock.
      
      Since we do not do usb_autopm_put_interface() until wacom_close()
      is called runtime PM is effectively disabled for the driver, however
      changing it now would risk regressions so the complete fix will
      have to wait till the next merge window.
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Acked-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      f6cd3783