Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-13 Thread Martin Kepplinger 
Am 2016-11-07 um 18:36 schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Kepplinger  wrote:
>> Am 2016-11-07 um 17:01 schrieb Martin Steigerwald:
>>> Hello.
>>>
>>> Am Montag, 7. November 2016, 16:34:35 CET schrieb Martin Kepplinger:
 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
> 
> That bug conflates two issues, with the main issue being unrelated to
> corruption.
> 
>>> 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:
> 
> As I wrote in another thread, the fix has now been pushed to
> drm-intel-fixes branch of http://cgit.freedesktop.org/drm-intel. It's
> -rc4 plus half a dozen fixes, including "drm/i915: Round tile chunks up
> for constructing partial VMAs" which should fix the corruption.
> 
> Please try that, and report back. If it doesn't fix the issue, please
> file a bug at the freedesktop.org bugzilla.
> 
> BR,
> Jani.
> 
Fixed in -rc5, thanks!

   martin

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-13 Thread Martin Kepplinger 
Am 2016-11-07 um 18:36 schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Kepplinger  wrote:
>> Am 2016-11-07 um 17:01 schrieb Martin Steigerwald:
>>> Hello.
>>>
>>> Am Montag, 7. November 2016, 16:34:35 CET schrieb Martin Kepplinger:
 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
> 
> That bug conflates two issues, with the main issue being unrelated to
> corruption.
> 
>>> 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:
> 
> As I wrote in another thread, the fix has now been pushed to
> drm-intel-fixes branch of http://cgit.freedesktop.org/drm-intel. It's
> -rc4 plus half a dozen fixes, including "drm/i915: Round tile chunks up
> for constructing partial VMAs" which should fix the corruption.
> 
> Please try that, and report back. If it doesn't fix the issue, please
> file a bug at the freedesktop.org bugzilla.
> 
> BR,
> Jani.
> 
Fixed in -rc5, thanks!

   martin

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread Jani Nikula 
On Mon, 07 Nov 2016, Martin Kepplinger  wrote:
> Am 2016-11-07 um 17:01 schrieb Martin Steigerwald:
>> Hello.
>> 
>> Am Montag, 7. November 2016, 16:34:35 CET schrieb Martin Kepplinger:
>>> 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

That bug conflates two issues, with the main issue being unrelated to
corruption.

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

As I wrote in another thread, the fix has now been pushed to
drm-intel-fixes branch of http://cgit.freedesktop.org/drm-intel. It's
-rc4 plus half a dozen fixes, including "drm/i915: Round tile chunks up
for constructing partial VMAs" which should fix the corruption.

Please try that, and report back. If it doesn't fix the issue, please
file a bug at the freedesktop.org bugzilla.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread Jani Nikula 
On Mon, 07 Nov 2016, Martin Kepplinger  wrote:
> Am 2016-11-07 um 17:01 schrieb Martin Steigerwald:
>> Hello.
>> 
>> Am Montag, 7. November 2016, 16:34:35 CET schrieb Martin Kepplinger:
>>> 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

That bug conflates two issues, with the main issue being unrelated to
corruption.

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

As I wrote in another thread, the fix has now been pushed to
drm-intel-fixes branch of http://cgit.freedesktop.org/drm-intel. It's
-rc4 plus half a dozen fixes, including "drm/i915: Round tile chunks up
for constructing partial VMAs" which should fix the corruption.

