3.15-rc2: i915 regression: only top 20% of screen works in X

[Jiri Kosina]

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.

-- 
Jiri Kosina
SUSE Labs