After eliminating the other members of the stack, It appears that 4.0~rc1 has a regression. One of two things happen: 1) Feb 25 18:24:42 Aesop kernel: [ 1318.339897] [drm] stuck on render ring Feb 25 18:24:42 Aesop kernel: [ 1318.341695] [drm] GPU HANG: ecode 3:0:0x02e6ffc1, in Xorg [2282], reason: Ring hung, action: reset Feb 25 18:24:42 Aesop kernel: [ 1318.341698] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. Feb 25 18:24:42 Aesop kernel: [ 1318.341700] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel Feb 25 18:24:42 Aesop kernel: [ 1318.341702] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. Feb 25 18:24:42 Aesop kernel: [ 1318.341703] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. Feb 25 18:24:42 Aesop kernel: [ 1318.341705] [drm] GPU crash dump saved to /sys/class/drm/card0/error Feb 25 18:24:42 Aesop kernel: [ 1318.371624] drm/i915: Resetting chip after gpu hang Feb 25 18:48:56 Aesop kernel: [ 2772.339749] [drm] stuck on render ring Feb 25 18:48:56 Aesop kernel: [ 2772.341710] [drm] GPU HANG: ecode 3:0:0x02faffcf, in Xorg [2282], reason: Ring hung, action: reset Feb 25 18:48:56 Aesop kernel: [ 2772.371456] drm/i915: Resetting chip after gpu hang which you can restart X (provided you know your system blind as nothing is intelligent on the screen.) This occurs seemingly at random, frequently. 2) The system just locks - screen perfectly frozen. Cycle the power. No trace of any crash or oops. As usual, for item one - you can not get at the crash dump when you try to ssh into the box to look at it; its ALWAYS empty (/sys/class/drm/card0/error). Also there is no pattern as to when it happens either. Additional info: OpenGL renderer string: Gallium 0.4 on i915 (chipset: 945G) OpenGL version string: 2.1 Mesa 10.4.5 Compiled with: gcc version 4.9.2 (Both OS & Mesa) xorg-server: 1.15.1 Module intel: vendor="X.Org Foundation" compiled for 1.15.1, module version = 2.99.917 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 15.0 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-0-reaper root=UUID=8536097e-c02a-4a8c-9cdf-b40ba4e3b74d ro crashkernel=384M-2G:64M,2G-:128M drm_kms_helper.edid_firmware=edid/1280x1024_75.bin thermal.crt=75 quiet splash vt.handoff=7 BIOS DMI: ECS 945GCT-M2/945GCT-M2, BIOS 080012 07/18/2008 Thanks in advance again for your help.
/sys/class/drm/card0/error is never empty; ls lies.
cat too? must be a conspiracy.
It's a conspiracy: =0 ickle:/usr/src/linux$ sudo cat /sys/class/drm/card0/error no error state collected
Oops "its ALWAYS empty" -pedantic == "devoid of useful information" meā culpā.
Please attach whatever you can find in /sys/class/drm/card0/error and dmesg after hang type 1. Also try i915c rather i915g (i.e. the intel driver rather than the gallium version). Attaching Xorg.0.log would explain a bit more.
K Will have for you tommorow AM (GMT +8)
It took around TWENTY crashes before I finally got an error log in sys... nothing really useful in the other files but here they are. This is with the gallium driver. I'll do the regular driver next.
Created attachment 113908 [details] Requested logs gallium driver
Oh, that is interesting. The kernel did not release the fence for the vertex buffer, which is naughty. 0x018000d8: 0x7d040031: 3DSTATE_LOAD_STATE_IMMEDIATE_1 0x018000dc: 0x01500000: S0: vbo offset: 0x01500000 0x018000e0: 0x04040000: S1: vertex width: 4, vertex pitch: 4 but 01500000 262144 76 00 19dc 0 dirty render uncached (fence: 11) fence[11] = 01500031 valid, x-tiled, pitch: 4096, start: 0x01500000, size: 1048576
(I am not sure if that actually would cause a GPU hang, but if you get a chance a kernel bisect would be useful, I have a few suspect commits in mind...)
Created attachment 113914 [details] [review] Ensure that no fences are active for the vertex buffer This tests the same idea from xf86-video-intel by flagging that the kernel needs to revoke any fences on the vertex buffers.
Actually thinking about what changed: it is that we no longer use the GTT to write into the vertex buffers so the fence is no longer being flushed before the batch. Interesting...
Created attachment 113915 [details] w/o gallium
Created attachment 113925 [details] Result after patch 113914 applied
(In reply to Chris Wilson from comment #10) > (I am not sure if that actually would cause a GPU hang, but if you get a > chance a kernel bisect would be useful, I have a few suspect commits in > mind...) Care to share so I can try before I have to do the bisect?
My explanation got cut about your patch: After I applied your patch I thought that you nailed it but the problem persists; however, syslog doesn't complain but the error log AND xorg do. I enclose both for your perusal. What was different also was that this time I didn't have to keep trying until a error log was produced - It was produced when the issue happened.
(In reply to Jim from comment #16) > My explanation got cut about your patch: > > After I applied your patch I thought that you nailed it but the problem > persists; however, syslog doesn't complain but the error log AND xorg do. I > enclose both for your perusal. What was different also was that this time I > didn't have to keep trying until a error log was produced - It was produced > when the issue happened. (In reply to Jim from comment #14) > Created attachment 113925 [details] > Result after patch 113914 applied Right, I think perhaps we have a second issue here. Sadly the error capture failed - it dumped the wrong batch - could you grab a few more and lets see if one pinpoints the issue. So I think the fenced vertex buffer is definitely one issue, and that is probably responsible for the system hangs. Now on to the next.
Ok, the no-gallium logs point towards an incoherent batch buffer. It's likely to bisect to mmap(wc) again, but the symptoms are a little more puzzling.
Created attachment 113929 [details] [review] Force set-domain on batch I hope this does not match a difference...
Created attachment 113934 [details] more logs without gallium The second patch seems to make things worse for the no gallium driver as well as the gallium driver.
Created attachment 113935 [details] with gallium & both patches With the second patch to xf86 driver the gallium driver acts like it always did except it now logs the error in the error file. With only the first patch, the problem does not happen nearly as much - So for the gallium driver, just the first patch works better than both patches together.
I will send more logs when I have more time latter. I thought you might like to have a look at these while you wait.
One final ddx change just to check a potential root cause of the problem: diff --git a/src/sna/kgem.c b/src/sna/kgem.c index a5571aa..adf52d6 100644 --- a/src/sna/kgem.c +++ b/src/sna/kgem.c @@ -83,7 +83,7 @@ search_snoop_cache(struct kgem *kgem, unsigned int num_pages, unsigned flags); #define DBG_NO_FAST_RELOC 0 #define DBG_NO_HANDLE_LUT 0 #define DBG_NO_WT 0 -#define DBG_NO_WC_MMAP 0 +#define DBG_NO_WC_MMAP 1 #define DBG_DUMP 0 #define DBG_NO_MALLOC_CACHE 0
(In reply to Chris Wilson from comment #23) > One final ddx change just to check a potential root cause of the problem: > > diff --git a/src/sna/kgem.c b/src/sna/kgem.c > index a5571aa..adf52d6 100644 > --- a/src/sna/kgem.c > +++ b/src/sna/kgem.c > @@ -83,7 +83,7 @@ search_snoop_cache(struct kgem *kgem, unsigned int > num_pages, unsigned flags); > #define DBG_NO_FAST_RELOC 0 > #define DBG_NO_HANDLE_LUT 0 > #define DBG_NO_WT 0 > -#define DBG_NO_WC_MMAP 0 > +#define DBG_NO_WC_MMAP 1 > #define DBG_DUMP 0 > #define DBG_NO_MALLOC_CACHE 0 OK have more for you in the AM. Many thanks for your time.
I had just 1 (one) system lock-up. No hang yet. The screen now goes black for about 3 sec the comes back to normal. This happens about once every 60-90 min. I will run piglet all night and post back the results. You were right - goes to mmap.
No more hangs it is a bit slow though. Sorry I took so long - had to go on a trip.
I now get these diatribes: After these happen you have to power cycle as system is frozen. Mar 13 07:12:54 Aesop kernel: [ 9132.585443] ------------[ cut here ]------------ Mar 13 07:12:54 Aesop kernel: [ 9132.585489] kernel BUG at /home/jim/software/ubuntu/4.0-rc3/drivers/gpu/drm/drm_mm.c:305! Mar 13 07:12:54 Aesop kernel: [ 9132.585533] invalid opcode: 0000 [#1] SMP Mar 13 07:12:54 Aesop kernel: [ 9132.585562] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_DSCP ctr ccm nf_log_ipv4 nf_log_common xt_tcpudp ip6table_mangle nf_conntrack_irc xt_TCPMSS xt_LOG ipt_REJECT xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp ip6table_filter ip6_tables lp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 gspca_zc3xx gspca_main cfg80211 videodev cdc_ether usbnet uas snd_hda_codec_idt usb_storage snd_hda_codec_generic snd_hda_intel snd_hda_controller ipv6 snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore gpio_ich lpc_ich mfd_core ppdev serio_raw parport_pc parport it87 hwmon_vid pata_acpi 8139too 8139cp mii i915 drm_kms_helper Mar 13 07:12:54 Aesop kernel: [ 9132.585763] CPU: 1 PID: 4416 Comm: compiz Not tainted 4.0.0-0-reaper #3~rc3 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] Hardware name: ECS 945GCT-M2/945GCT-M2, BIOS 080012 07/18/2008 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] task: ffff88005c53dfc0 ti: ffff88007b2ac000 task.ti: ffff88007b2ac000 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] RIP: 0010:[<ffffffff814a00c2>] [<ffffffff814a00c2>] drm_mm_insert_node_in_range_generic+0x3a7/0x3b0 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] RSP: 0018:ffff88007b2afa28 EFLAGS: 00010206 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] RAX: ffff88003047b600 RBX: 0000000000000000 RCX: ffff88003047b610 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] RDX: 0000000000118000 RSI: ffff88003047b500 RDI: ffff88003047b600 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] RBP: ffff88007b2afab8 R08: 0000000000018000 R09: 0000000000000000 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] R10: 0000000000100000 R11: 0000000000000000 R12: 0000000000000000 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] R13: 0000000000000000 R14: ffff880078037e08 R15: ffff88003047b500 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] FS: 00007fc366636780(0000) GS:ffff88007f480000(0000) knlGS:0000000000000000 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] CR2: 00007fc343976000 CR3: 0000000057cc6000 CR4: 00000000000007e0 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] Stack: Mar 13 07:12:54 Aesop kernel: [ 9132.585763] ffff88003047b600 0000000000100000 ffff88003047b500 0000000000100000 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] 0010000000000000 0000000000000000 0000000000018000 0000000000018000 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] ffff88007b2afa88 0000000000100000 0000000000100000 000000005fe9b2fa Mar 13 07:12:54 Aesop kernel: [ 9132.585763] Call Trace: Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffffa00578cb>] i915_gem_object_pin_view+0x627/0x89d [i915] Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffffa0049d65>] i915_gem_execbuffer_reserve_vma.isra.16+0x6f/0xf5 [i915] Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffffa004a0ee>] i915_gem_execbuffer_reserve+0x303/0x364 [i915] Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffffa004ab37>] i915_gem_do_execbuffer.isra.22+0x5a0/0x101d [i915] Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff81172b94>] ? __slab_free+0x66/0x249 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffffa00563a2>] ? i915_gem_object_put_fence+0x20/0xe4 [i915] Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff81172ac1>] ? __kmalloc+0x10e/0x17b Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffffa004c7cf>] i915_gem_execbuffer2+0xb2/0x283 [i915] Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff81497c8b>] drm_ioctl+0x1d2/0x5cb Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff811991a5>] ? __dentry_kill+0x145/0x1be Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff811993ea>] ? dput+0x1cc/0x1fd Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff81195cde>] do_vfs_ioctl+0x355/0x4ae Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff81183c88>] ? ____fput+0xe/0x10 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff81195eb0>] SyS_ioctl+0x79/0x89 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] [<ffffffff816dce76>] system_call_fastpath+0x16/0x1b Mar 13 07:12:54 Aesop kernel: [ 9132.585763] Code: ff 48 89 f0 e9 ae fe ff ff b8 e4 ff ff ff e9 4e ff ff ff 0f 0b 8b 4d 94 29 d1 48 8d 04 31 48 89 45 b8 e9 90 fe ff ff 0f 0b 0f 0b <0f> 0b 0f 0b e8 d4 f7 ba ff 0f 1f 44 00 00 55 48 89 e5 41 57 41 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] RIP [<ffffffff814a00c2>] drm_mm_insert_node_in_range_generic+0x3a7/0x3b0 Mar 13 07:12:54 Aesop kernel: [ 9132.585763] RSP <ffff88007b2afa28> Mar 13 07:12:54 Aesop kernel: [ 9132.673716] ---[ end trace b5709a427aa7df79 ]--- another: Mar 13 07:23:42 Aesop kernel: [ 516.020001] ------------[ cut here ]------------ Mar 13 07:23:42 Aesop kernel: [ 516.020046] kernel BUG at /home/jim/software/ubuntu/4.0-rc3/drivers/gpu/drm/drm_mm.c:305! Mar 13 07:23:42 Aesop kernel: [ 516.020090] invalid opcode: 0000 [#1] SMP Mar 13 07:23:42 Aesop kernel: [ 516.020119] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_DSCP cdc_ether usbnet uas usb_storage ctr ccm nf_log_ipv4 nf_log_common xt_tcpudp ip6table_mangle nf_conntrack_irc xt_TCPMSS xt_LOG ipt_REJECT xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp ip6table_filter ip6_tables lp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 cfg80211 gspca_zc3xx gspca_main videodev snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec ipv6 snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore gpio_ich lpc_ich mfd_core serio_raw ppdev parport_pc parport it87 hwmon_vid pata_acpi 8139too 8139cp mii i915 drm_kms_helper Mar 13 07:23:42 Aesop kernel: [ 516.020709] CPU: 0 PID: 4429 Comm: compiz Not tainted 4.0.0-0-reaper #3~rc3 Mar 13 07:23:42 Aesop kernel: [ 516.020746] Hardware name: ECS 945GCT-M2/945GCT-M2, BIOS 080012 07/18/2008 Mar 13 07:23:42 Aesop kernel: [ 516.020782] task: ffff8800774a17f0 ti: ffff880053bd8000 task.ti: ffff880053bd8000 Mar 13 07:23:42 Aesop kernel: [ 516.020822] RIP: 0010:[<ffffffff814a00c2>] [<ffffffff814a00c2>] drm_mm_insert_node_in_range_generic+0x3a7/0x3b0 Mar 13 07:23:42 Aesop kernel: [ 516.020884] RSP: 0018:ffff880053bdba28 EFLAGS: 00010206 Mar 13 07:23:42 Aesop kernel: [ 516.020914] RAX: ffff88002a60c800 RBX: 0000000000000000 RCX: ffff88002a60c810 Mar 13 07:23:42 Aesop kernel: [ 516.022960] RDX: 0000000001c00000 RSI: ffff88007829fa00 RDI: ffff88002a60c800 Mar 13 07:23:42 Aesop kernel: [ 516.023289] RBP: ffff880053bdbab8 R08: 0000000000700000 R09: 0000000000000000 Mar 13 07:23:42 Aesop kernel: [ 516.023289] R10: 0000000001800000 R11: 0000000000000000 R12: 0000000000000000 Mar 13 07:23:42 Aesop kernel: [ 516.023289] R13: 0000000000000000 R14: ffff880078007e08 R15: ffff88007829fa00 Mar 13 07:23:42 Aesop kernel: [ 516.023289] FS: 00007ffa49876780(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000 Mar 13 07:23:42 Aesop kernel: [ 516.023289] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 13 07:23:42 Aesop kernel: [ 516.023289] CR2: 00007ffa26f16000 CR3: 000000005ef39000 CR4: 00000000000007f0 Mar 13 07:23:42 Aesop kernel: [ 516.023289] Stack: Mar 13 07:23:42 Aesop kernel: [ 516.023289] ffff88002a60c800 0000000001000000 ffff88007829fa00 0000000001800000 Mar 13 07:23:42 Aesop kernel: [ 516.023289] 0100000000000000 0000000000000000 0000000000700000 0000000000c00000 Mar 13 07:23:42 Aesop kernel: [ 516.023289] dead000000100100 0000000001000000 0000000001800000 0000000030408e9c Mar 13 07:23:42 Aesop kernel: [ 516.043640] Call Trace: Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffffa00578cb>] i915_gem_object_pin_view+0x627/0x89d [i915] Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffffa005020b>] ? i915_gem_obj_lookup_or_create_vma_view+0x46/0x1bf [i915] Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffffa0049d65>] i915_gem_execbuffer_reserve_vma.isra.16+0x6f/0xf5 [i915] Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffffa004a0ee>] i915_gem_execbuffer_reserve+0x303/0x364 [i915] Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffffa004ab37>] i915_gem_do_execbuffer.isra.22+0x5a0/0x101d [i915] Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff81172b94>] ? __slab_free+0x66/0x249 Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffffa00563a2>] ? i915_gem_object_put_fence+0x20/0xe4 [i915] Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff81172ac1>] ? __kmalloc+0x10e/0x17b Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffffa004c7cf>] i915_gem_execbuffer2+0xb2/0x283 [i915] Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff81497c8b>] drm_ioctl+0x1d2/0x5cb Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff811991a5>] ? __dentry_kill+0x145/0x1be Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff811993ea>] ? dput+0x1cc/0x1fd Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff81195cde>] do_vfs_ioctl+0x355/0x4ae Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff81183c88>] ? ____fput+0xe/0x10 Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff81195eb0>] SyS_ioctl+0x79/0x89 Mar 13 07:23:42 Aesop kernel: [ 516.043640] [<ffffffff816dce76>] system_call_fastpath+0x16/0x1b Mar 13 07:23:42 Aesop kernel: [ 516.043640] Code: ff 48 89 f0 e9 ae fe ff ff b8 e4 ff ff ff e9 4e ff ff ff 0f 0b 8b 4d 94 29 d1 48 8d 04 31 48 89 45 b8 e9 90 fe ff ff 0f 0b 0f 0b <0f> 0b 0f 0b e8 d4 f7 ba ff 0f 1f 44 00 00 55 48 89 e5 41 57 41 Mar 13 07:23:42 Aesop kernel: [ 516.043640] RIP [<ffffffff814a00c2>] drm_mm_insert_node_in_range_generic+0x3a7/0x3b0 Mar 13 07:23:42 Aesop kernel: [ 516.043640] RSP <ffff880053bdba28> Mar 13 07:23:42 Aesop kernel: [ 516.094834] ---[ end trace 165f5c9e30f1777e ]---
Update. Using xf86-video-intel commit 254bbd67 AND updating the kernel to 4.0~rc4 seems to be working - I still infrequently get machine hangs where the colors bleed all over the screen and the machine hangs. I'm not able to capture any details about that though. Any suggestions? Thanks As far as I'm concerned, you may close this if you want.
Created attachment 114362 [details] New error reports Every time just when I think it fixed. Please see log if it offers anything new.
Yeah, the CS is still exhibiting incoherence. :(
Created attachment 114700 [details] log from rc5 Here is one from rc5. Cheers
I have not been able to test rc 6 & 7 because both versions cause X to seg fault. I need to use UXA instead of SNA now. This was the last thing I checked because I had ruled out SNA/UXA as a factor earlier - but since rc6 my hand is forced to use UXA. It is a performance hit in certain areas - but still acceptable considering... If i go back to rc5, Using either SNA or UXB I still exhibit the same failure. It is also the same whether I use Gallium drivers or the intel c driver.
rc6, rc7 and 4.0 final exhibits no error if I disable SNA. This is a bit confusing to me but it is what it is.
Slackware -current (xf86-video-intel-git_20150824_3e07681) kernel 4.1.6 on an IBM T60: [ 1741.004033] [drm] stuck on render ring [ 1741.005028] [drm] GPU HANG: ecode 3:0:0x70efffc1, in Xorg [890], reason: Ring hung, action: reset [ 1741.005031] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 1741.005033] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 1741.005035] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 1741.005036] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 1741.005038] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 1741.315597] drm/i915: Resetting chip after gpu hang
Created attachment 117912 [details] /sys/class/drm/card0/error
Bug scrub: Priority updated to medium.
Update and an observation: Using kernel 4.6 (from rc1 to release - no other kernel works) and mesa 11.2.2 (no other version works), using SNA not UXA. Driver version Problem has disappeared. I have found no other Linux/Mesa combination that works. I have 9 machines that have been running flawlessly since my birthday er May 13, 2016). Driver is at 2.99.917. Driver can be release version or with any updates since release. In fact ANY recent versions work as long as kernel is 4.6 AND Mesa is at 11.2.2. Cheers
*** This bug has been marked as a duplicate of bug 90841 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.