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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site