linux-kernel - Re: [ 04/16] drm/i915: correctly order the ring init sequence

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120821051318.GB3625@herton-Z68MA-D2H-B3>
Date:	Tue, 21 Aug 2012 02:13:19 -0300
From:	Herton Ronaldo Krzesinski <herton.krzesinski@...onical.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Jani Nikula <jani.nikula@...el.com>,
	Yang Guang <guang.a.yang@...el.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [ 04/16] drm/i915: correctly order the ring init sequence

On Sun, Aug 19, 2012 at 08:56:03PM -0700, Greg Kroah-Hartman wrote:
> From: Greg KH <gregkh@...uxfoundation.org>
> 
> 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Daniel Vetter <daniel.vetter@...ll.ch>
> 
> commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream.
> 
> We may only start to set up the new register values after having
> confirmed that the ring is truely off. Otherwise the hw might lose the
> newly written register values. This is caught later on in the init
> sequence, when we check whether the register writes have stuck.
> 
> Reviewed-by: Jani Nikula <jani.nikula@...el.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
> Tested-by: Yang Guang <guang.a.yang@...el.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
[...]

I had the same problem as on 3.2 with this change, i915 stopped working
unable to initialize render ring, eg. on one of the boots here:
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 head 00001020 tail 00000000 start 00001000 

But unlike I was expecting as with 3.2 case, picking commit
f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in
init_ring_common") here isn't enough, it continues to fail even if I
try to increase the delay in the wait_for, I'm not sure why yet... may
be something else is going on, or 3.0 has something else missing.

Also the same proposed patch for 3.4.10 gives the same problem, but
picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work
again like happend on first 3.2.28 proposed update. Only 3.0
is misteriously failing either way here.

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