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: <0e7529fa-6f48-fc31-8d25-18a836171d8c@posteo.de>
Date:   Mon, 7 Nov 2016 17:07:55 +0100
From:   Martin Kepplinger <martink@...teo.de>
To:     Martin Steigerwald <martin@...htvoll.de>
Cc:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        Joerg Roedel <jroedel@...e.de>,
        Linux kernel <linux-kernel@...r.kernel.org>,
        torvalds@...ux-foundation.org, daniel.vetter@...el.com
Subject: Re: [BUG][REGRESSION] mangled display since -rc1

Am 2016-11-07 um 17:01 schrieb Martin Steigerwald:
> Hello.
> 
> Am Montag, 7. November 2016, 16:34:35 CET schrieb Martin Kepplinger:
>> Am 2016-11-07 um 09:24 schrieb Jani Nikula:
>>> On Sun, 06 Nov 2016, Martin Kepplinger <martink@...teo.de> wrote:
>>>> I did not file a bug in bugzilla yet. I haven't given up that we can fix
>>>> this here before the release. I've ignored it the last few days though.
>>>
>>> You say it like filing the bug report and having the bug fixed are
>>> mutually exclusive things...
>>>
>>> Pretty please? It's easier for us to direct folks at the bug, with
>>> history and logs in one place. I realize only Daniel and me were Cc'd
>>> here, not intel-gfx list.
>>>
>>> Also, please double check your bisect. Not sure why the finger points at
>>> i915 when the bisect points at iommu merge.
> […]
>> Chris Clayton wrote off list and the mentioned patch fixes the problem
>> for me too, as it does for others. I hope it make it's way into the tree
>> soon:
> 
> With 4.9-rc4 I have corruptions that look like the ones reported in this 
> thread.
> 
> I reported my finding on LKML thread about 3.9-rc4. And in Bugzilla in a bug 
> report with an attachment that shows the same type of corruptions as here in 
> this thread:
> 
> https://patchwork.freedesktop.org/patch/116808/
> 
> mentioned in the other bug report and the following LKML thread does not fix 
> the issue for me:
> 
> Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: 
> Linux 4.9-rc4)
> https://lkml.org/lkml/2016/11/6/70
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=177701#c4
> 
> 
> In my case it looks like this:
> 
> https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> 
> 
>  I have a busy week, so I won´t to any bisecting at the moment. I am happy to 
> test another patch during breaks between holding the training, but please 
> point me specifically to what patch to test. Thank you.

this one: I just replaced max with roundup manually:

diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index c642385bb236..a52b40bbac6f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1837,7 +1837,7 @@ int i915_gem_fault(struct vm_area_struct *area,
struct vm_fault *vmf)
                /* Use a partial view if it is bigger than available
space */
                chunk_size = MIN_CHUNK_PAGES;
                if (i915_gem_object_is_tiled(obj))
-                       chunk_size = max(chunk_size, tile_row_pages(obj));
+                       chunk_size = roundup(chunk_size,
tile_row_pages(obj));
                 memset(&view, 0, sizeof(view));
                view.type = I915_GGTT_VIEW_PARTIAL;


> 
> 
> In general I am a bit confused about:
> 
> 1) when do I use the bugtracker
> 
> 2) when to just post on LKML
> 
> 3) and which bugtracker to use? bugzilla.kernel.org versus the freedesktop one 
> in this case. See:
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1611.0/03126.html
> 
> 4) how to determine whether a bug report matches my case or not. In that case 
> its easy enough considering the screenshots.
> 
> (using this list archive as threading view in lkml.org seems broken)
> 
> This bug is already being discussed in three places right now, I bet it makes 
> sense to settle on one place. I´d opt for Bugzilla but I would like to use my 
> MUA to access it for simple comments.

whatever, it's a mess :) that's what the kernel summit is for, right?

> 
> Thanks,
> Martin
> 
>> -------- Weitergeleitete Nachricht --------
>> Betreff: Fwd: Re: Redraw issues on i915 on 4.9-rc
>> Datum: Mon, 7 Nov 2016 13:48:14 +0000
>> Von: Chris Clayton <chris2553@...glemail.com>
>> An: martink@...teo.de
>>
>> Hi Martin.
>>
>>
>> I can't contact you through LKML because I'm not subscribed, but I've
>> been working with Chris Wilson, one of the Intel
>> DRM developers to analyse and fix the corruption. We've got a patch that
>> fixes it for me and Norbert who also reported
>> the problem. The patch is at the bottom of this message.
>>
>> Hope it helps.
>>
>> Chris
>>
>>
>> -------- Forwarded Message --------
>> Subject: Re: Redraw issues on i915 on 4.9-rc
>> Date: Mon, 7 Nov 2016 09:25:59 +0000
>> From: Chris Wilson <chris@...is-wilson.co.uk>
>> To: Chris Clayton <chris2553@...glemail.com>
>> CC: Norbert Preining <preining@...ic.at>
>>
>> On Mon, Nov 07, 2016 at 09:16:38AM +0000, Chris Clayton wrote:
>>> Hello again.
>>>
>>> I wasn't at all happy about the last bisect I did, so I've run it
>>
>> again and this time spent at least 30 minutes using my
>>
>>> system before marking a kernel as good. I've also noticed that when I
>>
>> boot a bad kernel, the graphics associated with
>>
>>> three of my desktop icons do not get drawn, so that helps.
>>>
>>> The outcome of the bisection is:
>>>
>>> a61007a83a4671da77210790997d5c8c92ed87ea is the first bad commit
>>> commit a61007a83a4671da77210790997d5c8c92ed87ea
>>> Author: Chris Wilson <chris@...is-wilson.co.uk>
>>> Date:   Thu Aug 18 17:17:02 2016 +0100
>>>
>>>     drm/i915: Fix partial GGTT faulting
>>
>> That's just the enabling patch, everything was meant to be in place by
>> then.
>>
>> Oh noes, care to try:
>>
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index c642385bb236..a52b40bbac6f 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -1837,7 +1837,7 @@ int i915_gem_fault(struct vm_area_struct *area,
>> struct vm_fault *vmf)
>>                 /* Use a partial view if it is bigger than available
>> space */
>>                 chunk_size = MIN_CHUNK_PAGES;
>>                 if (i915_gem_object_is_tiled(obj))
>> -                       chunk_size = max(chunk_size, tile_row_pages(obj));
>> +                       chunk_size = roundup(chunk_size,
>> tile_row_pages(obj));
>>                  memset(&view, 0, sizeof(view));
>>                 view.type = I915_GGTT_VIEW_PARTIAL;
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