<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - [GM45] boot-up broken in kernel 3.4.10 - screen stays blank (bad patch identified)" href="https://bugs.freedesktop.org/show_bug.cgi?id=54575#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - [GM45] boot-up broken in kernel 3.4.10 - screen stays blank (bad patch identified)" href="https://bugs.freedesktop.org/show_bug.cgi?id=54575">bug 54575</a> from <a class="email" href="mailto:eich@pdx.freedesktop.org" title="Egbert Eich <eich@pdx.freedesktop.org>"> Egbert Eich</a> <pre>This issue is fixed in the current upstream kernel, however it is definitely an issue in the 3.0.x longterm kernel: On some Q43/Q45 chipsets (device ID 0x2e12) this issue doesn't only happen occasionally but permanently. It turns out that the two upstream commits: commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 Author: Sean Paul <<a href="mailto:seanpaul@chromium.org">seanpaul@chromium.org</a>> Date: Fri Mar 16 12:43:22 2012 -0400 drm/i915: Add wait_for in init_ring_common I have seen a number of "blt ring initialization failed" messages where the ctl or start registers are not the correct value. Upon further inspection, if the code just waited a little bit, it would read the correct value. Adding the wait_for to these reads should eliminate the issue. and commit 3eef8918ff440837f6af791942d8dd07e1a268ee Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> Date: Mon Jun 4 17:05:40 2012 +0100 drm/i915: Mark the ringbuffers as being in the GTT domain By correctly describing the rinbuffers as being in the GTT domain, it appears that we are more careful with the management of the CPU cache upon resume and so prevent some coherency issue when submitting commands to the GPU later. A secondary effect is that the debug logs are then consistent with the actual usage (i.e. they no longer describe the ringbuffers as being in the CPU write domain when we are accessing them through an wc iomapping.) are needed to fix this issue. Both commits are part of 3.2.x and 3.4.x stable however not of 3.0.x. Commit b7884eb45ec98c0d34c7f49005ae9d4b4b4e38f6 may also be useful to have, however in the context of the hardware that I have tested it is not required. Will notify stable@</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>