On Thu, Dec 8, 2011 at 4:49 AM, Kai Meyer <[email protected]> wrote: > I'm getting this when I try to spin_unlock a recently acquired lock with > spin_lock. IRQs are still somewhat of a mystery to me, and cryptic lock > state symbols (IN-HARDIRQ-W, HARDIRQ-ON-W) are unintelligible to me. > > Dec 7 15:52:20 dev2 kernel: ================================= > Dec 7 15:52:20 dev2 kernel: [ INFO: inconsistent lock state ] > Dec 7 15:52:20 dev2 kernel: 2.6.32-220.el6.x86_64.debug #1 > Dec 7 15:52:20 dev2 kernel: --------------------------------- > Dec 7 15:52:20 dev2 kernel: inconsistent {IN-HARDIRQ-W} -> > {HARDIRQ-ON-W} usage. > > Looking at lockdep.c isn't giving me any help either. It's obfuscated > beyond my ability to grok by simply reading the code. > > It seems like this portion should help me, but it doesn't.... > Dec 7 15:52:20 dev2 kernel: {IN-HARDIRQ-W} state was registered at: > Dec 7 15:52:20 dev2 kernel: [<ffffffff810afbca>] > __lock_acquire+0x77a/0x1570 > Dec 7 15:52:20 dev2 kernel: [<ffffffff810b0a64>] lock_acquire+0xa4/0x120 > Dec 7 15:52:20 dev2 kernel: [<ffffffff81520c75>] > _spin_lock_irqsave+0x55/0xa0 > Dec 7 15:52:20 dev2 kernel: [<ffffffffa006b19b>] blk_done+0x2b/0x110 > [virtio_blk] > Dec 7 15:52:20 dev2 kernel: [<ffffffffa00401dc>] > vring_interrupt+0x3c/0xd0 [virtio_ring] > Dec 7 15:52:20 dev2 kernel: [<ffffffff810ec080>] > handle_IRQ_event+0x50/0x160 > Dec 7 15:52:20 dev2 kernel: [<ffffffff810ee840>] > handle_edge_irq+0xe0/0x170 > Dec 7 15:52:20 dev2 kernel: [<ffffffff8100e059>] handle_irq+0x49/0xa0 > Dec 7 15:52:20 dev2 kernel: [<ffffffff81526cdc>] do_IRQ+0x6c/0xf0 > Dec 7 15:52:20 dev2 kernel: [<ffffffff8100ba93>] ret_from_intr+0x0/0x16 > Dec 7 15:52:20 dev2 kernel: [<ffffffff810148e2>] default_idle+0x52/0xc0 > Dec 7 15:52:20 dev2 kernel: [<ffffffff81009e0b>] cpu_idle+0xbb/0x110 > Dec 7 15:52:20 dev2 kernel: [<ffffffff81516623>] > start_secondary+0x211/0x254 > > Then later it tells me that I'm holding 1 lock, which is the one that I > mentioned at the beginning that was just recently locked. > > 2 things: 1. Documentation/lockdep-design.txt explains the "cryptic lock state symbols". 2. Please post the lockdep splat _exactly_ as it appears, and _in full_ (and without line-wrapping, if possible). Usually lockdep is intelligent enough to tell you the possible scenario that would lock up your system. That gives a very good clue, in case you find it difficult to make out what is wrong from the cryptic symbols.
Regards, Srivatsa S. Bhat
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
