lkml.org 
[lkml]   [2013]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [-rc7 regression] Block IO/VFS/ext3/timer spinlock lockup?

    * Thomas Gleixner <tglx@linutronix.de> wrote:

    > 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?

    CPU0 appears to be idle:

    [ 118.510000] Call Trace:
    [ 118.510000] [<7900844b>] cpu_idle+0x86/0xb4
    [ 118.510000] [<792a91df>] rest_init+0x103/0x108
    [ 118.510000] [<794558cc>] start_kernel+0x2c7/0x2cc
    [ 118.510000] [<7945528e>] i386_start_kernel+0x44/0x46

    which suggests memory corruption - but, if then it's a special
    type of memory corruption because AFAIR I always saw similar
    patterns to the lockup, never other signs of memory corruption.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2013-02-14 16:21    [W:4.206 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site