lkml.org 
[lkml]   [2011]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [BUG][2.6.38] IRQ Lock Inversion / i915 fails
    On Thu, Mar 17, 2011 at 2:40 AM, Knut Petersen
    <Knut_Petersen@t-online.de> wrote:
    >
    > Well, I updated my test partition to opensuse 11.4.
    >
    > The opensuse standard kernel is unusable for me, booting hangs
    > most of the time, the same is true for shutdown. If booting succeeds the
    > system will fail after a short time of usage.
    >
    > So I installed kernel 2.6.38.  That helped a lot ... for a few minutes.
    >
    > A possible irq lock inversion is detected during boot, after a short time
    > X fails, restarting the X server does not work, a reboot is necessary.

    Ok, so the lock inversion seems to be due to the sound/drivers/aloop.c
    file, where the function "loopback_pos_update()" gets called from
    within a softirq context. And it takes a lock (cable->lock) that is
    also taken unprotected by loopback_trigger(). So that's liable to
    deadlock as per lockdep. Jaroslav? Takashi?

    The X problem seems to be something unrelated. You have those "GPU
    hung" messages, along with i2c/EDID problems. But the actual oops is
    at the very beginning of intel_release_load_detect_pipe(), here:

    0: 55 push %ebp
    1: 89 e5 mov %esp,%ebp
    3: 57 push %edi
    4: 89 cf mov %ecx,%edi
    6: 56 push %esi
    7: 53 push %ebx
    8: 89 c3 mov %eax,%ebx
    a: 83 ec 0c sub $0xc,%esp
    d: 8b 00 mov (%eax),%eax
    f: 8b 73 20 mov 0x20(%ebx),%esi
    12: 80 7b 30 00 cmpb $0x0,0x30(%ebx)
    16: 8b 4b 28 mov 0x28(%ebx),%ecx
    19: 89 45 f0 mov %eax,-0x10(%ebp)
    1c:* 8b 86 e0 01 00 00 mov 0x1e0(%esi),%eax <-- trapping
    instruction
    22: 89 45 ec mov %eax,-0x14(%ebp)
    25: 74 2d je 0x54
    27: c7 43 20 00 00 00 00 movl $0x0,0x20(%ebx)
    2e: 89 f0 mov %esi,%eax

    where %esi is NULL. I think that is the "crtc->helper_private" load,
    and crtc is NULL.

    That code does look broken. The very same function explicitly sets
    crtc to NULL, so clearly it _can_ be NULL. That said, this is all old
    code. I suspect the thing that made it start trigger may be commit
    f5afcd3dd0dc ("drm/i915/crt: Check for a analog monitor in case of
    DVI-I"), which is the only real change to the crt_detect logic I can
    see.

    Jesse? Chris? Ideas?

    Linus
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-03-17 17:59    [W:0.026 / U:1.212 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site