Messages in this thread | | | Date | Thu, 14 Feb 2013 00:20:24 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [-rc7 regression] Block IO/VFS/ext3/timer spinlock lockup? |
| |
On Wed, 13 Feb 2013, Linus Torvalds wrote:
> On Wed, Feb 13, 2013 at 3:10 AM, Ingo Molnar <mingo@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
| |