1. 18 7月, 2008 1 次提交
  2. 09 7月, 2008 6 次提交
  3. 08 7月, 2008 3 次提交
  4. 13 6月, 2008 1 次提交
    • V
      x86, lockdep: fix "WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()" · 4461145e
      Vegard Nossum 提交于
      Alessandro Suardi reported:
      > Recently upgraded my FC6 desktop to Fedora 9; with the
      >  latest nautilus RPM updates my VNC session went nuts
      >  with nautilus pegging the CPU for everything that breathed.
      >
      > I now reverted to an earlier nautilus package, but during
      >  the peak CPU period my kernel spat this:
      >
      > [314185.623294] ------------[ cut here ]------------
      > [314185.623414] WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()
      > [314185.623514] Modules linked in: iptable_filter ip_tables x_tables
      > sunrpc ipv6 fuse snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart
      > snd_rawmidi via686a hwmon parport_pc sg parport uhci_hcd ehci_hcd
      > [314185.623924] Pid: 12314, comm: nautilus Not tainted 2.6.26-rc5-git2 #4
      > [314185.624021]  [<c0115b95>] warn_on_slowpath+0x41/0x7b
      > [314185.624021]  [<c010de70>] ? do_page_fault+0x2c1/0x5fd
      > [314185.624021]  [<c0128396>] ? up_read+0x16/0x28
      > [314185.624021]  [<c010de70>] ? do_page_fault+0x2c1/0x5fd
      > [314185.624021]  [<c012fa33>] ? __lock_acquire+0xbb4/0xbc3
      > [314185.624021]  [<c012d0a0>] check_flags+0x4c/0x128
      > [314185.624021]  [<c012fa73>] lock_acquire+0x31/0x7d
      > [314185.624021]  [<c0128cf6>] __atomic_notifier_call_chain+0x30/0x80
      > [314185.624021]  [<c0128cc6>] ? __atomic_notifier_call_chain+0x0/0x80
      > [314185.624021]  [<c0128d52>] atomic_notifier_call_chain+0xc/0xe
      > [314185.624021]  [<c0128d81>] notify_die+0x2d/0x2f
      > [314185.624021]  [<c01043b0>] do_int3+0x1f/0x4d
      > [314185.624021]  [<c02f2d3b>] int3+0x27/0x2c
      > [314185.624021]  =======================
      > [314185.624021] ---[ end trace 1923f65a2d7bb246 ]---
      > [314185.624021] possible reason: unannotated irqs-off.
      > [314185.624021] irq event stamp: 488879
      > [314185.624021] hardirqs last  enabled at (488879): [<c0102d67>]
      > restore_nocheck+0x12/0x15
      > [314185.624021] hardirqs last disabled at (488878): [<c0102dca>]
      > work_resched+0x19/0x30
      > [314185.624021] softirqs last  enabled at (488876): [<c011a1ba>]
      > __do_softirq+0xa6/0xac
      > [314185.624021] softirqs last disabled at (488865): [<c010476e>]
      > do_softirq+0x57/0xa6
      >
      > I didn't seem to find it with some googling, so here it is.
      >
      > I was incidentally ltracing that process to try and find out
      >  what was gulping down that much CPU (sorry, no idea
      >  whether ltrace and the WARNING happened at the same
      >  time or which came first) and:
      
      Yeah, this is extremely likely to be the source of the warning.
      
      The warning should be harmless, however.
      
      > Box is my trusty noname K7-800, 512MB RAM; if there's
      >  anything else useful I might be able to provide, just ask.
      
      It would be interesting to see where the int3 comes from.  Too bad,
      lockdep doesn't provide the register dump. The stacktrace also doesn't
      go further than the int3(), I wonder if this int3 came from userspace?
      The ltrace readme says "software breakpoints, like gdb", so I guess
      this is the case. Yep, seems like it.
      
      This looks relevant:
      
      | commit fb1dac90
      | Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      | Date:   Wed Jan 16 09:51:59 2008 +0100
      |
      |     lockdep: more hardirq annotations for notify_die()
      
      I'm attaching a similarly-looking patch for this case (DO_VM86_ERROR),
      though I suspect it might be missing for the other cases
      (DO_ERROR/DO_ERROR_INFO) as well.
      Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4461145e
  5. 26 5月, 2008 1 次提交
  6. 26 4月, 2008 1 次提交
  7. 20 4月, 2008 3 次提交
  8. 18 4月, 2008 1 次提交
    • 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
  9. 17 4月, 2008 3 次提交
  10. 07 2月, 2008 1 次提交
  11. 30 1月, 2008 16 次提交
  12. 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
  13. 21 12月, 2007 1 次提交
    • I
      x86: fix die() to not be preemptible · c0a698b7
      Ingo Molnar 提交于
      Andrew "Eagle Eye" Morton noticed that we use raw_local_save_flags()
      instead of raw_local_irq_save(flags) in die(). This allows the
      preemption of oopsing contexts - which is highly undesirable. It also
      causes CONFIG_DEBUG_PREEMPT to complain, as reported by Miles Lane.
      
      this bug was introduced via:
      
        commit 39743c9e
        Author: Andi Kleen <ak@suse.de>
        Date:   Fri Oct 19 20:35:03 2007 +0200
      
            x86: use raw locks during oopses
      
      -               spin_lock_irqsave(&die.lock, flags);
      +               __raw_spin_lock(&die.lock);
      +               raw_local_save_flags(flags);
      
      that is not a correct open-coding of spin_lock_irqsave(): both the
      ordering is wrong (irqs should be disabled _first_), and the wrong
      flags-saving API was used.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c0a698b7
  14. 27 11月, 2007 1 次提交
    • 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