Created attachment 98080 [details] sys/class/drm/card0/error Am running: [ 34973.186] \n X.Org X Server 1.15.1 \n Release Date: 2014-04-13 [ 34973.186] X Protocol Version 11, Revision 0 [ 34973.186] Build Operating System: Linux 3.14.0-4-ARCH i686 [ 34973.186] Current Operating System: Linux e600 3.14.1-e600+ #11 SMP PREEMPT Tue Apr 22 03:30:04 CEST 2014 i686 with: Option "AccelMethod" "uxa" (since the default causes a great many rendering-probleems). Have seen this problem many times before as well: [ 0.000000] Linux version 3.14.1-e600+ (rene@e600) (gcc version 4.8.2 20140206 (prerelease) (GCC) ) #11 SMP PREEMPT Tue Apr 22 03:30:04 CEST 2014 [ ... ] [ 0.232279] Linux agpgart interface v0.103 [ 0.232377] agpgart-intel 0000:00:00.0: Intel 865 Chipset [ 0.232443] agpgart-intel 0000:00:00.0: detected gtt size: 131072K total, 131072K mappable [ 0.232612] agpgart-intel 0000:00:00.0: detected 8192K stolen memory [ 0.232830] agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xf0000000 [ 0.232936] [drm] Initialized drm 1.1.0 20060810 [ 0.234440] [drm] Memory usable by graphics device = 128M [ 0.234949] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 0.234998] [drm] Driver supports precise vblank timestamp query. [ 0.240265] [drm] initialized overlay support [ 0.293779] fbcon: inteldrmfb (fb0) is primary device [ 0.327098] Console: switching to colour frame buffer device 160x64 [ 0.332477] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 0.332514] i915 0000:00:02.0: registered panic notifier [ 0.332556] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ ... ] [18465.171262] [drm] GPU crash dump saved to /sys/class/drm/card0/error [18465.171267] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [18465.171269] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [18465.171270] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [18465.171272] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [18465.172253] i915: render error detected, EIR: 0x00000010 [18465.172253] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking [18465.175897] i915: render error detected, EIR: 0x00000010
(In reply to comment #0) > (since the default causes a great many rendering-probleems). Have seen this > problem many times before as well: Really? That would be the first I heard of them.
No, just having you on. Manually constructing that sysfs drm/card0/error dump did take quite some time I can tell you -- but hey, anything for a succesful belated april fools. Older Intel (865G here) has and had had for years metric tons of these sorts of problems. Given that I cannot interpret them, I cannot tell you with certainty that this current issue is always the same problem but certainly this message: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking has appeared for me regularly for multiple years now. If you google for it, you will find it's not just me either. If you were more specifically referring to needing UXA: the default, SNA I gather, causes all sorts of corruption; (most) immediately triggerable in a terminal; mate-terminal now, but the xfce terminal and I believe rxvt were also affected. Quite often the first line of output will be invisible. Both with a white on black and a black on white terminal, by the way. This time it's the first time that I saw the kernel messages advice reporting it (or cared -- what do I know) and hence the current report. But given that things still seem to work, the vast majoriry of users simply ignores it. Add in a slinking "vast" majority of old Intel users and you just get one or at best a few of them.
(In reply to comment #2) > No, just having you on. Manually constructing that sysfs drm/card0/error > dump did take quite some time I can tell you -- but hey, anything for a > succesful belated april fools. > > Older Intel (865G here) has and had had for years metric tons of these sorts > of problems. Given that I cannot interpret them, I cannot tell you with > certainty that this current issue is always the same problem but certainly > this message: > > [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking > > has appeared for me regularly for multiple years now. If you google for it, > you will find it's not just me either. This error is not unknown to us. Just we have the occassional overzealous bug scrub that closes those bug reports as obsolete, even though we know that we haven't root caused the issue. > If you were more specifically referring to needing UXA: the default, SNA I > gather, causes all sorts of corruption; (most) immediately triggerable in a > terminal; mate-terminal now, but the xfce terminal and I believe rxvt were > also affected. Quite often the first line of output will be invisible. Both > with a white on black and a black on white terminal, by the way. Indeed I was. I need your Xorg.0.log so that I have an idea about software versions for starters.
Created attachment 98092 [details] My Xorg.0.log Here you go, with accompanying configuration below. Option "TearFree" was only recently added when browsing the manpage since it seemed to make sense -- is not related to any SNA trouble. Section "Screen" is present only since I needed it when I also had a Device section, since otherwise things... well, actually bombed out I believe; I can't restart X now to test. $ cat /etc/X11/xorg.conf.d/10-intel.conf Section "Device" Identifier "Device0" Driver "intel" Option "AccelMethod" "uxa" Option "TearFree" EndSection Section "Screen" Identifier "Screen0" Device "Device0" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection Back when SNA was made default, probably more then a year ago now?, the arch-linux upgrade helpfully noticed that I might need to set it back to UXA if I had trouble, which I immediately had and did. I have since then always run with UXA. Recently retested, the problems are still present. Arch defaul or custom kernel (as currently) makes no difference.
Could you please test with latest drm-intel-nightly to see if the issue is still present and paste new logs?
timeout. Feel free to reopen if you are still able to reproduce on recent kernels updating new logs.
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.