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

Commit Message

Chris Wilson Aug. 13, 2013, 9:25 a.m. UTC

On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
> Hi,
> 
> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
> top, it's simply black.
> I can estimate the URL line in Firefox (or open a new tab blindly and
> get a known URL from my autocompleted history).

Can you attach a photograph?
 
> My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
> next-20130808 was OK - no screen corruptions.
> 
> Any idea, hint?

Can you please try:

Comments

Sedat Dilek Aug. 13, 2013, 9:35 a.m. UTC | #1

On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson <[e-mail]> wrote:
> On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
>> top, it's simply black.
>> I can estimate the URL line in Firefox (or open a new tab blindly and
>> get a known URL from my autocompleted history).
>
> Can you attach a photograph?
>

It's a black bar on the top of my desktop-screen - approx. 1/10.

It looks like this is also in the VT on bootup before entering LightDM.

>> My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14.
>> next-20130808 was OK - no screen corruptions.
>>
>> Any idea, hint?
>
> Can you please try:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index af1b2f0..b0f181d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>                 break;
>         case I915_TILING_X:
>                 /* pin() will align the object as required by fence */
> -               alignment = 0;
> +               alignment = 256 * 1024;
>                 break;
>         case I915_TILING_Y:
>                 /* Despite that we check this in framebuffer_init userspace can
>
> --

NO, that did not help.

After a logout from my "BROKEN" Unity-2D session - the login-screen
for LightDM seems to be OK.
Then entering my Unity-2D desktop is OK - no screen corruptions.

- Sedat -

Chris Wilson Aug. 13, 2013, 9:39 a.m. UTC | #2

On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> After a logout from my "BROKEN" Unity-2D session - the login-screen
> for LightDM seems to be OK.
> Then entering my Unity-2D desktop is OK - no screen corruptions.

What hardware and display do you have?
-Chris

Sedat Dilek Aug. 13, 2013, 9:47 a.m. UTC | #3

On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[e-mail]> wrote:
> On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> After a logout from my "BROKEN" Unity-2D session - the login-screen
>> for LightDM seems to be OK.
>> Then entering my Unity-2D desktop is OK - no screen corruptions.
>
> What hardware and display do you have?

It's a Samsung ultrabook with SandyBridge CPU.

[   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
Graphics 3000

xrand output attached.

- Sedat -

P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS1 connected 1366x768+0+0 (0x45) normal (normal left inverted right x axis y axis) 0mm x 0mm
	Identifier: 0x41
	Timestamp:  339571
	Subpixel:   horizontal rgb
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       0
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	BACKLIGHT: 7 (0x00000007)	range:  (0,7)
	Backlight: 7 (0x00000007)	range:  (0,7)
	scaling mode:	Full aspect
		supported: None         Full         Center       Full aspect 
  1366x768 (0x45)   70.7MHz -HSync -VSync *current +preferred
        h: width  1366 start 1414 end 1446 total 1486 skew    0 clock   47.6KHz
        v: height  768 start  770 end  775 total  792           clock   60.1Hz
  1360x768 (0x46)   84.8MHz -HSync +VSync
        h: width  1360 start 1432 end 1568 total 1776 skew    0 clock   47.7KHz
        v: height  768 start  771 end  781 total  798           clock   59.8Hz
  1360x768 (0x47)   72.0MHz +HSync -VSync
        h: width  1360 start 1408 end 1440 total 1520 skew    0 clock   47.4KHz
        v: height  768 start  771 end  781 total  790           clock   60.0Hz
  1024x768 (0x48)   65.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  800x600 (0x49)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
        v: height  600 start  601 end  605 total  628           clock   60.3Hz
  800x600 (0x4a)   36.0MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock   35.2KHz
        v: height  600 start  601 end  603 total  625           clock   56.2Hz
  640x480 (0x4b)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
        v: height  480 start  490 end  492 total  525           clock   59.9Hz
VGA1 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x42
	Timestamp:  339571
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
HDMI1 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x43
	Timestamp:  339571
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	Broadcast RGB:	Automatic
		supported: Automatic    Full         Limited 16:2
	audio:	auto
		supported: force-dvi    off          auto         on          
DP1 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x44
	Timestamp:  339571
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	Broadcast RGB:	Automatic
		supported: Automatic    Full         Limited 16:2
	audio:	auto
		supported: force-dvi    off          auto         on

Chris Wilson Aug. 13, 2013, 9:52 a.m. UTC | #4

On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[e-mail]> wrote:
> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
> >> for LightDM seems to be OK.
> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
> >
> > What hardware and display do you have?
> 
> It's a Samsung ultrabook with SandyBridge CPU.
> 
> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
> Graphics 3000

using LVDS.
 
> - Sedat -
> 
> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.

Did that make a difference? It shouldn't if the error is occuring before
X even starts...
-Chris

Sedat Dilek Aug. 13, 2013, 9:57 a.m. UTC | #5

On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[e-mail]> wrote:
> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[e-mail]> wrote:
>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
>> >> for LightDM seems to be OK.
>> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
>> >
>> > What hardware and display do you have?
>>
>> It's a Samsung ultrabook with SandyBridge CPU.
>>
>> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
>> Graphics 3000
>
> using LVDS.
>
>> - Sedat -
>>
>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>
> Did that make a difference? It shouldn't if the error is occuring before
> X even starts...

NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
Xorg.log :-).

As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
Starting again a Unity-2D session - no screen corruption, too.

- Sedat -

Sedat Dilek Aug. 13, 2013, 2:07 p.m. UTC | #6

On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek <[e-mail]> wrote:
> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[e-mail]> wrote:
>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[e-mail]> wrote:
>>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
>>> >> for LightDM seems to be OK.
>>> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
>>> >
>>> > What hardware and display do you have?
>>>
>>> It's a Samsung ultrabook with SandyBridge CPU.
>>>
>>> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
>>> Graphics 3000
>>
>> using LVDS.
>>
>>> - Sedat -
>>>
>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>>
>> Did that make a difference? It shouldn't if the error is occuring before
>> X even starts...
>
> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
> Xorg.log :-).
>
> As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
> Starting again a Unity-2D session - no screen corruption, too.
>
> - Sedat -

Some more testing:

[1] With my X stack:

FIRST BAD: next-20130812
LAST GOOD: next-20130809

[2] With Ubuntu's X stack:

next-20130813 is OK (Xorg.log attached)

- Sedat -

Sedat Dilek Aug. 13, 2013, 2:45 p.m. UTC | #7

On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek <[e-mail]> wrote:
> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek <[e-mail]> wrote:
>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[e-mail]> wrote:
>>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>>>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[e-mail]> wrote:
>>>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>>>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
>>>> >> for LightDM seems to be OK.
>>>> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
>>>> >
>>>> > What hardware and display do you have?
>>>>
>>>> It's a Samsung ultrabook with SandyBridge CPU.
>>>>
>>>> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
>>>> Graphics 3000
>>>
>>> using LVDS.
>>>
>>>> - Sedat -
>>>>
>>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>>>
>>> Did that make a difference? It shouldn't if the error is occuring before
>>> X even starts...
>>
>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
>> Xorg.log :-).
>>
>> As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
>> Starting again a Unity-2D session - no screen corruption, too.
>>
>> - Sedat -
>
> Some more testing:
>
> [1] With my X stack:
>
> FIRST BAD: next-20130812
> LAST GOOD: next-20130809
>
> [2] With Ubuntu's X stack:
>
> next-20130813 is OK (Xorg.log attached)
>

drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
no problems).

- Sedat -

> - Sedat -

Sedat Dilek Aug. 13, 2013, 3:59 p.m. UTC | #8

On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek <[e-mail]> wrote:
> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek <[e-mail]> wrote:
>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek <[e-mail]> wrote:
>>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[e-mail]> wrote:
>>>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>>>>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[e-mail]> wrote:
>>>>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>>>>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
>>>>> >> for LightDM seems to be OK.
>>>>> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
>>>>> >
>>>>> > What hardware and display do you have?
>>>>>
>>>>> It's a Samsung ultrabook with SandyBridge CPU.
>>>>>
>>>>> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
>>>>> Graphics 3000
>>>>
>>>> using LVDS.
>>>>
>>>>> - Sedat -
>>>>>
>>>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>>>>
>>>> Did that make a difference? It shouldn't if the error is occuring before
>>>> X even starts...
>>>
>>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
>>> Xorg.log :-).
>>>
>>> As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
>>> Starting again a Unity-2D session - no screen corruption, too.
>>>
>>> - Sedat -
>>
>> Some more testing:
>>
>> [1] With my X stack:
>>
>> FIRST BAD: next-20130812
>> LAST GOOD: next-20130809
>>
>> [2] With Ubuntu's X stack:
>>
>> next-20130813 is OK (Xorg.log attached)
>>
>
> drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
> no problems).
>

I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:

5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson <[e-mail]>
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 <[e-mail]>
    Reviewed-by: Ville Syrjälä <[e-mail]>
    Signed-off-by: Daniel Vetter <[e-mail]>

:040000 040000 de063a052f39095f4d2f51b49caef9f827df41e8
1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M      drivers

See also attached files!

- Sedat -
git bisect start
# good: [d4e4ab86bcba5a72779c43dc1459f71fea3d89c8] Linux 3.11-rc5
git bisect good d4e4ab86bcba5a72779c43dc1459f71fea3d89c8
# bad: [5b79c8eb1b61d499ca70cc3e4e2ced7822209876] Merge branch 'drm-intel-nightly' into 3.11.0-rc5-iniza-small
git bisect bad 5b79c8eb1b61d499ca70cc3e4e2ced7822209876
# good: [36f2d1f151215c48d902947d64b86dc5ab277e19] drm/i915: rip out legacy encoder->mode_set callback
git bisect good 36f2d1f151215c48d902947d64b86dc5ab277e19
# good: [c35426d2bc25b242ee2a9a7a1d62634be1e86bb0] drm/i915: Split plane watermark parameters into a separate struct
git bisect good c35426d2bc25b242ee2a9a7a1d62634be1e86bb0
# good: [32c913e4369ce7bd1d16a9b6983f7b8975c13f5a] Merge tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
git bisect good 32c913e4369ce7bd1d16a9b6983f7b8975c13f5a
# good: [d46f1c3f1372e3a72fab97c60480aa4a1084387f] drm/i915: Allow the GPU to cache stolen memory
git bisect good d46f1c3f1372e3a72fab97c60480aa4a1084387f
# bad: [b8a1868b10bb4fe7fb7d283da5d56064b1a189f4] drm/i915: Allow the user to set bo into the DISPLAY cache domain
git bisect bad b8a1868b10bb4fe7fb7d283da5d56064b1a189f4
# bad: [a698a20e8cf9a946b0a491cb58ff96c0b4332d08] i915: Fix SDVO potentially turning off randomly
git bisect bad a698a20e8cf9a946b0a491cb58ff96c0b4332d08
# bad: [8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1] drm/i915: Only do a chipset flush after a clflush
git bisect bad 8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1
# bad: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC ringbuffers from stolen
git bisect bad 5456fe3882812aba251886e36fe55bfefb8e8829
# first bad commit: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC ringbuffers from stolen
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson <[e-mail]>
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 <[e-mail]>
    Reviewed-by: Ville Syrjälä <[e-mail]>
    Signed-off-by: Daniel Vetter <[e-mail]>

 drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
commit 5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson <[e-mail]>
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 <[e-mail]>
    Reviewed-by: Ville Syrjälä <[e-mail]>
    Signed-off-by: Daniel Vetter <[e-mail]>

Sedat Dilek Aug. 13, 2013, 4:23 p.m. UTC | #9

On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek <[e-mail]> wrote:
> On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek <[e-mail]> wrote:
>> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek <[e-mail]> wrote:
>>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek <[e-mail]> wrote:
>>>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[e-mail]> wrote:
>>>>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>>>>>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[e-mail]> wrote:
>>>>>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>>>>>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
>>>>>> >> for LightDM seems to be OK.
>>>>>> >> Then entering my Unity-2D desktop is OK - no screen corruptions.
>>>>>> >
>>>>>> > What hardware and display do you have?
>>>>>>
>>>>>> It's a Samsung ultrabook with SandyBridge CPU.
>>>>>>
>>>>>> [   333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
>>>>>> Graphics 3000
>>>>>
>>>>> using LVDS.
>>>>>
>>>>>> - Sedat -
>>>>>>
>>>>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>>>>>
>>>>> Did that make a difference? It shouldn't if the error is occuring before
>>>>> X even starts...
>>>>
>>>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
>>>> Xorg.log :-).
>>>>
>>>> As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
>>>> Starting again a Unity-2D session - no screen corruption, too.
>>>>
>>>> - Sedat -
>>>
>>> Some more testing:
>>>
>>> [1] With my X stack:
>>>
>>> FIRST BAD: next-20130812
>>> LAST GOOD: next-20130809
>>>
>>> [2] With Ubuntu's X stack:
>>>
>>> next-20130813 is OK (Xorg.log attached)
>>>
>>
>> drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack
>> no problems).
>>
>
> I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
>
> 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
> commit 5456fe3882812aba251886e36fe55bfefb8e8829
> Author: Chris Wilson <[e-mail]>
> 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 <[e-mail]>
>     Reviewed-by: Ville Syrjälä <[e-mail]>
>     Signed-off-by: Daniel Vetter <[e-mail]>
>
> :040000 040000 de063a052f39095f4d2f51b49caef9f827df41e8
> 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M      drivers
>
> See also attached files!
>

With the attached revert-patch my system is OK (with my customized X stack).

- Sedat -

Chris Wilson Aug. 13, 2013, 4:34 p.m. UTC | #10

On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek <[e-mail]> 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 <[e-mail]>
> > 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 <[e-mail]>
> >     Reviewed-by: Ville Syrjälä <[e-mail]>
> >     Signed-off-by: Daniel Vetter <[e-mail]>
> >
> > :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.
-Chris

Sedat Dilek Aug. 13, 2013, 4:37 p.m. UTC | #11

On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> > 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 <[e-mail]>
>> >     Reviewed-by: Ville Syrjälä <[e-mail]>
>> >     Signed-off-by: Daniel Vetter <[e-mail]>
>> >
>> > :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.

With revert-patch applied:

$ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen
Stolen:
   ffff88007f6f5200: p g     4128KiB 77 00 0 0 0 uncached (name: 1)
(pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
(stolen: 00000000) (p mappable)
Total 1 objects, 4227072 bytes, 4227072 GTT size

$ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj
ffff88007f6f5200: p g     4128KiB 77 00 0 0 0 uncached (name: 1)
(pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
(stolen: 00000000) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj
ffff88007f6f5080: pXg     5120KiB 36 02 124873 124873 0 uncached dirty
(name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000,
size: 00500000) (p mappable) (blitter ring)

- Sedat -

Sedat Dilek Aug. 13, 2013, 5:03 p.m. UTC | #12

On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek <[e-mail]> wrote:
> On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>> > 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 <[e-mail]>
>>> >     Reviewed-by: Ville Syrjälä <[e-mail]>
>>> >     Signed-off-by: Daniel Vetter <[e-mail]>
>>> >
>>> > :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.
>
> With revert-patch applied:
>
> $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen
> Stolen:
>    ffff88007f6f5200: p g     4128KiB 77 00 0 0 0 uncached (name: 1)
> (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
> (stolen: 00000000) (p mappable)
> Total 1 objects, 4227072 bytes, 4227072 GTT size
>
> $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
> fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj
> ffff88007f6f5200: p g     4128KiB 77 00 0 0 0 uncached (name: 1)
> (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000)
> (stolen: 00000000) (p mappable)
> user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj
> ffff88007f6f5080: pXg     5120KiB 36 02 124873 124873 0 uncached dirty
> (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000,
> size: 00500000) (p mappable) (blitter ring)
>

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

- Sedat -
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj ffff880074492e40: p g     4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 00000000) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj ffff880074492840: pXg     5120KiB 36 02 158126 158126 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 00500000) (p mappable) (blitter ring)
fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj ffff880073995200: p g     4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 00060000) (p mappable)
user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj ffff8800736d8e00: pXg     5120KiB 36 02 -737 -737 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 00500000) (p mappable) (blitter ring)
Stolen:
   ffff880074492e40: p g     4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 00000000) (p mappable)
Total 1 objects, 4227072 bytes, 4227072 GTT size
Stolen:
   ffff880073995c80: p g      128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00001000, size: 00020000) (stolen: 00000000) (p mappable)
   ffff880073995800: p g      128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00023000, size: 00020000) (stolen: 00020000) (p mappable)
   ffff880073995500: p g      128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00044000, size: 00020000) (stolen: 00040000) (p mappable)
   ffff880073995200: p g     4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 00060000) (p mappable)
Total 4 objects, 4620288 bytes, 4620288 GTT size

Patch

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index af1b2f0..b0f181d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1837,7 +1837,7 @@  intel_pin_and_fence_fb_obj(struct drm_device *dev,
                break;
        case I915_TILING_X:
                /* pin() will align the object as required by fence */
-               alignment = 0;
+               alignment = 256 * 1024;
                break;
        case I915_TILING_Y:
                /* Despite that we check this in framebuffer_init userspace can