Kernel 5.12.1 - 5.13rc3 graphics spasms(?)

JustSomeGeek · 2021-05-27 11:02:30

Firstly, I full expect to get chewed out for not adhering to bug reporting / Arch protocols. It's a *lot* to try and understand as an aging n00b.

https://bugs.archlinux.org/task/70724

This appears to be my issue, and is still valid, and *not* been fixed, at least not on my system. I have requested a re-open.

I believe i have tried most, if not all 5.12.xx linux and or linux-zen kernels as well as 5.13rc3. All with the same bug.

Booting a Garuda Live system with a 5.12.xx kernel using open source, or proprietary drivers produces the same.

So, on my laptop at least, I am stuck on 5.11.16 unless this can be resolved.

As a, now dedicated, Linux user, I am perfectly willing to tinker with, and break, my own system to learn, and fix things. But if a new user were to try out a distro with a kernel that does this, they may either try another distro, or abandon any attempts to try Linux at all. So I really feel this needs to be addressed.

The guidelines on kernel.org state that unless I compile the kernel myself, then I should turn to the Distro for support (in this case Garuda), which I have done, and they cannot help.

The Arch Linux Code of Conduct states:

"Arch Linux distribution support ONLY
Arch-based distributions have their own support fora and users of those distributions should be
actively encouraged to seek support there. These distributions often use different packages,
package versions, repositories, or make custom system configurations silently, practically
rendering support for such projects within Arch Linux impossible. Community technical support shall
only be provided for the Arch Linux distribution and the Arch User Repository. Posting issues with,
and requesting support for, derivative distributions or operating systems other than Arch Linux are
prohibited."

So what am I supposed to do *officially*? Being a Linux user, especially a new(ish) one, is a lonely life at the best of times, unless you stay within the ecosystem of the "cuddlier" distros like Ubuntu, Mint etc. It's way harder trying to adhere to "protocol" than it is to understand, and fix, the problems themselves. As a geek, I'm already socially awkward and nervous, with a fear of offending people, and drawing attention to myself. I imagine there are many more people like this out there.

So. Where do I go to get involved in diagnosing, and fixing this issue? Not just for me, but for anyone else that will get this problem once they switch from the last LTS kernel.

MSI GE72VR 6RF Intel/NVidia Optimus Laptop

edid-decode "/sys/class/drm/card0-eDP-1/edid":

EDID (hex):
00ffffffffffff0030e4690400000000
00180104952615780a0bb5a35955a027
0c505400000001010101010101010101
010101010101e835809670381f403020
35007ed71000001a0000000000000000
00000000000000000000000000fe004c
4720446973706c61790a2020000000fe
004c503137335746342d535046310022

Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: ...
version: 01 04
basic params: 95 26 15 78 0a
chroma info: 0b b5 a3 59 55 a0 27 0c 50 54
established: 00 00 00
standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1: e8 35 80 96 70 38 1f 40 30 20 35 00 7e d7 10 00 00 1a
descriptor 2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 3: 00 00 00 fe 00 4c 47 20 44 69 73 70 6c 61 79 0a 20 20
descriptor 4: 00 00 00 fe 00 4c 50 31 37 33 57 46 34 2d 53 50 46 31
extensions: 00
checksum: 22

EDID version: 1.4
Manufacturer: LGD Model 469 Serial Number ...
Made in year 2014
Digital display
6 bits per primary color channel
DisplayPort interface
Maximum image size: 38 cm x 21 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing includes the native pixel format and preferred refresh rate
Display x,y Chromaticity:
Red: 0.6367, 0.3476
Green: 0.3339, 0.6279
Blue: 0.1542, 0.0498
White: 0.3134, 0.3291
Established timings supported:
Standard timings supported:
Detailed mode: Clock 138.000 MHz, 382 mm x 215 mm
1920 1968 2000 2070 hborder 0
1080 1083 1088 1111 vborder 0
+hsync -vsync
VertFreq: 60 Hz, HorFreq: 66666 Hz
Manufacturer-specified data, tag 0
ASCII string: LG Display
ASCII string: LP173WF4-SPF1
Checksum: 0x22 (valid)
EDID block does NOT conform to EDID 1.4!
Missing name descriptor
Missing monitor ranges

seth · 2021-05-27 12:56:03

Protocolwise, please wrap shell IO and file contents in code tags when posting them, https://bbs.archlinux.org/help.php#bbcode
Also, protocolwise, garuda is not archlinux, https://bbs.archlinux.org/misc.php?action=rules - so be prepared for a mod to close this.

Bugwise, similar symptoms do not verify the same bug.
Eg. there's linked down https://gitlab.freedesktop.org/drm/intel/-/issues/3452 and mutiple sources (some extremely qualified) have verified the resolution of the one you found.

To diagnose this, one would require far less personal jabber or quotations of the CoC parts you intentionally violate, but
* a system journal (for kernel errors)
* stuff you've tried (i915.enable_psr=0 seems relevant) and
* the context (is only a display server affected? If so, which? Or does it happen on the console as well?) and
* the setup (how do you configure the optimus setup? is there also an external output? is the output maybe fed by the nvidia chip? …)
* etcetc.

scurrvy2020 · 2021-05-28 23:33:42

I had this issue with graphical artifacts in opengl. https://gitlab.freedesktop.org/drm/inte … ote_895128

It was just recently fixed in 5.12.6, 5.10.40, and 5.13.rc3.

It's not clear which GPU you are using, but I think this bug only affected skylake era iGPUs.

JustSomeGeek · 2021-06-11 10:08:15

Apologies for the absence. Not been online much.

This problem exists when booting straight from the archlinux-2021.06.01-x86_64.iso (kernel 5.12.8-arch1-1)

Machine is an MSI GE72VR (i7-6700HQ, HD Graphics 530 + NV GTX1060)

So yes, Skylake. And the issue seems to be *not* fixed, at least in this case.

nomodeset gives me a stable display.

Last edited by JustSomeGeek (2021-06-11 11:26:18)

JustSomeGeek · 2021-08-20 17:41:24

I am now running pure Arch, and still have the same issue, whether booting from the Arch ISO, or my install.

On 5.13.13-zen1-1-zen currently.

As stated, using nomodeset gives a stable display, but I cannot load Plasma Wayland because "kwin_wayland_drm: No suitable DRM devices have been found" So, I am stuck using terminal only.

loqs · 2021-08-20 18:31:25

You can post the journal seth requested from the console, see the first link in seth's signature and also Systemd/Journal#Filtering_output.
Please post the system journal for one boot without nomodeset. Have you tested linux 5.14-rc6 or linux drm-tip to see if the issue is already fixed upstream? Have you opened an upstream bug report?

Last edited by loqs (2021-08-20 19:01:57)

Arch Linux

#1 2021-05-27 11:02:30

Kernel 5.12.1 - 5.13rc3 graphics spasms(?)

#2 2021-05-27 12:56:03

Re: Kernel 5.12.1 - 5.13rc3 graphics spasms(?)

#3 2021-05-28 23:33:42

Re: Kernel 5.12.1 - 5.13rc3 graphics spasms(?)

#4 2021-06-11 10:08:15

Re: Kernel 5.12.1 - 5.13rc3 graphics spasms(?)

#5 2021-08-20 17:41:24

Re: Kernel 5.12.1 - 5.13rc3 graphics spasms(?)

#6 2021-08-20 18:31:25

Re: Kernel 5.12.1 - 5.13rc3 graphics spasms(?)

Board footer