1. 17 Feb, 2011 9 commits
  2. 15 Feb, 2011 7 commits
  3. 14 Feb, 2011 3 commits
    • Naga Chumbalkar's avatar
      x86, dmi, debug: Log board name (when present) in dmesg/oops output · 84e383b3
      Naga Chumbalkar authored
      
      
      The "Type 2" SMBIOS record that contains Board Name is not
      strictly required and may be absent in the SMBIOS on some
      platforms.
      
      ( Please note that Type 2 is not listed in Table 3 in Sec 6.2
        ("Required Structures and Data") of the SMBIOS v2.7
        Specification. )
      
      Use the Manufacturer Name (aka System Vendor) name.
      Print Board Name only when it is present.
      
      Before the fix:
        (i) dmesg output: DMI: /ProLiant DL380 G6, BIOS P62 01/29/2011
       (ii) oops output:  Pid: 2170, comm: bash Not tainted 2.6.38-rc4+ #3 /ProLiant DL380 G6
      
      After the fix:
        (i) dmesg output: DMI: HP ProLiant DL380 G6, BIOS P62 01/29/2011
       (ii) oops output:  Pid: 2278, comm: bash Not tainted 2.6.38-rc4+ #4 HP ProLiant DL380 G6
      Signed-off-by: default avatarNaga Chumbalkar <nagananda.chumbalkar@hp.com>
      Reviewed-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: <stable@kernel.org> # .3x - good for debugging, please apply as far back as it applies cleanly
      LKML-Reference: <20110214224423.2182.13929.sendpatchset@nchumbalkar.americas.hpqcorp.net>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      84e383b3
    • Paul Bolle's avatar
      x86, ioapic: Don't warn about non-existing IOAPICs if we have none · 678301ec
      Paul Bolle authored
      
      
      mp_find_ioapic() prints errors like:
      
          ERROR: Unable to locate IOAPIC for GSI 13
      
      if it can't find the IOAPIC that manages that specific GSI. I
      see errors like that at every boot of a laptop that apparently
      doesn't have any IOAPICs.
      
      But if there are no IOAPICs it doesn't seem to be an error that
      none can be found. A solution that gets rid of this message is
      to directly return if nr_ioapics (still) is zero. (But keep
      returning -1 in that case, so nothing breaks from this change.)
      
      The call chain that generates this error is:
      
      pnpacpi_allocated_resource()
          case ACPI_RESOURCE_TYPE_IRQ:
              pnpacpi_parse_allocated_irqresource()
                  acpi_get_override_irq()
                       mp_find_ioapic()
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      678301ec
    • Borislav Petkov's avatar
      x86: Fix mwait_usable section mismatch · 1c9d16e3
      Borislav Petkov authored
      
      
      We use it in non __cpuinit code now too so drop marker.
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20110211171754.GA21047@aftab>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      1c9d16e3
  4. 12 Feb, 2011 1 commit
  5. 11 Feb, 2011 5 commits
    • Peter Zijlstra's avatar
      x86: Fix text_poke_smp_batch() deadlock · d91309f6
      Peter Zijlstra authored
      
      
      Fix this deadlock - we are already holding the mutex:
      
      =======================================================
      [ INFO: possible circular locking dependency detected ] 2.6.38-rc4-test+ #1
      -------------------------------------------------------
      bash/1850 is trying to acquire lock:
       (text_mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
      
      but task is already holding lock:
       (smp_alt){+.+...}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (smp_alt){+.+...}:
             [<ffffffff81082d02>] lock_acquire+0xcd/0xf8
             [<ffffffff8192e119>] __mutex_lock_common+0x4c/0x339
             [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43
             [<ffffffff8101050f>] alternatives_smp_switch+0x77/0x1d8
             [<ffffffff81926a6f>] do_boot_cpu+0xd7/0x762
             [<ffffffff819277dd>] native_cpu_up+0xe6/0x16a
             [<ffffffff81928e28>] _cpu_up+0x9d/0xee
             [<ffffffff81928f4c>] cpu_up+0xd3/0xe7
             [<ffffffff82268d4b>] kernel_init+0xe8/0x20a
             [<ffffffff8100ba24>] kernel_thread_helper+0x4/0x10
      
      -> #1 (cpu_hotplug.lock){+.+.+.}:
             [<ffffffff81082d02>] lock_acquire+0xcd/0xf8
             [<ffffffff8192e119>] __mutex_lock_common+0x4c/0x339
             [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43
             [<ffffffff810568cc>] get_online_cpus+0x41/0x55
             [<ffffffff810a1348>] stop_machine+0x1e/0x3e
             [<ffffffff819314c1>] text_poke_smp_batch+0x3a/0x3c
             [<ffffffff81932b6c>] arch_optimize_kprobes+0x10d/0x11c
             [<ffffffff81933a51>] kprobe_optimizer+0x152/0x222
             [<ffffffff8106bb71>] process_one_work+0x1d3/0x335
             [<ffffffff8106cfae>] worker_thread+0x104/0x1a4
             [<ffffffff810707c4>] kthread+0x9d/0xa5
             [<ffffffff8100ba24>] kernel_thread_helper+0x4/0x10
      
      -> #0 (text_mutex){+.+.+.}:
      
      other info that might help us debug this:
      
      6 locks held by bash/1850:
       #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
       #1:  (s_active#75){.+.+.+}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
       #2:  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
       #3:  (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
       #4:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
       #5:  (smp_alt){+.+...}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
      
      stack backtrace:
      Pid: 1850, comm: bash Not tainted 2.6.38-rc4-test+ #1
      Call Trace:
      
       [<ffffffff81080eb2>] print_circular_bug+0xa8/0xb7
       [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43
       [<ffffffff81010302>] alternatives_smp_unlock+0x3d/0x93
       [<ffffffff81010630>] alternatives_smp_switch+0x198/0x1d8
       [<ffffffff8102568a>] native_cpu_die+0x65/0x95
       [<ffffffff818cc4ec>] _cpu_down+0x13e/0x202
       [<ffffffff8117a619>] sysfs_write_file+0x108/0x144
       [<ffffffff8111f5a2>] vfs_write+0xac/0xff
       [<ffffffff8111f7a9>] sys_write+0x4a/0x6e
      Reported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Tested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: mathieu.desnoyers@efficios.com
      Cc: rusty@rustcorp.com.au
      Cc: ananth@in.ibm.com
      Cc: masami.hiramatsu.pt@hitachi.com
      Cc: fweisbec@gmail.com
      Cc: jbeulich@novell.com
      Cc: jbaron@redhat.com
      Cc: mhiramat@redhat.com
      LKML-Reference: <1297458466.5226.93.camel@laptop>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d91309f6
    • Will Deacon's avatar
      ARM: 6657/1: hw_breakpoint: fix ptrace breakpoint advertising on unsupported arch · 66e1cfe6
      Will Deacon authored
      
      
      The ptrace debug information register was advertising breakpoint and
      watchpoint resources for unsupported debug architectures. This meant
      that setting breakpoints on these architectures would appear to succeed,
      although they would never fire in reality.
      
      This patch fixes the breakpoint slot probing so that it returns 0 when
      running on an unsupported debug architecture.
      Reported-by: default avatarUlrich Weigand <ulrich.weigand@de.ibm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      66e1cfe6
    • Will Deacon's avatar
      ARM: 6656/1: hw_breakpoint: avoid UNPREDICTABLE behaviour when reading DBGDSCR · ed19b739
      Will Deacon authored
      
      
      Reading baseline CP14 registers, other than DBGDIDR, when the OS Lock
      is set leads to UNPREDICTABLE behaviour.
      
      This patch ensures that we clear the OS lock before accessing anything
      other than the DBGDIDR, thereby avoiding this behaviour.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ed19b739
    • Dmitry Eremin-Solenikov's avatar
      ARM: 6658/1: collie: do actually pass locomo_info to locomo driver · 34cd2d38
      Dmitry Eremin-Solenikov authored
      
      
      locomo_info isn't actually used as a platform_data on collie platform:
       arm/mach-sa1100/collie.c:237: warning: ‘locomo_info’ defined but not used
      
      So locomo driver doesn't setup IRQs correctly. Pass locomo_info to the
      driver.
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      34cd2d38
    • Dave Martin's avatar
      ARM: 6659/1: Thumb-2: Make CONFIG_OABI_COMPAT depend on !CONFIG_THUMB2_KERNEL · 9bc433a1
      Dave Martin authored
      
      
      rmk says: "You might as well make OABI_COMPAT depend on !THUMB2_KERNEL.
      OABI userland is useless without FPA support."
      
      nwfpe doesn't work with Thumb-2 anyway and will probably never get
      ported, so I can't argue with that.
      
      This patch implements the dependency change.
      Signed-off-by: default avatarDave Martin <dave.martin@linaro.org>
      Acked-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      9bc433a1
  6. 10 Feb, 2011 7 commits
  7. 09 Feb, 2011 6 commits
  8. 07 Feb, 2011 2 commits
    • Greg Ungerer's avatar
      m68knommu: fix use of un-defined _TIF_WORK_MASK · b3e338de
      Greg Ungerer authored
      The _TIF_WORK_MASK definition was removed in the clean up of MMU and
      non-MMU arch/m68k/include/asm/thread_info*.h files (this was commit
      cddafa35
      
      , "merge MMU and non-MMU
      thread_info.h").
      
      It didn't get cleaned out of the entry.S code for the 68328 and 68360
      based platforms. And it was replaced by a hard coded constant mask for
      coldfire platforms. There is currently no need to mask any of these bits,
      so fix all uses (and former uses) to check for any non-zero value.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      b3e338de
    • Michal Simek's avatar
      microblaze: Fix msr instruction detection · 0eb6aaf5
      Michal Simek authored
      
      
      Fix msr instructions detection. The current code
      just use msrclr for loading msr content and compare
      it with proper MSR content. If msrclr is not implemented
      r8 contains pc address.
      Previous code wanted to use MSR carry bit but if msrclr
      wasn't implemented carry wasn't cleared.
      Signed-off-by: default avatarMichal Simek <monstr@monstr.eu>
      0eb6aaf5