[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwpFFg+Z28aZ=92bGdU+Va00j08BzL-2frtLarKWt=qOQ@mail.gmail.com>
Date: Thu, 14 Feb 2013 15:05:14 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>,
Thomas Gleixner <tglx@...utronix.de>,
Alexander Viro <viro@....linux.org.uk>,
"Theodore Ts'o" <tytso@....edu>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [-rc7 regression] Block IO/VFS/ext3/timer spinlock lockup?
On Wed, Feb 13, 2013 at 3:10 AM, Ingo Molnar <mingo@...nel.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
Btw, this is an entirely unrelated thing, but it just struck me: you
have CONFIG_DEBUG_LOCK_ALLOC in your config, so that spinlock has a
_name_, and the not-so-helpful "spin_dump()" is too stupid to even
bother to print it out.
Now, in this case, it doesn't much matter, since the callchain really
does end up showing pretty unambiguously what the lock is, but
shouldn't we print that lock name when we dump the lock information?
I dunno. Maybe the names aren't useful, and the callchain ends up
always making them redundant. But it seems an oversight in our debug
output.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists