Re: [BUG][2.6.38] IRQ Lock Inversion / i915 fails

[Linus Torvalds]

On Thu, Mar 17, 2011 at 2:40 AM, Knut Petersen
<Knut_Petersen@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/