Faulty intel graphics

CBiX · 2020-01-16 16:32:32

HW: Thinkpad X250 with i5-5300U

Since 2 days ago (I was just trying to set up OBS studio) I'm having some serious issues regarding hardware acceleration with GNOME on X11, with colors and fonts being messed up as you can see in this screen recording: https://i.imgur.com/DnYivdz.mp4
It's not due to any upgrade or configuration change as the problems also occur on a fresh Ubuntu live system. Also I don't get any notable errors in dmesg or /sys/class/drm/card0/error...

When using `Option "DRI" "false"` in the xorg config most of the glitches disappear, but I still experience missing or corrupted font characters/glyphs.

How can I further debug this issue? Any configuration options or kernel params I should try out? Is there some kind of GPU integrity testing tool?

/etc/X11/xorg.conf.d/20-intel.conf:

Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "AccelMethod"   "sna"
    Option      "TripleBuffer"  "true"
    Option      "TearFree"      "true"
    Option      "DRI"           "false"
EndSection

Thanks!

Trilby · 2020-01-16 16:39:27

Get rid of xf86-video-intel, it is a well known and well documented source of problems just like yours. The modesetting driver performs much better on a wide variety of hardware - most notably (IMHO) on Thinkpads. You'll also then have to remove your 20-intel.conf.

Last edited by Trilby (2020-01-16 16:40:08)

CBiX · 2020-01-16 19:00:56

Thanks for the tip, I also read it's the source of a lot of problems, but apparently not for this one: https://i.imgur.com/PzKfVYY.mp4

I'll try different configurations for the modesetting driver though... Right now I believe the graphics chip is kind of broken or maybe a clock connected to it.

Update: ok, so far modesetting with the following config seems to be the best option, the graphics performance is even better than before but there are still some rare glyph issues, e.g. gnome-terminal not displaying the light grey text at the right of the bars in htop in contrast to the dark grey text on the light theme: https://i.imgur.com/ySigK7Z.png ... Anyway it's a lot better now compared to before!

Section "Device"
    Identifier  "Intel Graphics"
    Driver      "modesetting"
    Option      "AccelMethod"     "none"
EndSection

Last edited by CBiX (2020-01-16 20:29:25)

V1del · 2020-01-16 20:50:35

What's in your dmesg when the issue occurs? Have you tried the LTS kernel? This does start to look like hardware failure to be frank.

Trilby · 2020-01-17 00:06:32

CBiX wrote:

Thanks for the tip, I also read it's the source of a lot of problems, but apparently not for this one

This may be true - but I'm at a loss, what lead you to this assertion? You link to another video showing the problem, but I don't see how that's relevant to assessing whether the intel driver is the problem or not.

CBiX · 2020-01-17 01:20:30

Trilby wrote:

I don't see how that's relevant to assessing whether the intel driver is the problem or not.

The 2nd video is the same problem using the modesetting driver with hw acceleration, after removing the xf86-video-intel package.

c00ter · 2020-01-17 04:22:33

Remove the config file and reboot. For some reason it is not always enough just to remove the driver.

CBiX · 2020-01-17 11:33:54

V1del wrote:

What's in your dmesg when the issue occurs? Have you tried the LTS kernel? This does start to look like hardware failure to be frank.

Switching to the LTS kernel didn't help, unfortunately, and I couldn't find any differences in the log.

c00ter wrote:

Remove the config file and reboot. For some reason it is not always enough just to remove the driver.

Sorry, I didn't make it clear the first time: the 2nd video is with driver and config removed.

Also I don't know what I tested before with acceleration turned off but especially with 3D and video playback the performance is really bad now... At least I can code on in peace without getting a seizure from all the flickering.

V1del · 2020-01-17 11:47:11

Well what's in the log? Post the output, otherwise we can't really diagnose anything. If it isn't fixed by the LTS kernel then it shouldn't be the usual i915 bugs that have surfaced in recent kernel versions and you might be in a bit of a pickle here. Maybe test a live disk of a different distribution. Also maybe run a memtest for a day or so to ensure your memory is alright.

Last edited by V1del (2020-01-17 11:47:58)

CBiX · 2020-01-17 14:32:33

modesetting with config: dmesg, Xorg.0.log
modesetting without config: dmesg, Xorg.0.log

Hope this helps.

I tested both Ubuntu 19.10 and KDE neon live distros and experienced the same graphics issue right away, which made me believe it's a hardware issue. I didn't run a full memtest yet but the issue persisted when changing the memory (which I just purchased recently). I'm going to try testing MS Windows and then ask the vendor for a replacement, but I'd really like to understand this issue better. Is it possible that there was a short circuit or sth on one of the display ports leading to this issue?

Update: I have the exact same graphics issue on Windows 10, which confirms my theory, so I'll be running Arch with graphics acceleration turned off until I get a hardware replacement.

Last edited by CBiX (2020-01-19 00:17:11)

CBiX · 2020-05-18 15:25:05

Quick update after now 4 months of working with basically llvmpipe as my software GPU, one BIOS upgrade and multiple kernel upgrades (now on 5.6.13). When testing with modesetting and iGPU acceleration, the "new" big problem now seems to be the kind of GPU hangs that people had with intel on previous kernels, along with just getting a blank screen with a cursor instead of the glitches I had before:

[   25.671019] i915 0000:00:02.0: GPU HANG: ecode 8:1:85dffff9, in Xorg [932]
[   25.671021] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[   25.671021] Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/intel/issues/new.
[   25.671021] Please see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details.
[   25.671022] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[   25.671022] The GPU crash dump is required to analyze GPU hangs, so please always attach it.
[   25.671023] GPU crash dump saved to /sys/class/drm/card0/error
[   25.773816] i915 0000:00:02.0: Resetting rcs0 for stopped heartbeat on rcs0
[   25.773825] i915 0000:00:02.0: Xorg[932] context reset due to GPU hang

