On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> Changes since 20130812:
>
> The ext4 tree gained a conflict against Linus' tree.
>
> The infiniband tree gained a build failure for which I applied a merge
> fix patch and another so I used the version from next-20130812.
>
> The tty tree gained conflicts against the devicetree and tile trees.
>
> The usb tree gained a conflict against the net-next tree.
>
> The usb-gadget tree gained a build failure for which I reverted a commit.
>
> The ptr-ret tree gained a conflict against the staging tree.
>
> The akpm tree gained a conflict against the staging tree.
>
> ----------------------------------------------------------------------------
>
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).
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?
- Sedat -
On Tue, Aug 13, 2013 at 11:10 AM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell <[email protected]> wrote:
>> Hi all,
>>
>> Changes since 20130812:
>>
>> The ext4 tree gained a conflict against Linus' tree.
>>
>> The infiniband tree gained a build failure for which I applied a merge
>> fix patch and another so I used the version from next-20130812.
>>
>> The tty tree gained conflicts against the devicetree and tile trees.
>>
>> The usb tree gained a conflict against the net-next tree.
>>
>> The usb-gadget tree gained a build failure for which I reverted a commit.
>>
>> The ptr-ret tree gained a conflict against the staging tree.
>>
>> The akpm tree gained a conflict against the staging tree.
>>
>> ----------------------------------------------------------------------------
>>
>
> 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).
>
> 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?
>
> - Sedat -
[ From my dmesg ]
[ 28.026524] ------------[ cut here ]------------
[ 28.026557] WARNING: CPU: 3 PID: 639 at
drivers/gpu/drm/i915/i915_gem.c:3435
i915_gem_object_set_cache_level+0x389/0x3a0 [i915]()
[ 28.026560] Modules linked in: arc4 snd_hwdep i915(+) iwldvm
snd_pcm snd_page_alloc mac80211 snd_seq_midi parport_pc
snd_seq_midi_event rfcomm bnep snd_rawmidi ppdev uvcvideo snd_seq
btusb videobuf2_vmalloc i2c_algo_bit psmouse iwlwifi drm_kms_helper
videobuf2_memops snd_timer drm snd_seq_device videobuf2_core bluetooth
videodev serio_raw snd cfg80211 samsung_laptop wmi soundcore lp
mac_hid video lpc_ich parport hid_generic usbhid hid usb_storage r8169
mii
[ 28.026610] CPU: 3 PID: 639 Comm: modprobe Not tainted
3.11.0-rc5-next20130813-1-iniza-small #1
[ 28.026613] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[ 28.026616] 0000000000000d6b ffff8800795535a8 ffffffff816e259a
0000000000000007
[ 28.026622] 0000000000000000 ffff8800795535e8 ffffffff810661dc
ffffffff81376e70
[ 28.026627] ffff8800746ba200 ffff8800746ba2b8 ffff88007a2c7000
0000000000000041
[ 28.026632] Call Trace:
[ 28.026641] [<ffffffff816e259a>] dump_stack+0x46/0x58
[ 28.026647] [<ffffffff810661dc>] warn_slowpath_common+0x8c/0xc0
[ 28.026653] [<ffffffff81376e70>] ? sg_kfree+0x30/0x30
[ 28.026658] [<ffffffff8106622a>] warn_slowpath_null+0x1a/0x20
[ 28.026680] [<ffffffffa03e1fe9>]
i915_gem_object_set_cache_level+0x389/0x3a0 [i915]
[ 28.026684] [<ffffffff8137723f>] ? sg_alloc_table+0x1f/0x50
[ 28.026703] [<ffffffffa03e2162>]
i915_gem_object_pin_to_display_plane+0x62/0x1c0 [i915]
[ 28.026727] [<ffffffffa03f9b10>]
intel_pin_and_fence_fb_obj+0xc0/0x140 [i915]
[ 28.026732] [<ffffffff816e82ee>] ? mutex_lock+0x1e/0x40
[ 28.026761] [<ffffffffa0424277>] intelfb_create+0x107/0x510 [i915]
[ 28.026778] [<ffffffffa020f807>] ? drm_mode_create+0x47/0x70 [drm]
[ 28.026786] [<ffffffffa01a404e>]
drm_fb_helper_initial_config+0x2fe/0x550 [drm_kms_helper]
[ 28.026813] [<ffffffffa0431323>] ? i915_write32+0xc3/0x190 [i915]
[ 28.026838] [<ffffffffa0424751>] intel_fbdev_initial_config+0x21/0x30 [i915]
[ 28.026859] [<ffffffffa03cb38d>] i915_driver_load+0xe9d/0xed0 [i915]
[ 28.026876] [<ffffffffa020aad1>] drm_get_pci_dev+0x181/0x2a0 [drm]
[ 28.026881] [<ffffffff8137b12d>] ? do_raw_spin_unlock+0x5d/0xb0
[ 28.026900] [<ffffffffa03c75d6>] i915_pci_probe+0x36/0x70 [i915]
[ 28.026905] [<ffffffff81399ceb>] local_pci_probe+0x4b/0x80
[ 28.026910] [<ffffffff8139b5c1>] pci_device_probe+0x101/0x120
[ 28.026915] [<ffffffff81478a1b>] driver_probe_device+0x7b/0x240
[ 28.026920] [<ffffffff81478c8b>] __driver_attach+0xab/0xb0
[ 28.026924] [<ffffffff81478be0>] ? driver_probe_device+0x240/0x240
[ 28.026928] [<ffffffff81476b6e>] bus_for_each_dev+0x5e/0x90
[ 28.026932] [<ffffffff8147851e>] driver_attach+0x1e/0x20
[ 28.026936] [<ffffffff81477fc4>] bus_add_driver+0x104/0x2a0
[ 28.026941] [<ffffffff814793f4>] driver_register+0x64/0xf0
[ 28.026946] [<ffffffff8139a544>] __pci_register_driver+0x64/0x70
[ 28.026951] [<ffffffffa0475000>] ? 0xffffffffa0474fff
[ 28.026963] [<ffffffffa020ad0a>] drm_pci_init+0x11a/0x130 [drm]
[ 28.026968] [<ffffffffa0475000>] ? 0xffffffffa0474fff
[ 28.026987] [<ffffffffa0475066>] i915_init+0x66/0x68 [i915]
[ 28.026992] [<ffffffff8100207e>] do_one_initcall+0x4e/0x180
[ 28.026997] [<ffffffff81058413>] ? set_memory_nx+0x43/0x50
[ 28.027003] [<ffffffff810d147c>] load_module+0x209c/0x25b0
[ 28.027007] [<ffffffff810ce0a0>] ? show_initstate+0x50/0x50
[ 28.027013] [<ffffffff810d1a3c>] SyS_init_module+0xac/0xd0
[ 28.027018] [<ffffffff816f41ef>] tracesys+0xe1/0xe6
[ 28.027022] ---[ end trace be830cf8c302dde8 ]---
- Sedat -
On Tue, Aug 13, 2013 at 11:14 AM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 11:10 AM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell <[email protected]> wrote:
>>> Hi all,
>>>
>>> Changes since 20130812:
>>>
>>> The ext4 tree gained a conflict against Linus' tree.
>>>
>>> The infiniband tree gained a build failure for which I applied a merge
>>> fix patch and another so I used the version from next-20130812.
>>>
>>> The tty tree gained conflicts against the devicetree and tile trees.
>>>
>>> The usb tree gained a conflict against the net-next tree.
>>>
>>> The usb-gadget tree gained a build failure for which I reverted a commit.
>>>
>>> The ptr-ret tree gained a conflict against the staging tree.
>>>
>>> The akpm tree gained a conflict against the staging tree.
>>>
>>> ----------------------------------------------------------------------------
>>>
>>
>> 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).
>>
>> 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?
>>
>> - Sedat -
>
> [ From my dmesg ]
>
> [ 28.026524] ------------[ cut here ]------------
> [ 28.026557] WARNING: CPU: 3 PID: 639 at
> drivers/gpu/drm/i915/i915_gem.c:3435
> i915_gem_object_set_cache_level+0x389/0x3a0 [i915]()
> [ 28.026560] Modules linked in: arc4 snd_hwdep i915(+) iwldvm
> snd_pcm snd_page_alloc mac80211 snd_seq_midi parport_pc
> snd_seq_midi_event rfcomm bnep snd_rawmidi ppdev uvcvideo snd_seq
> btusb videobuf2_vmalloc i2c_algo_bit psmouse iwlwifi drm_kms_helper
> videobuf2_memops snd_timer drm snd_seq_device videobuf2_core bluetooth
> videodev serio_raw snd cfg80211 samsung_laptop wmi soundcore lp
> mac_hid video lpc_ich parport hid_generic usbhid hid usb_storage r8169
> mii
> [ 28.026610] CPU: 3 PID: 639 Comm: modprobe Not tainted
> 3.11.0-rc5-next20130813-1-iniza-small #1
> [ 28.026613] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [ 28.026616] 0000000000000d6b ffff8800795535a8 ffffffff816e259a
> 0000000000000007
> [ 28.026622] 0000000000000000 ffff8800795535e8 ffffffff810661dc
> ffffffff81376e70
> [ 28.026627] ffff8800746ba200 ffff8800746ba2b8 ffff88007a2c7000
> 0000000000000041
> [ 28.026632] Call Trace:
> [ 28.026641] [<ffffffff816e259a>] dump_stack+0x46/0x58
> [ 28.026647] [<ffffffff810661dc>] warn_slowpath_common+0x8c/0xc0
> [ 28.026653] [<ffffffff81376e70>] ? sg_kfree+0x30/0x30
> [ 28.026658] [<ffffffff8106622a>] warn_slowpath_null+0x1a/0x20
> [ 28.026680] [<ffffffffa03e1fe9>]
> i915_gem_object_set_cache_level+0x389/0x3a0 [i915]
> [ 28.026684] [<ffffffff8137723f>] ? sg_alloc_table+0x1f/0x50
> [ 28.026703] [<ffffffffa03e2162>]
> i915_gem_object_pin_to_display_plane+0x62/0x1c0 [i915]
> [ 28.026727] [<ffffffffa03f9b10>]
> intel_pin_and_fence_fb_obj+0xc0/0x140 [i915]
> [ 28.026732] [<ffffffff816e82ee>] ? mutex_lock+0x1e/0x40
> [ 28.026761] [<ffffffffa0424277>] intelfb_create+0x107/0x510 [i915]
> [ 28.026778] [<ffffffffa020f807>] ? drm_mode_create+0x47/0x70 [drm]
> [ 28.026786] [<ffffffffa01a404e>]
> drm_fb_helper_initial_config+0x2fe/0x550 [drm_kms_helper]
> [ 28.026813] [<ffffffffa0431323>] ? i915_write32+0xc3/0x190 [i915]
> [ 28.026838] [<ffffffffa0424751>] intel_fbdev_initial_config+0x21/0x30 [i915]
> [ 28.026859] [<ffffffffa03cb38d>] i915_driver_load+0xe9d/0xed0 [i915]
> [ 28.026876] [<ffffffffa020aad1>] drm_get_pci_dev+0x181/0x2a0 [drm]
> [ 28.026881] [<ffffffff8137b12d>] ? do_raw_spin_unlock+0x5d/0xb0
> [ 28.026900] [<ffffffffa03c75d6>] i915_pci_probe+0x36/0x70 [i915]
> [ 28.026905] [<ffffffff81399ceb>] local_pci_probe+0x4b/0x80
> [ 28.026910] [<ffffffff8139b5c1>] pci_device_probe+0x101/0x120
> [ 28.026915] [<ffffffff81478a1b>] driver_probe_device+0x7b/0x240
> [ 28.026920] [<ffffffff81478c8b>] __driver_attach+0xab/0xb0
> [ 28.026924] [<ffffffff81478be0>] ? driver_probe_device+0x240/0x240
> [ 28.026928] [<ffffffff81476b6e>] bus_for_each_dev+0x5e/0x90
> [ 28.026932] [<ffffffff8147851e>] driver_attach+0x1e/0x20
> [ 28.026936] [<ffffffff81477fc4>] bus_add_driver+0x104/0x2a0
> [ 28.026941] [<ffffffff814793f4>] driver_register+0x64/0xf0
> [ 28.026946] [<ffffffff8139a544>] __pci_register_driver+0x64/0x70
> [ 28.026951] [<ffffffffa0475000>] ? 0xffffffffa0474fff
> [ 28.026963] [<ffffffffa020ad0a>] drm_pci_init+0x11a/0x130 [drm]
> [ 28.026968] [<ffffffffa0475000>] ? 0xffffffffa0474fff
> [ 28.026987] [<ffffffffa0475066>] i915_init+0x66/0x68 [i915]
> [ 28.026992] [<ffffffff8100207e>] do_one_initcall+0x4e/0x180
> [ 28.026997] [<ffffffff81058413>] ? set_memory_nx+0x43/0x50
> [ 28.027003] [<ffffffff810d147c>] load_module+0x209c/0x25b0
> [ 28.027007] [<ffffffff810ce0a0>] ? show_initstate+0x50/0x50
> [ 28.027013] [<ffffffff810d1a3c>] SyS_init_module+0xac/0xd0
> [ 28.027018] [<ffffffff816f41ef>] tracesys+0xe1/0xe6
> [ 28.027022] ---[ end trace be830cf8c302dde8 ]---
>
>
> - Sedat -
Looks like there is patch to fix this WARNING, do not think it fixes
my screen corruption.
- Sedat -
http://lists.freedesktop.org/archives/intel-gfx/2013-August/031701.html
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:
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
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson <[email protected]> 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 -
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
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[email protected]> 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.
On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson <[email protected]> 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
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[email protected]> 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 <[email protected]> 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 -
On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[email protected]> 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 <[email protected]> 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 -
On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[email protected]> 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 <[email protected]> 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 -
On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek <[email protected]> wrote:
>>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[email protected]> 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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
:040000 040000 de063a052f39095f4d2f51b49caef9f827df41e8
1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers
See also attached files!
- Sedat -
On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek <[email protected]> wrote:
>>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek <[email protected]> wrote:
>>>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> Reviewed-by: Ville Syrjälä <[email protected]>
> Signed-off-by: Daniel Vetter <[email protected]>
>
> :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 -
On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek <[email protected]> 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 <[email protected]>
> > 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 <[email protected]>
> > Reviewed-by: Ville Syrj?l? <[email protected]>
> > Signed-off-by: Daniel Vetter <[email protected]>
> >
> > :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
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> > 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 <[email protected]>
>> > Reviewed-by: Ville Syrjälä <[email protected]>
>> > Signed-off-by: Daniel Vetter <[email protected]>
>> >
>> > :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 -
On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>> > 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 <[email protected]>
>>> > Reviewed-by: Ville Syrjälä <[email protected]>
>>> > Signed-off-by: Daniel Vetter <[email protected]>
>>> >
>>> > :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 -
On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek <[email protected]> wrote:
> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson <[email protected]> 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 <[email protected]> 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 <[email protected]>
> >>> > 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 <[email protected]>
> >>> > Reviewed-by: Ville Syrj?l? <[email protected]>
> >>> > Signed-off-by: Daniel Vetter <[email protected]>
> >>> >
> >>> > :040000 040000 de063a052f39095f4d2f51b49caef9f827df41e8
> >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers
> >>> >
> >>> > See also attached files!
> >>> >
> >>>
> >>> With the attached revert-patch my system is OK (with my customized X stack).
> >>
> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the
> >> scanout being misread.
> >>
> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen
> >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
> >>
> >> would be interesting.
> Attached both outputs with GOOD and BAD (BROKEN) kernel.
ggtt offset is the same for both setups, the only difference between the
two is the location of fbcon in stolen memory.
Can you please attach the output of intel_reg_dumper for good/bad? It's
a long shot...
Speaking of long shots, try this (slightly different to the earlier patch):
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index a21f935..37ad772 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
BUG();
}
+ if (obj->stolen && INTEL_INFO(dev)->gen >= 6)
+ alignment = 256 * 1024;
+
/* Note that the w/a also requires 64 PTE of padding following the
* bo. We currently fill all unused PTE with the shadow page and so
* we should always have valid PTE following the scanout preventing
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek <[email protected]> wrote:
>> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> >>> > 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 <[email protected]>
>> >>> > Reviewed-by: Ville Syrjälä <[email protected]>
>> >>> > Signed-off-by: Daniel Vetter <[email protected]>
>> >>> >
>> >>> > :040000 040000 de063a052f39095f4d2f51b49caef9f827df41e8
>> >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers
>> >>> >
>> >>> > See also attached files!
>> >>> >
>> >>>
>> >>> With the attached revert-patch my system is OK (with my customized X stack).
>> >>
>> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the
>> >> scanout being misread.
>> >>
>> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen
>> >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer
>> >>
>> >> would be interesting.
>
>> Attached both outputs with GOOD and BAD (BROKEN) kernel.
>
> ggtt offset is the same for both setups, the only difference between the
> two is the location of fbcon in stolen memory.
>
> Can you please attach the output of intel_reg_dumper for good/bad? It's
> a long shot...
>
> Speaking of long shots, try this (slightly different to the earlier patch):
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index a21f935..37ad772 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
> BUG();
> }
>
> + if (obj->stolen && INTEL_INFO(dev)->gen >= 6)
> + alignment = 256 * 1024;
> +
> /* Note that the w/a also requires 64 PTE of padding following the
> * bo. We currently fill all unused PTE with the shadow page and so
> * we should always have valid PTE following the scanout preventing
>
>
> --
Files attached.
- Sedat -
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> Files attached.
Can you also please attach a full dmesg so I can check for anything
unusual?
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> Files attached.
>
> Can you also please attach a full dmesg so I can check for anything
> unusual?
>
-2: BAD with your test-patch
-3: GOOD with your patch
- Sedat .-
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> Files attached.
> >
> > Can you also please attach a full dmesg so I can check for anything
> > unusual?
> >
Nothing scarred me on a couple of read throughs.
What happens if you try:
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 112c5e1..9828d9b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
return NULL;
ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
- 4096, DRM_MM_SEARCH_DEFAULT);
+ 1024*1024, DRM_MM_SEARCH_DEFAULT);
if (ret) {
kfree(stolen);
return NULL;
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
>> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> Files attached.
>> >
>> > Can you also please attach a full dmesg so I can check for anything
>> > unusual?
>> >
>
> Nothing scarred me on a couple of read throughs.
>
> What happens if you try:
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 112c5e1..9828d9b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
> return NULL;
>
> ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
> - 4096, DRM_MM_SEARCH_DEFAULT);
> + 1024*1024, DRM_MM_SEARCH_DEFAULT);
> if (ret) {
> kfree(stolen);
> return NULL;
>
> --
Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
from the top).
On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
So-to-say 3/4 "blind".
- Sedat -
On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson <[email protected]> wrote:
> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> >> Files attached.
> >> >
> >> > Can you also please attach a full dmesg so I can check for anything
> >> > unusual?
> >> >
> >
> > Nothing scarred me on a couple of read throughs.
> >
> > What happens if you try:
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index 112c5e1..9828d9b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
> > return NULL;
> >
> > ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
> > - 4096, DRM_MM_SEARCH_DEFAULT);
> > + 1024*1024, DRM_MM_SEARCH_DEFAULT);
> > if (ret) {
> > kfree(stolen);
> > return NULL;
> >
> > --
>
> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
> from the top).
> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
> So-to-say 3/4 "blind".
That implies that the scanout is always reading from the base of stolen.
Can you grab intel_reg_dumper so that I can check what values the
transcoder is set to?
At the moment, I am guessing that the display never sees the updated
surface offset and so persists with the value programmed by the BIOS -
which will be 0 and set to the base of stolen memory in the GTT. A
drm.debug=6 dmesg would help here as well.
If you forced a mode change, I think that too would restore the output.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson <[email protected]> wrote:
>> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
>> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> >> Files attached.
>> >> >
>> >> > Can you also please attach a full dmesg so I can check for anything
>> >> > unusual?
>> >> >
>> >
>> > Nothing scarred me on a couple of read throughs.
>> >
>> > What happens if you try:
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > index 112c5e1..9828d9b 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
>> > return NULL;
>> >
>> > ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
>> > - 4096, DRM_MM_SEARCH_DEFAULT);
>> > + 1024*1024, DRM_MM_SEARCH_DEFAULT);
>> > if (ret) {
>> > kfree(stolen);
>> > return NULL;
>> >
>> > --
>>
>> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>> from the top).
>> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>> So-to-say 3/4 "blind".
>
> That implies that the scanout is always reading from the base of stolen.
> Can you grab intel_reg_dumper so that I can check what values the
> transcoder is set to?
>
> At the moment, I am guessing that the display never sees the updated
> surface offset and so persists with the value programmed by the BIOS -
> which will be 0 and set to the base of stolen memory in the GTT. A
> drm.debug=6 dmesg would help here as well.
>
> If you forced a mode change, I think that too would restore the output.
With which kernel? Vanilla next-20130813? With any of your patches?
- Sedat -
On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson <[email protected]> wrote:
> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson <[email protected]> wrote:
> >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
> >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> >> >> Files attached.
> >> >> >
> >> >> > Can you also please attach a full dmesg so I can check for anything
> >> >> > unusual?
> >> >> >
> >> >
> >> > Nothing scarred me on a couple of read throughs.
> >> >
> >> > What happens if you try:
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> > index 112c5e1..9828d9b 100644
> >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
> >> > return NULL;
> >> >
> >> > ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
> >> > - 4096, DRM_MM_SEARCH_DEFAULT);
> >> > + 1024*1024, DRM_MM_SEARCH_DEFAULT);
> >> > if (ret) {
> >> > kfree(stolen);
> >> > return NULL;
> >> >
> >> > --
> >>
> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
> >> from the top).
> >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
> >> So-to-say 3/4 "blind".
> >
> > That implies that the scanout is always reading from the base of stolen.
> > Can you grab intel_reg_dumper so that I can check what values the
> > transcoder is set to?
> >
> > At the moment, I am guessing that the display never sees the updated
> > surface offset and so persists with the value programmed by the BIOS -
> > which will be 0 and set to the base of stolen memory in the GTT. A
> > drm.debug=6 dmesg would help here as well.
> >
> > If you forced a mode change, I think that too would restore the output.
>
> With which kernel? Vanilla next-20130813? With any of your patches?
Any but the working one ;-)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson <[email protected]> wrote:
>> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson <[email protected]> wrote:
>> >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
>> >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> >> >> Files attached.
>> >> >> >
>> >> >> > Can you also please attach a full dmesg so I can check for anything
>> >> >> > unusual?
>> >> >> >
>> >> >
>> >> > Nothing scarred me on a couple of read throughs.
>> >> >
>> >> > What happens if you try:
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> >> > index 112c5e1..9828d9b 100644
>> >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
>> >> > return NULL;
>> >> >
>> >> > ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
>> >> > - 4096, DRM_MM_SEARCH_DEFAULT);
>> >> > + 1024*1024, DRM_MM_SEARCH_DEFAULT);
>> >> > if (ret) {
>> >> > kfree(stolen);
>> >> > return NULL;
>> >> >
>> >> > --
>> >>
>> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>> >> from the top).
>> >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>> >> So-to-say 3/4 "blind".
>> >
>> > That implies that the scanout is always reading from the base of stolen.
>> > Can you grab intel_reg_dumper so that I can check what values the
>> > transcoder is set to?
>> >
>> > At the moment, I am guessing that the display never sees the updated
>> > surface offset and so persists with the value programmed by the BIOS -
>> > which will be 0 and set to the base of stolen memory in the GTT. A
>> > drm.debug=6 dmesg would help here as well.
>> >
>> > If you forced a mode change, I think that too would restore the output.
>>
>> With which kernel? Vanilla next-20130813? With any of your patches?
>
> Any but the working one ;-)
Damn Gmail, they switched again the UI, f***.
This is d-i-n with Revert "drm/i915: Allocate LLC ringbuffers from
stolen" <--- "working one" (no screen corruptions).
- Sedat -
On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson <[email protected]> wrote:
>> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson <[email protected]> wrote:
>>> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>>> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson <[email protected]> wrote:
>>> >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>>> >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
>>> >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>>> >> >> >> Files attached.
>>> >> >> >
>>> >> >> > Can you also please attach a full dmesg so I can check for anything
>>> >> >> > unusual?
>>> >> >> >
>>> >> >
>>> >> > Nothing scarred me on a couple of read throughs.
>>> >> >
>>> >> > What happens if you try:
>>> >> >
>>> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> >> > index 112c5e1..9828d9b 100644
>>> >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
>>> >> > return NULL;
>>> >> >
>>> >> > ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
>>> >> > - 4096, DRM_MM_SEARCH_DEFAULT);
>>> >> > + 1024*1024, DRM_MM_SEARCH_DEFAULT);
>>> >> > if (ret) {
>>> >> > kfree(stolen);
>>> >> > return NULL;
>>> >> >
>>> >> > --
>>> >>
>>> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>>> >> from the top).
>>> >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>>> >> So-to-say 3/4 "blind".
>>> >
>>> > That implies that the scanout is always reading from the base of stolen.
>>> > Can you grab intel_reg_dumper so that I can check what values the
>>> > transcoder is set to?
>>> >
>>> > At the moment, I am guessing that the display never sees the updated
>>> > surface offset and so persists with the value programmed by the BIOS -
>>> > which will be 0 and set to the base of stolen memory in the GTT. A
>>> > drm.debug=6 dmesg would help here as well.
>>> >
>>> > If you forced a mode change, I think that too would restore the output.
>>>
>>> With which kernel? Vanilla next-20130813? With any of your patches?
>>
>> Any but the working one ;-)
>
> Damn Gmail, they switched again the UI, f***.
>
> This is d-i-n with Revert "drm/i915: Allocate LLC ringbuffers from
> stolen" <--- "working one" (no screen corruptions).
>
> - Sedat -
Vanilla next-20130813 after 1st login and logout-unity2d-plus-relogin-lightdm.
The diff might be interesting as the 2nd login makes the issue go away.
- Sedat -
On Tue, Aug 13, 2013 at 10:33 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson <[email protected]> wrote:
>>> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
>>>> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson <[email protected]> wrote:
>>>> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>>>> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson <[email protected]> wrote:
>>>> >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>>>> >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson <[email protected]> wrote:
>>>> >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>>>> >> >> >> Files attached.
>>>> >> >> >
>>>> >> >> > Can you also please attach a full dmesg so I can check for anything
>>>> >> >> > unusual?
>>>> >> >> >
>>>> >> >
>>>> >> > Nothing scarred me on a couple of read throughs.
>>>> >> >
>>>> >> > What happens if you try:
>>>> >> >
>>>> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> >> > index 112c5e1..9828d9b 100644
>>>> >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
>>>> >> > return NULL;
>>>> >> >
>>>> >> > ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
>>>> >> > - 4096, DRM_MM_SEARCH_DEFAULT);
>>>> >> > + 1024*1024, DRM_MM_SEARCH_DEFAULT);
>>>> >> > if (ret) {
>>>> >> > kfree(stolen);
>>>> >> > return NULL;
>>>> >> >
>>>> >> > --
>>>> >>
>>>> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>>>> >> from the top).
>>>> >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>>>> >> So-to-say 3/4 "blind".
>>>> >
>>>> > That implies that the scanout is always reading from the base of stolen.
>>>> > Can you grab intel_reg_dumper so that I can check what values the
>>>> > transcoder is set to?
>>>> >
>>>> > At the moment, I am guessing that the display never sees the updated
>>>> > surface offset and so persists with the value programmed by the BIOS -
>>>> > which will be 0 and set to the base of stolen memory in the GTT. A
>>>> > drm.debug=6 dmesg would help here as well.
>>>> >
>>>> > If you forced a mode change, I think that too would restore the output.
>>>>
>>>> With which kernel? Vanilla next-20130813? With any of your patches?
>>>
>>> Any but the working one ;-)
>>
>> Damn Gmail, they switched again the UI, f***.
>>
>> This is d-i-n with Revert "drm/i915: Allocate LLC ringbuffers from
>> stolen" <--- "working one" (no screen corruptions).
>>
>> - Sedat -
>
> Vanilla next-20130813 after 1st login and logout-unity2d-plus-relogin-lightdm.
> The diff might be interesting as the 2nd login makes the issue go away.
>
intel_reg_dumper output attached.
- Sedat -