linux-kernel - Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

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: <20130813171324.GB8805@cantiga.alporthouse.com>
Date:	Tue, 13 Aug 2013 18:13:24 +0100
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Sedat Dilek <sedat.dilek@...il.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Dave Airlie <airlied@...il.com>,
	DRI <dri-devel@...ts.freedesktop.org>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	"s.dilek" <s.dilek@...erlin.de>
Subject: Re: linux-next: Tree for Aug 13 [ screen corruption in graphical
 mode ]

On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
> >>> >
> >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
> >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829
> >>> > Author: Chris Wilson <chris@...is-wilson.co.uk>
> >>> > Date:   Thu Aug 8 14:41:07 2013 +0100
> >>> >
> >>> >     drm/i915: Allocate LLC ringbuffers from stolen
> >>> >
> >>> >     As stolen objects now behave identically (wrt to default LLC cacheing)
> >>> >     as their normal system counterparts, we no longer have to differentiate
> >>> >     our usage for ringbuffers. So allocate them from stolen on SNB+ as well.
> >>> >
> >>> >     Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
> >>> >     Reviewed-by: Ville Syrjälä <ville.syrjala@...ux.intel.com>
> >>> >     Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
> >>> >
> >>> > :040000 040000 de063a052f39095f4d2f51b49caef9f827df41e8
> >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M      drivers
> >>> >
> >>> > See also attached files!
> >>> >
> >>>
> >>> With the attached revert-patch my system is OK (with my customized X stack).
> >>
> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the
> >> scanout being misread.
> >>
> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen
> >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
> >>
> >> would be interesting.

> Attached both outputs with GOOD and BAD (BROKEN) kernel.

ggtt offset is the same for both setups, the only difference between the
two is the location of fbcon in stolen memory.

Can you please attach the output of intel_reg_dumper for good/bad? It's
a long shot...

Speaking of long shots, try this (slightly different to the earlier patch):

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index a21f935..37ad772 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
                BUG();
        }
 
+       if (obj->stolen && INTEL_INFO(dev)->gen >= 6)
+               alignment = 256 * 1024;
+
        /* Note that the w/a also requires 64 PTE of padding following the
         * bo. We currently fill all unused PTE with the shadow page and so
         * we should always have valid PTE following the scanout preventing


-- 
Chris Wilson, Intel Open Source Technology Centre
--
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/