1. 18 7月, 2008 1 次提交
  2. 15 7月, 2008 1 次提交
  3. 09 7月, 2008 7 次提交
  4. 26 5月, 2008 2 次提交
  5. 25 5月, 2008 1 次提交
  6. 20 4月, 2008 3 次提交
  7. 18 4月, 2008 2 次提交
    • J
      kgdb: fix several kgdb regressions · 737a460f
      Jason Wessel 提交于
      kgdb core fixes:
      - Check to see that mm->mmap_cache is not null before calling
        flush_cache_range(), else on arch=ARM it will cause a fatal
        fault.
      
      - Breakpoints should only be restored if they are in the BP_ACTIVE
        state.
      
      - Fix a typo in comments to "kgdb_register_io_module"
      
      x86 kgdb fixes:
      - Fix the x86 arch handler such that on a kill or detach that the
        appropriate cleanup on the single stepping flags gets run.
      
      - Add in the DIE_NMIWATCHDOG call for x86_64
      
      - Touch the nmi watchdog before returning the system to normal
        operation after performing any kind of kgdb operation, else
        the possibility exists to trigger the watchdog.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      737a460f
    • J
      kgdb: fix NMI hangs · d3597524
      Jason Wessel 提交于
      This patch fixes the hang regression with kgdb when the NMI interrupt
      comes in while the master core is returning from an exception.
      
      Adjust the NMI logic such that KGDB will not stop NMI exceptions from
      occurring by in general returning NOTIFY_DONE.  It is not possible to
      distinguish the debug NMI sync vs the normal NMI apic interrupt so
      kgdb needs to catch the unknown NMI if it the debugger was previously
      active on one of the cpus.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3597524
  8. 17 4月, 2008 1 次提交
  9. 15 2月, 2008 1 次提交
    • I
      x86: fix "BUG: sleeping function called from invalid context" in print_vma_addr() · e8bff74a
      Ingo Molnar 提交于
      Jiri Kosina reported the following deadlock scenario with
      show_unhandled_signals enabled:
      
       [   68.379022] gnome-settings-[2941] trap int3 ip:3d2c840f34
       sp:7fff36f5d100 error:0<3>BUG: sleeping function called from invalid
       context at kernel/rwsem.c:21
       [   68.379039] in_atomic():1, irqs_disabled():0
       [   68.379044] no locks held by gnome-settings-/2941.
       [   68.379050] Pid: 2941, comm: gnome-settings- Not tainted 2.6.25-rc1 #30
       [   68.379054]
       [   68.379056] Call Trace:
       [   68.379061]  <#DB>  [<ffffffff81064883>] ? __debug_show_held_locks+0x13/0x30
       [   68.379109]  [<ffffffff81036765>] __might_sleep+0xe5/0x110
       [   68.379123]  [<ffffffff812f2240>] down_read+0x20/0x70
       [   68.379137]  [<ffffffff8109cdca>] print_vma_addr+0x3a/0x110
       [   68.379152]  [<ffffffff8100f435>] do_trap+0xf5/0x170
       [   68.379168]  [<ffffffff8100f52b>] do_int3+0x7b/0xe0
       [   68.379180]  [<ffffffff812f4a6f>] int3+0x9f/0xd0
       [   68.379203]  <<EOE>>
       [   68.379229]  in libglib-2.0.so.0.1505.0[3d2c800000+dc000]
      
      and tracked it down to:
      
        commit 03252919
        Author: Andi Kleen <ak@suse.de>
        Date:   Wed Jan 30 13:33:18 2008 +0100
      
            x86: print which shared library/executable faulted in segfault etc. messages
      
      the problem is that we call down_read() from an atomic context.
      
      Solve this by returning from print_vma_addr() if the preempt count is
      elevated. Update preempt_conditional_sti / preempt_conditional_cli to
      unconditionally lift the preempt count even on !CONFIG_PREEMPT.
      Reported-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e8bff74a
  10. 30 1月, 2008 18 次提交
  11. 16 1月, 2008 1 次提交
    • P
      lockdep: more hardirq annotations for notify_die() · fb1dac90
      Peter Zijlstra 提交于
      On Sat, 2007-12-29 at 18:06 +0100, Marcin Slusarz wrote:
      > Hi
      > Today I've got this (while i was upgrading my gentoo box):
      >
      > WARNING: at kernel/lockdep.c:2658 check_flags()
      > Pid: 21680, comm: conftest Not tainted 2.6.24-rc6 #63
      >
      > Call Trace:
      >  [<ffffffff80253457>] check_flags+0x1c7/0x1d0
      >  [<ffffffff80257217>] lock_acquire+0x57/0xc0
      >  [<ffffffff8024d5c0>] __atomic_notifier_call_chain+0x60/0xd0
      >  [<ffffffff8024d641>] atomic_notifier_call_chain+0x11/0x20
      >  [<ffffffff8024d67e>] notify_die+0x2e/0x30
      >  [<ffffffff8020da0a>] do_divide_error+0x5a/0xa0
      >  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      >  [<ffffffff80255b89>] trace_hardirqs_on+0xd9/0x180
      >  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      >  [<ffffffff80523c2d>] error_exit+0x0/0xa9
      >
      > possible reason: unannotated irqs-off.
      > irq event stamp: 4693
      > hardirqs last  enabled at (4693): [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      > hardirqs last disabled at (4692): [<ffffffff80522c17>] trace_hardirqs_off_thunk+0x35/0x37
      > softirqs last  enabled at (3546): [<ffffffff80238343>] __do_softirq+0xb3/0xd0
      > softirqs last disabled at (3521): [<ffffffff8020c97c>] call_softirq+0x1c/0x30
      
      more early fixups for notify_die()..
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fb1dac90
  12. 27 11月, 2007 2 次提交
    • P
      lockdep: annotate do_debug() trap handler · 000f4a9e
      Peter Zijlstra 提交于
      Ensure the hardirq state is consistent before using locks. Use the rare
      trace_hardirqs_fixup() because the trap can happen in any context.
      
      resolves this rare lockdep warning:
      
      WARNING: at kernel/lockdep.c:2658 check_flags()
       [<c013571e>] check_flags+0x90/0x140
       [<c0138a69>] lock_release+0x4b/0x1d0
       [<c0507fea>] notifier_call_chain+0x2a/0x47
       [<c050806b>] __atomic_notifier_call_chain+0x64/0x6d
       [<c0508007>] __atomic_notifier_call_chain+0x0/0x6d
       [<c050808b>] atomic_notifier_call_chain+0x17/0x1a
       [<c0131802>] notify_die+0x30/0x34
       [<c0506b09>] do_debug+0x3e/0xd4
       [<c050658f>] debug_stack_correct+0x27/0x2c
       [<c04be389>] tcp_rcv_established+0x1/0x620
       [<c04c38c2>] tcp_v4_do_rcv+0x2b/0x313
       [<c04c56b6>] tcp_v4_rcv+0x467/0x85d
       [<c0505ff2>] _spin_lock_nested+0x27/0x32
       [<c04c5a4d>] tcp_v4_rcv+0x7fe/0x85d
       [<c04c560e>] tcp_v4_rcv+0x3bf/0x85d
       [<c04adbb5>] ip_local_deliver_finish+0x11b/0x1b0
       [<c04adac8>] ip_local_deliver_finish+0x2e/0x1b0
       [<c04ada7b>] ip_rcv_finish+0x27b/0x29a
       [<c04961e5>] netif_receive_skb+0xfb/0x2a6
       [<c04add0f>] ip_rcv+0x0/0x1fb
       [<c0496354>] netif_receive_skb+0x26a/0x2a6
       [<c04961e5>] netif_receive_skb+0xfb/0x2a6
       [<c049872e>] process_backlog+0x7f/0xc6
       [<c04983ba>] net_rx_action+0xb9/0x1ac
       [<c0498348>] net_rx_action+0x47/0x1ac
       [<c01376cb>] trace_hardirqs_on+0x118/0x16b
       [<c01225e2>] __do_softirq+0x49/0xa2
       [<c010595f>] do_softirq+0x60/0xdd
       [<c0506300>] _spin_unlock_irq+0x20/0x2c
       [<c0103e4f>] restore_nocheck+0x12/0x15
       [<c01440e1>] handle_fasteoi_irq+0x0/0x9b
       [<c0105a70>] do_IRQ+0x94/0xaa
       [<c0506300>] _spin_unlock_irq+0x20/0x2c
       [<c0104832>] common_interrupt+0x2e/0x34
       [<c0114703>] native_safe_halt+0x2/0x3
       [<c0102c01>] default_idle+0x44/0x65
       [<c010257f>] cpu_idle+0x42/0x50
       [<c076ea09>] start_kernel+0x26b/0x270
       [<c076e317>] unknown_bootoption+0x0/0x196
       =======================
      irq event stamp: 559190
      hardirqs last  enabled at (559190): [<c0507316>] kprobe_exceptions_notify+0x299/0x305
      hardirqs last disabled at (559189): [<c05067bf>] do_int3+0x1d/0x95
      softirqs last  enabled at (559172): [<c010595f>] do_softirq+0x60/0xdd
      softirqs last disabled at (559181): [<c010595f>] do_softirq+0x60/0xdd
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      000f4a9e
    • A
      x86: printk kernel version in WARN_ON and other dump_stack users · 57c351de
      Arjan van de Ven 提交于
      today, all oopses contain a version number of the kernel, which is nice
      because the people who actually do bother to read the oops get this
      vital bit of information always without having to ask the reporter in
      another round trip.
      
      However, WARN_ON() and many other dump_stack() users right now lack this
      information; the patch below adds this. This information is essential
      for getting people to use their time effectively when looking at these
      things; in addition, it's essential for tools that try to collect
      statistics about defects.
      
      Please consider, since its so simple and important for long term kernel
      quality processes.
      
      The code is identical between 32/64 bit; a lot of this code should be
      unified over time, the patch keeps the identical-ness intact.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      57c351de