On Wed, 13 Feb 2013, Linus Torvalds wrote:
> On Wed, Feb 13, 2013 at 3:10 AM, Ingo Molnar <mi...@kernel.org> wrote:
> >
> >
> > Setting up Logical Volume Management: [ 13.140000] BUG: spinlock lockup
> > suspected on CPU#1, lvm.static/139
> > [ 13.140000] BUG: spinlock lockup suspected on CPU#1, lvm.static/139
> > [ 13.140000] lock: 0x97fe9fc0, .magic: dead4ead, .owner: <none>/-1,
> > .owner_cpu: -1
> > [ 13.140000] Pid: 139, comm: lvm.static Not tainted 3.8.0-rc7 #216702
> > [ 13.140000] Call Trace:
> > [ 13.140000] [<792b5e66>] spin_dump+0x73/0x7d
> > [ 13.140000] [<7916a347>] do_raw_spin_lock+0xb2/0xe8
> > [ 13.140000] [<792b9412>] _raw_spin_lock_irqsave+0x35/0x3e
> > [ 13.140000] [<790391e8>] prepare_to_wait+0x18/0x57
>
> The wait-queue spinlock? That sounds *very* unlikely to deadlock due
> to any bugs in block layer or filesystems. There are never any
> downcalls to those from within that spinlock or any other locks taken
> inside of it.
The way more interesting information is:
[ 13.140000] lock: 0x97fe9fc0, .magic: dead4ead, .owner: <none>/-1,
.owner_cpu: -1
That lock is not contended, which makes no sense at all. The only
explanation for such a behaviour would be a tight spin_lock/unlock
loop on the other core which is exposed through the spinlock debugging
code (it uses trylocks instead of queueing in the ticket lock).
Ingo, can you provide the backtrace of CPU0 please?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
