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

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: <alpine.LRH.2.00.1404241555440.1491@twin.jikos.cz>
Date:	Thu, 24 Apr 2014 15:56:49 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Pavel Machek <pavel@....cz>
cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: 3.15-rc2: i915 regression: only top 20% of screen works in X

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

--
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/