Please try that, and report back. If it doesn't fix the issue, please
file a bug at the freedesktop.org bugzilla.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread Martin Kepplinger 
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  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(, 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 +
>> Von: Chris Clayton 
>> An: mart...@posteo.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 +
>> From: Chris Wilson 
>> To: Chris Clayton 
>> CC: Norbert Preining 
>>
>> On Mon, Nov 07, 2016 at 09:16:38AM +, 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

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread Martin Kepplinger 
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  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(, 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 +
>> Von: Chris Clayton 
>> An: mart...@posteo.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 +
>> From: Chris Wilson 
>> To: Chris Clayton 
>> CC: Norbert Preining 
>>
>> On Mon, Nov 07, 2016 at 09:16:38AM +, 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 
>>> Date:   Thu Aug 18 17:17:02 2016 +0100
>>>
>>> drm/i915: Fix partial GGTT faulting
>>
>> That's just the enabling patch,

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread 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  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.


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.

Thanks,
Martin

>  Weitergeleitete Nachricht 
> Betreff: Fwd: Re: Redraw issues on i915 on 4.9-rc
> Datum: Mon, 7 Nov 2016 13:48:14 +
> Von: Chris Clayton 
> An: mart...@posteo.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 +
> From: Chris Wilson 
> To: Chris Clayton 
> CC: Norbert Preining 
> 
> On Mon, Nov 07, 2016 at 09:16:38AM +, 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 
> > 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(, 0, sizeof(view));
> view.type = I915_GGTT_VIEW_PARTIAL;


-- 
Martin

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread 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  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.


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.

Thanks,
Martin

>  Weitergeleitete Nachricht 
> Betreff: Fwd: Re: Redraw issues on i915 on 4.9-rc
> Datum: Mon, 7 Nov 2016 13:48:14 +
> Von: Chris Clayton 
> An: mart...@posteo.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 +
> From: Chris Wilson 
> To: Chris Clayton 
> CC: Norbert Preining 
> 
> On Mon, Nov 07, 2016 at 09:16:38AM +, 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 
> > 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(, 0, sizeof(view));
> view.type = I915_GGTT_VIEW_PARTIAL;


-- 
Martin

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread Martin Kepplinger 
Am 2016-11-07 um 09:24 schrieb Jani Nikula:
> On Sun, 06 Nov 2016, Martin Kepplinger  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.
> 
> 
> BR,
> Jani.
> 
> 

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:


 Weitergeleitete Nachricht 
Betreff: Fwd: Re: Redraw issues on i915 on 4.9-rc
Datum: Mon, 7 Nov 2016 13:48:14 +
Von: Chris Clayton 
An: mart...@posteo.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 +
From: Chris Wilson 
To: Chris Clayton 
CC: Norbert Preining 

On Mon, Nov 07, 2016 at 09:16:38AM +, 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 
> 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(, 0, sizeof(view));
view.type = I915_GGTT_VIEW_PARTIAL;

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread Martin Kepplinger 
Am 2016-11-07 um 09:24 schrieb Jani Nikula:
> On Sun, 06 Nov 2016, Martin Kepplinger  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.
> 
> 
> BR,
> Jani.
> 
> 

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:


 Weitergeleitete Nachricht 
Betreff: Fwd: Re: Redraw issues on i915 on 4.9-rc
Datum: Mon, 7 Nov 2016 13:48:14 +
Von: Chris Clayton 
An: mart...@posteo.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 +
From: Chris Wilson 
To: Chris Clayton 
CC: Norbert Preining 

On Mon, Nov 07, 2016 at 09:16:38AM +, 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 
> 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(, 0, sizeof(view));
view.type = I915_GGTT_VIEW_PARTIAL;

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread Jani Nikula 
On Sun, 06 Nov 2016, Martin Kepplinger  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.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-07 Thread Jani Nikula 
On Sun, 06 Nov 2016, Martin Kepplinger  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.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-06 Thread Martin Kepplinger 
Am 2016-11-06 um 12:43 schrieb Martin Kepplinger:
> Am 2016-11-06 um 12:21 schrieb Thorsten Leemhuis:
>> On 01.11.2016 12:47, Jani Nikula wrote:
>>> On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
 I'll come up with a nouveau system example and it was quite easy to 
 bisect. To quote the merge commit msg:
 This also required some changes outside of the IOMMU code, but these are 
 acked by the respective maintainers.
 Any help on bisecting into it would be awesome.
>>> So the information here is pretty scarce. Please file a bug at [1],
>>> describe the problem, perhaps add drm.debug=14 module parameter and
>>> attach dmesg from boot to reproducing the problem.
>>
>> Martin, did you do that and can point me to the bug? And if not: Any
>> news on the issue?
>>
>> FWIW: I added this report to the list of regressions for Linux 4.9. I'll
>> watch this thread for further updates on this issue to document progress
>> in my weekly reports. Please let me know via regressi...@leemhuis.info
>> in case the discussion moves to a different place (bugzilla or another
>> mail thread for example).
>>
>> tia! Ciao, Thorsten
>>
> 
> 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.
> 
> Again: This is the first bad commit:
> 
> [56e520c7a0a490b63b042b047ec9659fc08762a4] Merge tag
> 'iommu-updates-v4.9' of
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
> 
> If you know how to bisect into this, please share your thoughts. Linus'
> merge here is bigger than iommu-update-v4.9 i think and that's what I
> have to look at really. I'm not sure how though.
> 
> One part of the merge is indeed iiommu-updates-v4.9:
> 
> That's the tag:
> https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/tag/?h=iommu-updates-v4.9
> 
> and the tagged object:
> https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=iommu-updates-v4.9=13a08259187c5cd3f63d98efa159ab42976d85a4
> 
> I'll have to think about how to check the iommu-updates-v4.9 part of the
> merge again... to eliminate something.
> 
-rc4 is still bad. all still relevant :(

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-06 Thread Martin Kepplinger 
Am 2016-11-06 um 12:43 schrieb Martin Kepplinger:
> Am 2016-11-06 um 12:21 schrieb Thorsten Leemhuis:
>> On 01.11.2016 12:47, Jani Nikula wrote:
>>> On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
 I'll come up with a nouveau system example and it was quite easy to 
 bisect. To quote the merge commit msg:
 This also required some changes outside of the IOMMU code, but these are 
 acked by the respective maintainers.
 Any help on bisecting into it would be awesome.
>>> So the information here is pretty scarce. Please file a bug at [1],
>>> describe the problem, perhaps add drm.debug=14 module parameter and
>>> attach dmesg from boot to reproducing the problem.
>>
>> Martin, did you do that and can point me to the bug? And if not: Any
>> news on the issue?
>>
>> FWIW: I added this report to the list of regressions for Linux 4.9. I'll
>> watch this thread for further updates on this issue to document progress
>> in my weekly reports. Please let me know via regressi...@leemhuis.info
>> in case the discussion moves to a different place (bugzilla or another
>> mail thread for example).
>>
>> tia! Ciao, Thorsten
>>
> 
> 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.
> 
> Again: This is the first bad commit:
> 
> [56e520c7a0a490b63b042b047ec9659fc08762a4] Merge tag
> 'iommu-updates-v4.9' of
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
> 
> If you know how to bisect into this, please share your thoughts. Linus'
> merge here is bigger than iommu-update-v4.9 i think and that's what I
> have to look at really. I'm not sure how though.
> 
> One part of the merge is indeed iiommu-updates-v4.9:
> 
> That's the tag:
> https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/tag/?h=iommu-updates-v4.9
> 
> and the tagged object:
> https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=iommu-updates-v4.9=13a08259187c5cd3f63d98efa159ab42976d85a4
> 
> I'll have to think about how to check the iommu-updates-v4.9 part of the
> merge again... to eliminate something.
> 
-rc4 is still bad. all still relevant :(

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-06 Thread Martin Kepplinger 
Am 2016-11-06 um 12:21 schrieb Thorsten Leemhuis:
> On 01.11.2016 12:47, Jani Nikula wrote:
>> On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
>>> I'll come up with a nouveau system example and it was quite easy to bisect. 
>>> To quote the merge commit msg:
>>> This also required some changes outside of the IOMMU code, but these are 
>>> acked by the respective maintainers.
>>> Any help on bisecting into it would be awesome.
>> So the information here is pretty scarce. Please file a bug at [1],
>> describe the problem, perhaps add drm.debug=14 module parameter and
>> attach dmesg from boot to reproducing the problem.
> 
> Martin, did you do that and can point me to the bug? And if not: Any
> news on the issue?
> 
> FWIW: I added this report to the list of regressions for Linux 4.9. I'll
> watch this thread for further updates on this issue to document progress
> in my weekly reports. Please let me know via regressi...@leemhuis.info
> in case the discussion moves to a different place (bugzilla or another
> mail thread for example).
> 
> tia! Ciao, Thorsten
> 

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.

Again: This is the first bad commit:

[56e520c7a0a490b63b042b047ec9659fc08762a4] Merge tag
'iommu-updates-v4.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

If you know how to bisect into this, please share your thoughts. Linus'
merge here is bigger than iommu-update-v4.9 i think and that's what I
have to look at really. I'm not sure how though.

One part of the merge is indeed iiommu-updates-v4.9:

That's the tag:
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/tag/?h=iommu-updates-v4.9

and the tagged object:
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=iommu-updates-v4.9=13a08259187c5cd3f63d98efa159ab42976d85a4

I'll have to think about how to check the iommu-updates-v4.9 part of the
merge again... to eliminate something.

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-06 Thread Martin Kepplinger 
Am 2016-11-06 um 12:21 schrieb Thorsten Leemhuis:
> On 01.11.2016 12:47, Jani Nikula wrote:
>> On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
>>> I'll come up with a nouveau system example and it was quite easy to bisect. 
>>> To quote the merge commit msg:
>>> This also required some changes outside of the IOMMU code, but these are 
>>> acked by the respective maintainers.
>>> Any help on bisecting into it would be awesome.
>> So the information here is pretty scarce. Please file a bug at [1],
>> describe the problem, perhaps add drm.debug=14 module parameter and
>> attach dmesg from boot to reproducing the problem.
> 
> Martin, did you do that and can point me to the bug? And if not: Any
> news on the issue?
> 
> FWIW: I added this report to the list of regressions for Linux 4.9. I'll
> watch this thread for further updates on this issue to document progress
> in my weekly reports. Please let me know via regressi...@leemhuis.info
> in case the discussion moves to a different place (bugzilla or another
> mail thread for example).
> 
> tia! Ciao, Thorsten
> 

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.

Again: This is the first bad commit:

[56e520c7a0a490b63b042b047ec9659fc08762a4] Merge tag
'iommu-updates-v4.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

If you know how to bisect into this, please share your thoughts. Linus'
merge here is bigger than iommu-update-v4.9 i think and that's what I
have to look at really. I'm not sure how though.

One part of the merge is indeed iiommu-updates-v4.9:

That's the tag:
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/tag/?h=iommu-updates-v4.9

and the tagged object:
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=iommu-updates-v4.9=13a08259187c5cd3f63d98efa159ab42976d85a4

I'll have to think about how to check the iommu-updates-v4.9 part of the
merge again... to eliminate something.

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-06 Thread Thorsten Leemhuis 
On 01.11.2016 12:47, Jani Nikula wrote:
> On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
>> I'll come up with a nouveau system example and it was quite easy to bisect. 
>> To quote the merge commit msg:
>> This also required some changes outside of the IOMMU code, but these are 
>> acked by the respective maintainers.
>> Any help on bisecting into it would be awesome.
> So the information here is pretty scarce. Please file a bug at [1],
> describe the problem, perhaps add drm.debug=14 module parameter and
> attach dmesg from boot to reproducing the problem.

Martin, did you do that and can point me to the bug? And if not: Any
news on the issue?

FWIW: I added this report to the list of regressions for Linux 4.9. I'll
watch this thread for further updates on this issue to document progress
in my weekly reports. Please let me know via regressi...@leemhuis.info
in case the discussion moves to a different place (bugzilla or another
mail thread for example).

tia! Ciao, Thorsten

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-06 Thread Thorsten Leemhuis 
On 01.11.2016 12:47, Jani Nikula wrote:
> On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
>> I'll come up with a nouveau system example and it was quite easy to bisect. 
>> To quote the merge commit msg:
>> This also required some changes outside of the IOMMU code, but these are 
>> acked by the respective maintainers.
>> Any help on bisecting into it would be awesome.
> So the information here is pretty scarce. Please file a bug at [1],
> describe the problem, perhaps add drm.debug=14 module parameter and
> attach dmesg from boot to reproducing the problem.

Martin, did you do that and can point me to the bug? And if not: Any
news on the issue?

FWIW: I added this report to the list of regressions for Linux 4.9. I'll
watch this thread for further updates on this issue to document progress
in my weekly reports. Please let me know via regressi...@leemhuis.info
in case the discussion moves to a different place (bugzilla or another
mail thread for example).

tia! Ciao, Thorsten

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-01 Thread Jani Nikula 
On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
> Am 31. Oktober 2016 22:54:54 MEZ, schrieb Joerg Roedel :
>>On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote:
>>> This is one machine booting a bad kernel. I could provide another
>>> example later this week.
>>
>>You have an Intel system without any IOMMU (enabled), otherwise you
>>would have a DMAR-ACPI table, but there is none:
>>
>>> [0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
>>> [0.00] ACPI: XSDT 0xA6FFE210 8C (v01 ACRSYS
>>ACRPRDCT 0001  0113)
>>> [0.00] ACPI: FACP 0xA6FFB000 F4 (v04 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: DSDT 0xA6FEC000 00B903 (v01 ACRSYS
>>ACRPRDCT  1025 0004)
>>> [0.00] ACPI: FACS 0xA6FBB000 40
>>> [0.00] ACPI: FACS 0xA6FBB000 40
>>> [0.00] ACPI: UEFI 0xA6FFD000 000236 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: ASF! 0xA6FFC000 A5 (v32 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: HPET 0xA6FFA000 38 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: APIC 0xA6FF9000 8C (v02 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: MCFG 0xA6FF8000 3C (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SLIC 0xA6FEB000 000176 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FEA000 0006FE (v01 ACRSYS
>>ACRPRDCT 1000 1025 0004)
>>> [0.00] ACPI: BOOT 0xA6FE8000 28 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: ASPT 0xA6FE3000 34 (v07 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: FPDT 0xA6FE1000 44 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FE 00079A (v01 ACRSYS
>>ACRPRDCT 3000 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FDF000 000A92 (v01 ACRSYS
>>ACRPRDCT 3000 1025 0004)
>>
>>So it is pretty unlikely that any change in IOMMU code causes your
>>issue. Not sure why your bisecting ended up there. You also have an
>>Intel GPU in the system:
>>
>>> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
>>Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
>>00 [VGA controller])
>>> Subsystem: Acer Incorporated [ALI] Device 0748
>>> Flags: bus master, fast devsel, latency 0, IRQ 28
>>> Memory at c000 (64-bit, non-prefetchable) [size=4M]
>>> Memory at b000 (64-bit, prefetchable) [size=256M]
>>> I/O ports at 2000 [size=64]
>>> [virtual] Expansion ROM at 000c [disabled] [size=128K]
>>> Capabilities: 
>>> Kernel driver in use: i915
>>
>>My best guess is that some changes in the i915 driver cause your issue,
>>I add the maintainers of i915 to the cc-list, maybe they have an idea.
>>
>>
>>  Joerg
>
>
> I'll come up with a nouveau system example and it was quite easy to bisect. 
> To quote the merge commit msg:
>
> This also required some changes outside of the IOMMU code, but these are 
> acked by the respective maintainers.
>
> Any help on bisecting into it would be awesome.

So the information here is pretty scarce. Please file a bug at [1],
describe the problem, perhaps add drm.debug=14 module parameter and
attach dmesg from boot to reproducing the problem.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-01 Thread Jani Nikula 
On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
> Am 31. Oktober 2016 22:54:54 MEZ, schrieb Joerg Roedel :
>>On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote:
>>> This is one machine booting a bad kernel. I could provide another
>>> example later this week.
>>
>>You have an Intel system without any IOMMU (enabled), otherwise you
>>would have a DMAR-ACPI table, but there is none:
>>
>>> [0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
>>> [0.00] ACPI: XSDT 0xA6FFE210 8C (v01 ACRSYS
>>ACRPRDCT 0001  0113)
>>> [0.00] ACPI: FACP 0xA6FFB000 F4 (v04 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: DSDT 0xA6FEC000 00B903 (v01 ACRSYS
>>ACRPRDCT  1025 0004)
>>> [0.00] ACPI: FACS 0xA6FBB000 40
>>> [0.00] ACPI: FACS 0xA6FBB000 40
>>> [0.00] ACPI: UEFI 0xA6FFD000 000236 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: ASF! 0xA6FFC000 A5 (v32 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: HPET 0xA6FFA000 38 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: APIC 0xA6FF9000 8C (v02 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: MCFG 0xA6FF8000 3C (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SLIC 0xA6FEB000 000176 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FEA000 0006FE (v01 ACRSYS
>>ACRPRDCT 1000 1025 0004)
>>> [0.00] ACPI: BOOT 0xA6FE8000 28 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: ASPT 0xA6FE3000 34 (v07 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: FPDT 0xA6FE1000 44 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FE 00079A (v01 ACRSYS
>>ACRPRDCT 3000 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FDF000 000A92 (v01 ACRSYS
>>ACRPRDCT 3000 1025 0004)
>>
>>So it is pretty unlikely that any change in IOMMU code causes your
>>issue. Not sure why your bisecting ended up there. You also have an
>>Intel GPU in the system:
>>
>>> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
>>Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
>>00 [VGA controller])
>>> Subsystem: Acer Incorporated [ALI] Device 0748
>>> Flags: bus master, fast devsel, latency 0, IRQ 28
>>> Memory at c000 (64-bit, non-prefetchable) [size=4M]
>>> Memory at b000 (64-bit, prefetchable) [size=256M]
>>> I/O ports at 2000 [size=64]
>>> [virtual] Expansion ROM at 000c [disabled] [size=128K]
>>> Capabilities: 
>>> Kernel driver in use: i915
>>
>>My best guess is that some changes in the i915 driver cause your issue,
>>I add the maintainers of i915 to the cc-list, maybe they have an idea.
>>
>>
>>  Joerg
>
>
> I'll come up with a nouveau system example and it was quite easy to bisect. 
> To quote the merge commit msg:
>
> This also required some changes outside of the IOMMU code, but these are 
> acked by the respective maintainers.
>
> Any help on bisecting into it would be awesome.

So the information here is pretty scarce. Please file a bug at [1],
describe the problem, perhaps add drm.debug=14 module parameter and
attach dmesg from boot to reproducing the problem.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-01 Thread Martin Kepplinger 


Am 31. Oktober 2016 22:54:54 MEZ, schrieb Joerg Roedel :
>On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote:
>> This is one machine booting a bad kernel. I could provide another
>> example later this week.
>
>You have an Intel system without any IOMMU (enabled), otherwise you
>would have a DMAR-ACPI table, but there is none:
>
>> [0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
>> [0.00] ACPI: XSDT 0xA6FFE210 8C (v01 ACRSYS
>ACRPRDCT 0001  0113)
>> [0.00] ACPI: FACP 0xA6FFB000 F4 (v04 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: DSDT 0xA6FEC000 00B903 (v01 ACRSYS
>ACRPRDCT  1025 0004)
>> [0.00] ACPI: FACS 0xA6FBB000 40
>> [0.00] ACPI: FACS 0xA6FBB000 40
>> [0.00] ACPI: UEFI 0xA6FFD000 000236 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: ASF! 0xA6FFC000 A5 (v32 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: HPET 0xA6FFA000 38 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: APIC 0xA6FF9000 8C (v02 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: MCFG 0xA6FF8000 3C (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SLIC 0xA6FEB000 000176 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FEA000 0006FE (v01 ACRSYS
>ACRPRDCT 1000 1025 0004)
>> [0.00] ACPI: BOOT 0xA6FE8000 28 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: ASPT 0xA6FE3000 34 (v07 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: FPDT 0xA6FE1000 44 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FE 00079A (v01 ACRSYS
>ACRPRDCT 3000 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FDF000 000A92 (v01 ACRSYS
>ACRPRDCT 3000 1025 0004)
>
>So it is pretty unlikely that any change in IOMMU code causes your
>issue. Not sure why your bisecting ended up there. You also have an
>Intel GPU in the system:
>
>> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
>Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
>00 [VGA controller])
>>  Subsystem: Acer Incorporated [ALI] Device 0748
>>  Flags: bus master, fast devsel, latency 0, IRQ 28
>>  Memory at c000 (64-bit, non-prefetchable) [size=4M]
>>  Memory at b000 (64-bit, prefetchable) [size=256M]
>>  I/O ports at 2000 [size=64]
>>  [virtual] Expansion ROM at 000c [disabled] [size=128K]
>>  Capabilities: 
>>  Kernel driver in use: i915
>
>My best guess is that some changes in the i915 driver cause your issue,
>I add the maintainers of i915 to the cc-list, maybe they have an idea.
>
>
>   Joerg


I'll come up with a nouveau system example and it was quite easy to bisect. To 
quote the merge commit msg:

This also required some changes outside of the IOMMU code, but these are acked 
by the respective maintainers.

Any help on bisecting into it would be awesome.

Re: [BUG][REGRESSION] mangled display since -rc1

2016-11-01 Thread Martin Kepplinger 


Am 31. Oktober 2016 22:54:54 MEZ, schrieb Joerg Roedel :
>On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote:
>> This is one machine booting a bad kernel. I could provide another
>> example later this week.
>
>You have an Intel system without any IOMMU (enabled), otherwise you
>would have a DMAR-ACPI table, but there is none:
>
>> [0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
>> [0.00] ACPI: XSDT 0xA6FFE210 8C (v01 ACRSYS
>ACRPRDCT 0001  0113)
>> [0.00] ACPI: FACP 0xA6FFB000 F4 (v04 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: DSDT 0xA6FEC000 00B903 (v01 ACRSYS
>ACRPRDCT  1025 0004)
>> [0.00] ACPI: FACS 0xA6FBB000 40
>> [0.00] ACPI: FACS 0xA6FBB000 40
>> [0.00] ACPI: UEFI 0xA6FFD000 000236 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: ASF! 0xA6FFC000 A5 (v32 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: HPET 0xA6FFA000 38 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: APIC 0xA6FF9000 8C (v02 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: MCFG 0xA6FF8000 3C (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SLIC 0xA6FEB000 000176 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FEA000 0006FE (v01 ACRSYS
>ACRPRDCT 1000 1025 0004)
>> [0.00] ACPI: BOOT 0xA6FE8000 28 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: ASPT 0xA6FE3000 34 (v07 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: FPDT 0xA6FE1000 44 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FE 00079A (v01 ACRSYS
>ACRPRDCT 3000 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FDF000 000A92 (v01 ACRSYS
>ACRPRDCT 3000 1025 0004)
>
>So it is pretty unlikely that any change in IOMMU code causes your
>issue. Not sure why your bisecting ended up there. You also have an
>Intel GPU in the system:
>
>> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
>Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
>00 [VGA controller])
>>  Subsystem: Acer Incorporated [ALI] Device 0748
>>  Flags: bus master, fast devsel, latency 0, IRQ 28
>>  Memory at c000 (64-bit, non-prefetchable) [size=4M]
>>  Memory at b000 (64-bit, prefetchable) [size=256M]
>>  I/O ports at 2000 [size=64]
>>  [virtual] Expansion ROM at 000c [disabled] [size=128K]
>>  Capabilities: 
>>  Kernel driver in use: i915
>
>My best guess is that some changes in the i915 driver cause your issue,
>I add the maintainers of i915 to the cc-list, maybe they have an idea.
>
>
>   Joerg


I'll come up with a nouveau system example and it was quite easy to bisect. To 
quote the merge commit msg:

This also required some changes outside of the IOMMU code, but these are acked 
by the respective maintainers.

Any help on bisecting into it would be awesome.

Re: [BUG][REGRESSION] mangled display since -rc1

2016-10-31 Thread Joerg Roedel 
On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote:
> This is one machine booting a bad kernel. I could provide another
> example later this week.

You have an Intel system without any IOMMU (enabled), otherwise you
would have a DMAR-ACPI table, but there is none:

> [0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
> [0.00] ACPI: XSDT 0xA6FFE210 8C (v01 ACRSYS ACRPRDCT 
> 0001  0113)
> [0.00] ACPI: FACP 0xA6FFB000 F4 (v04 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: DSDT 0xA6FEC000 00B903 (v01 ACRSYS ACRPRDCT 
>  1025 0004)
> [0.00] ACPI: FACS 0xA6FBB000 40
> [0.00] ACPI: FACS 0xA6FBB000 40
> [0.00] ACPI: UEFI 0xA6FFD000 000236 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: ASF! 0xA6FFC000 A5 (v32 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: HPET 0xA6FFA000 38 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: APIC 0xA6FF9000 8C (v02 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: MCFG 0xA6FF8000 3C (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: SLIC 0xA6FEB000 000176 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: SSDT 0xA6FEA000 0006FE (v01 ACRSYS ACRPRDCT 
> 1000 1025 0004)
> [0.00] ACPI: BOOT 0xA6FE8000 28 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: ASPT 0xA6FE3000 34 (v07 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: FPDT 0xA6FE1000 44 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: SSDT 0xA6FE 00079A (v01 ACRSYS ACRPRDCT 
> 3000 1025 0004)
> [0.00] ACPI: SSDT 0xA6FDF000 000A92 (v01 ACRSYS ACRPRDCT 
> 3000 1025 0004)

So it is pretty unlikely that any change in IOMMU code causes your
issue. Not sure why your bisecting ended up there. You also have an
Intel GPU in the system:

> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
> Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA 
> controller])
>   Subsystem: Acer Incorporated [ALI] Device 0748
>   Flags: bus master, fast devsel, latency 0, IRQ 28
>   Memory at c000 (64-bit, non-prefetchable) [size=4M]
>   Memory at b000 (64-bit, prefetchable) [size=256M]
>   I/O ports at 2000 [size=64]
>   [virtual] Expansion ROM at 000c [disabled] [size=128K]
>   Capabilities: 
>   Kernel driver in use: i915

My best guess is that some changes in the i915 driver cause your issue,
I add the maintainers of i915 to the cc-list, maybe they have an idea.


Joerg

Re: [BUG][REGRESSION] mangled display since -rc1

2016-10-31 Thread Joerg Roedel 
On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote:
> This is one machine booting a bad kernel. I could provide another
> example later this week.

You have an Intel system without any IOMMU (enabled), otherwise you
would have a DMAR-ACPI table, but there is none:

> [0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
> [0.00] ACPI: XSDT 0xA6FFE210 8C (v01 ACRSYS ACRPRDCT 
> 0001  0113)
> [0.00] ACPI: FACP 0xA6FFB000 F4 (v04 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: DSDT 0xA6FEC000 00B903 (v01 ACRSYS ACRPRDCT 
>  1025 0004)
> [0.00] ACPI: FACS 0xA6FBB000 40
> [0.00] ACPI: FACS 0xA6FBB000 40
> [0.00] ACPI: UEFI 0xA6FFD000 000236 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: ASF! 0xA6FFC000 A5 (v32 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: HPET 0xA6FFA000 38 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: APIC 0xA6FF9000 8C (v02 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: MCFG 0xA6FF8000 3C (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: SLIC 0xA6FEB000 000176 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: SSDT 0xA6FEA000 0006FE (v01 ACRSYS ACRPRDCT 
> 1000 1025 0004)
> [0.00] ACPI: BOOT 0xA6FE8000 28 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: ASPT 0xA6FE3000 34 (v07 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: FPDT 0xA6FE1000 44 (v01 ACRSYS ACRPRDCT 
> 0001 1025 0004)
> [0.00] ACPI: SSDT 0xA6FE 00079A (v01 ACRSYS ACRPRDCT 
> 3000 1025 0004)
> [0.00] ACPI: SSDT 0xA6FDF000 000A92 (v01 ACRSYS ACRPRDCT 
> 3000 1025 0004)

So it is pretty unlikely that any change in IOMMU code causes your
issue. Not sure why your bisecting ended up there. You also have an
Intel GPU in the system:

> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
> Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA 
> controller])
>   Subsystem: Acer Incorporated [ALI] Device 0748
>   Flags: bus master, fast devsel, latency 0, IRQ 28
>   Memory at c000 (64-bit, non-prefetchable) [size=4M]
>   Memory at b000 (64-bit, prefetchable) [size=256M]
>   I/O ports at 2000 [size=64]
>   [virtual] Expansion ROM at 000c [disabled] [size=128K]
>   Capabilities: 
>   Kernel driver in use: i915

My best guess is that some changes in the i915 driver cause your issue,
I add the maintainers of i915 to the cc-list, maybe they have an idea.


Joerg

Re: [BUG][REGRESSION] mangled display since -rc1

2016-10-31 Thread Martin Kepplinger 
Am 2016-10-31 um 16:21 schrieb Joerg Roedel:
> On Mon, Oct 31, 2016 at 11:40:06AM +0100, Martin Kepplinger wrote:
>> In case the screenshot doesn't make it to you, here it is:
>> https://postimg.org/image/5wl2wemt9/
> 
> Can you please send a boot-dmesg and 'lspci -v'? We need more
> information about your system first.
> 
> 
>   Joerg
> 

This is one machine booting a bad kernel. I could provide another
example later this week.

  martin
[0.00] Linux version 4.9.0-rc2-3-g414e1a5 (martin@laptop) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #86 SMP Mon Oct 24 09:25:27 CEST 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-rc2-3-g414e1a5 
root=UUID=bc17d7c1-da00-453d-bb7c-d956af38c74d ro nosplash
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0xa6abefff] usable
[0.00] BIOS-e820: [mem 0xa6abf000-0xa6ebefff] reserved
[0.00] BIOS-e820: [mem 0xa6ebf000-0xa6fbefff] ACPI NVS
[0.00] BIOS-e820: [mem 0xa6fbf000-0xa6ffefff] ACPI data
[0.00] BIOS-e820: [mem 0xa6fff000-0xa6ff] usable
[0.00] BIOS-e820: [mem 0xa700-0xaf9f] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffc8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00024f5f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Acer TravelMate B113/BA10_HX   , BIOS V1.09 
10/30/2012
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x24f600 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-E7FFF write-protect
[0.00]   E8000-E write-combining
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0A700 mask FFF00 uncachable
[0.00]   3 base 0A800 mask FF800 uncachable
[0.00]   4 base 0B000 mask FF000 uncachable
[0.00]   5 base 0FFC0 mask FFFC0 write-protect
[0.00]   6 base 1 mask F write-back
[0.00]   7 base 2 mask FC000 write-back
[0.00]   8 base 24000 mask FF000 write-back
[0.00]   9 base 24F60 mask FFFE0 uncachable
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0xa7000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fe1b0-0x000fe1bf] mapped at 
[880fe1b0]
[0.00] Base memory trampoline at [88097000] 97000 size 24576
[0.00] reserving inaccessible SNB gfx pages
[0.00] BRK [0x01aad000, 0x01aadfff] PGTABLE
[0.00] BRK [0x01aae000, 0x01aaefff] PGTABLE
[0.00] BRK [0x01aaf000, 0x01aa] PGTABLE
[0.00] BRK [0x01ab, 0x01ab0fff] PGTABLE
[0.00] BRK [0x01ab1000, 0x01ab1fff] PGTABLE
[0.00] BRK [0x01ab2000, 0x01ab2fff] PGTABLE
[0.00] RAMDISK: [mem 0x36b56000-0x375a2fff]
[0.00]

Re: [BUG][REGRESSION] mangled display since -rc1

2016-10-31 Thread Martin Kepplinger 
Am 2016-10-31 um 16:21 schrieb Joerg Roedel:
> On Mon, Oct 31, 2016 at 11:40:06AM +0100, Martin Kepplinger wrote:
>> In case the screenshot doesn't make it to you, here it is:
>> https://postimg.org/image/5wl2wemt9/
> 
> Can you please send a boot-dmesg and 'lspci -v'? We need more
> information about your system first.
> 
> 
>   Joerg
> 

This is one machine booting a bad kernel. I could provide another
example later this week.

  martin
[0.00] Linux version 4.9.0-rc2-3-g414e1a5 (martin@laptop) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #86 SMP Mon Oct 24 09:25:27 CEST 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-rc2-3-g414e1a5 
root=UUID=bc17d7c1-da00-453d-bb7c-d956af38c74d ro nosplash
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0xa6abefff] usable
[0.00] BIOS-e820: [mem 0xa6abf000-0xa6ebefff] reserved
[0.00] BIOS-e820: [mem 0xa6ebf000-0xa6fbefff] ACPI NVS
[0.00] BIOS-e820: [mem 0xa6fbf000-0xa6ffefff] ACPI data
[0.00] BIOS-e820: [mem 0xa6fff000-0xa6ff] usable
[0.00] BIOS-e820: [mem 0xa700-0xaf9f] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffc8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00024f5f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Acer TravelMate B113/BA10_HX   , BIOS V1.09 
10/30/2012
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x24f600 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-E7FFF write-protect
[0.00]   E8000-E write-combining
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0A700 mask FFF00 uncachable
[0.00]   3 base 0A800 mask FF800 uncachable
[0.00]   4 base 0B000 mask FF000 uncachable
[0.00]   5 base 0FFC0 mask FFFC0 write-protect
[0.00]   6 base 1 mask F write-back
[0.00]   7 base 2 mask FC000 write-back
[0.00]   8 base 24000 mask FF000 write-back
[0.00]   9 base 24F60 mask FFFE0 uncachable
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0xa7000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fe1b0-0x000fe1bf] mapped at 
[880fe1b0]
[0.00] Base memory trampoline at [88097000] 97000 size 24576
[0.00] reserving inaccessible SNB gfx pages
[0.00] BRK [0x01aad000, 0x01aadfff] PGTABLE
[0.00] BRK [0x01aae000, 0x01aaefff] PGTABLE
[0.00] BRK [0x01aaf000, 0x01aa] PGTABLE
[0.00] BRK [0x01ab, 0x01ab0fff] PGTABLE
[0.00] BRK [0x01ab1000, 0x01ab1fff] PGTABLE
[0.00] BRK [0x01ab2000, 0x01ab2fff] PGTABLE
[0.00] RAMDISK: [mem 0x36b56000-0x375a2fff]
[0.00]

Re: [BUG][REGRESSION] mangled display since -rc1

2016-10-31 Thread Joerg Roedel 
On Mon, Oct 31, 2016 at 11:40:06AM +0100, Martin Kepplinger wrote:
> In case the screenshot doesn't make it to you, here it is:
> https://postimg.org/image/5wl2wemt9/

Can you please send a boot-dmesg and 'lspci -v'? We need more
information about your system first.


Joerg

Re: [BUG][REGRESSION] mangled display since -rc1

2016-10-31 Thread Joerg Roedel 
On Mon, Oct 31, 2016 at 11:40:06AM +0100, Martin Kepplinger wrote:
> In case the screenshot doesn't make it to you, here it is:
> https://postimg.org/image/5wl2wemt9/

Can you please send a boot-dmesg and 'lspci -v'? We need more
information about your system first.


Joerg

Re: [BUG][REGRESSION] mangled display since -rc1

2016-10-31 Thread Martin Kepplinger 

In case the screenshot doesn't make it to you, here it is:
https://postimg.org/image/5wl2wemt9/


Am 31.10.2016 11:36 schrieb Martin Kepplinger:

so guys,

I can't believe that nobody hits this: Since -rc1 Nautilus' list of
elements or Firefox' website window or just photos in eog (probably
among many more things) is mangled. Please have a look at the
screenshot of nautilus.

This is the same on a i3 laptop with intel graphics and a i7 with
nouvau graphics. I bisected and the problem is this merge:
first bad commit: [56e520c7a0a490b63b042b047ec9659fc08762a4] Merge tag
'iommu-updates-v4.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

Two things I'd ask of you if this isn't already a known problem to you:

* I failed bisecting into this merge but I could easily have tried it
totally wrong, so I'd appreciate any advice on how to bisect into
this.
  Strangely, running joro's
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=iommu-updates-v4.9=13a08259187c5cd3f63d98efa159ab42976d85a4
(referenced here:
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/tag/?h=iommu-updates-v4.9)
is good (?)

* Please add anybody you know is involved to CC.

I'm happy to test patches too, of course.

Anyhow. This is a bad regression that prevents me from running 4.9.
Just so you know.

so long,
martin

Re: [BUG][REGRESSION] mangled display since -rc1

2016-10-31 Thread Martin Kepplinger 

In case the screenshot doesn't make it to you, here it is:
https://postimg.org/image/5wl2wemt9/


Am 31.10.2016 11:36 schrieb Martin Kepplinger:

so guys,

I can't believe that nobody hits this: Since -rc1 Nautilus' list of
elements or Firefox' website window or just photos in eog (probably
among many more things) is mangled. Please have a look at the
screenshot of nautilus.

This is the same on a i3 laptop with intel graphics and a i7 with
nouvau graphics. I bisected and the problem is this merge:
first bad commit: [56e520c7a0a490b63b042b047ec9659fc08762a4] Merge tag
'iommu-updates-v4.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

Two things I'd ask of you if this isn't already a known problem to you:

* I failed bisecting into this merge but I could easily have tried it
totally wrong, so I'd appreciate any advice on how to bisect into
this.
  Strangely, running joro's
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=iommu-updates-v4.9=13a08259187c5cd3f63d98efa159ab42976d85a4
(referenced here:
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/tag/?h=iommu-updates-v4.9)
is good (?)

* Please add anybody you know is involved to CC.

I'm happy to test patches too, of course.

Anyhow. This is a bad regression that prevents me from running 4.9.
Just so you know.

so long,
martin