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

[Knut Petersen <Knut_Petersen@t-online.de>]

Am 17.03.2011 17:55, schrieb Linus Torvalds:
>
> 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?
Takashi Iwai already gave a solution for the irq inversion problem.

> 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.
>
Well, I think there are two i915 problems that are independent.

The i2c/edid thing might be related to the f5a...commit, but reverting
that commit alone does not help. i2c/edid error messages might be before
or after the "gpu hung" problem, Xorg seems to be able to cope with that.
But after a gpu lockup it's time to reboot.

If nobody has a better idea I'll try to bisect ... tomorrow.

cu,
 Knut