On Thu, 24 Apr 2014, Pavel Machek wrote:
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00002034 tail 00000000 start 0012f000
Jiri has been seeing a similar issue creep in during resume, but it is not reliable enough to bisect. Is your boot failure reliable enough to bisect? Also drm-intel-nightly should mitigate this failure and allow i915.ko to continue to load and run X, which would be worth testing to make sure that works as intended.
Oh right, g4x going beserk :( Apparently something changed in 3.15 somewhere which made this much more likely, but like Chris said in Jiri's case it's too unreliable to reproduce for a bisect. We've had this come&go pretty much ever since kms support was merged and never tracked it down.
So far I went back to 3.14, and yes, graphics works there.
Back to 3.15, put it to smaller monitor. This time, top 30% of screen works, and last working scanline is copied to the rest 60% of screen. [With the exception of mouse cursor, that somehow affects that magically.]
The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
Like Chris said please test latest drm-intel-nighlty from http://cgit.freedesktop.org/drm-intel to make sure that the recently merged mitigation measures work properly. But those won't get your gpu back, only the display and it's only for 3.16. We're still hunting a proper fix for 3.15.
So you know where the bug is or not?
No, but there is a workaround for cases kernel finds out that it cannot execute GPU commands (because the rings failed to initialize), and instead it falls back to CPU rendering directly into the framebuffer.
So it's highly sub-optimal, but works around the complete wreckage.