Full dmesg log and /sys/class/drm/card0/error. Maybe something looks familiar to someone so I'm happy about any hints!
Tried Wayland a few times also and same problem there but I don't know how to disable GPU acceleration so I'm staying on X11 for now.

The refurbisher wouldn't replace the device and I'm getting sick of switching to my older laptop for the occasional app development just for proper OpenGL so I'm gonna try with some research on those GPU hangs.

jones · 2020-05-19 10:31:14

CBiX wrote:

Thanks for the tip, I also read it's the source of a lot of problems, but apparently not for this one: https://i.imgur.com/PzKfVYY.mp4
I'll try different configurations for the modesetting driver though... Right now I believe the graphics chip is kind of broken or maybe a clock connected to it.
Update: ok, so far modesetting with the following config seems to be the best option, the graphics performance is even better than before but there are still some rare glyph issues, e.g. gnome-terminal not displaying the light grey text at the right of the bars in htop in contrast to the dark grey text on the light theme: https://i.imgur.com/ySigK7Z.png ... Anyway it's a lot better now compared to before!
Section "Device"
    Identifier  "Intel Graphics"
    Driver      "modesetting"
    Option      "AccelMethod"     "none"
EndSection

Was kind of hoping for a (legitimate) bump of this of this topic because I don't know if my post warranted one.

I am too using a solarized look on my (XFCE-)terminal. And about your second screenshot, this one: : https://i.imgur.com/ySigK7Z.png
htop's load percentages seem to formatted in a dark and bold font by default, in my experience a deep blue. So if the terminal background has the rough color tone... it's incredibly difficult to seen them, if not impossible.

CBiX · 2020-05-19 14:11:27

jones wrote:

I am too using a solarized look on my (XFCE-)terminal. And about your second screenshot, this one: : https://i.imgur.com/ySigK7Z.png
htop's load percentages seem to formatted in a dark and bold font by default, in my experience a deep blue. So if the terminal background has the rough color tone... it's incredibly difficult to seen them, if not impossible.

I since switched to the Tango color palette with my default dark system theme (seems like it's using the Tango dark scheme but with the darker background color from my materia-dark GTK theme). I like the blue-ish solarized color but dark grey just goes along better with my GTK theme and literally all my screens

Anyway, I don't remember how I tested my performance back when writing that post. Performance is really only ok when I'm not using any application that uses lots of immediate-mode graphics / GL animations.

loqs · 2020-05-19 15:34:29

Have you tried drm-tip to see if the issue is fixed upstream? Will currently need a patch for gcc10 see https://bbs.archlinux.org/viewtopic.php … 3#p1905753

CBiX · 2020-05-19 16:32:59

loqs wrote:

Have you tried drm-tip to see if the issue is fixed upstream? Will currently need a patch for gcc10 see https://bbs.archlinux.org/viewtopic.php … 3#p1905753

Building now, will report later if that changes anything. I'm still wondering what's the chance of a hardware fault like this just appearing with an iGPU, as I also had those glitches when trying the original Windows 10 drive that used to work perfectly with my laptop. But probably the glitches and the GPU hangs in the logs are two separate issues...

Update: Still not working with 5.7.0-rc5-1-drm-tip-git-gdd6f7db19af1.

[   24.539789] i915 0000:00:02.0: [drm] GPU HANG: ecode 8:1:85dffff9, in Xorg [841]
[   24.539791] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[   24.539792] Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/intel/issues/new.
[   24.539792] Please see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details.
[   24.539792] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[   24.539793] The GPU crash dump is required to analyze GPU hangs, so please always attach it.
[   24.539793] GPU crash dump saved to /sys/class/drm/card0/error
[   24.641427] i915 0000:00:02.0: [drm] Resetting rcs0 for stopped heartbeat on rcs0
[   24.641437] i915 0000:00:02.0: [drm] Xorg[841] context reset due to GPU hang

dump-gpu-hang-x11 and with gnome-wayland

Last edited by CBiX (2020-05-20 12:31:53)

loqs · 2020-05-20 18:02:19

As drm-tip is producing the issue please consider reporting the bug upstream. How-to-file-i915-bugs.

Arch Linux

#1 2020-01-16 16:32:32

Faulty intel graphics

#2 2020-01-16 16:39:27

Re: Faulty intel graphics

#3 2020-01-16 19:00:56

Re: Faulty intel graphics

#4 2020-01-16 20:50:35

Re: Faulty intel graphics

#5 2020-01-17 00:06:32

Re: Faulty intel graphics

#6 2020-01-17 01:20:30

Re: Faulty intel graphics

#7 2020-01-17 04:22:33

Re: Faulty intel graphics

#8 2020-01-17 11:33:54

Re: Faulty intel graphics

#9 2020-01-17 11:47:11

Re: Faulty intel graphics

#10 2020-01-17 14:32:33

Re: Faulty intel graphics

#11 2020-05-18 15:25:05

Re: Faulty intel graphics

#12 2020-05-19 10:31:14

Re: Faulty intel graphics

#13 2020-05-19 14:11:27

Re: Faulty intel graphics

#14 2020-05-19 15:34:29

Re: Faulty intel graphics

#15 2020-05-19 16:32:59

Re: Faulty intel graphics

#16 2020-05-20 18:02:19

Re: Faulty intel graphics

Board footer