video corruption with kernel 5.19.8, 5.19.9

dr.dynamics · 2022-09-16 23:42:24

Something in the 5.19.8 and newer kernel causes my laptop video to break. The screen image jumps left and right about 10% - 20% of the screen width every second or two at random. Happens even if I switch to a virtual terminal. Downgrade to 5.19.7 fixes the issue. Intel Pentium Silver N5030 built in video.

seth · 2022-09-17 05:16:27

psr or fbc?
https://wiki.archlinux.org/title/Intel_ … flickering
https://wiki.archlinux.org/title/Intel_ … nable_fbc)

(*disable* both)

dr.dynamics · 2022-09-17 18:19:02

Thanks for the suggestion, but can report that this does not fix the issue. Added: i915.enable_psr=0 i915.enable_fbc=0
to my kernel boot parameters in refind_linux.conf with no postive result. Actually, it is worse. It just made the screen fully black for the majority of the time. Had to blind pacman -U to downgrade to old kernel.

loqs · 2022-09-17 19:04:09

There are three bisection kernels for 5.19.7 to 5.19.8 linked from https://bugs.archlinux.org/task/75925#comment211221 if you are willing to test them.

dr.dynamics · 2022-09-18 03:57:24

Ok, thanks, I tried the second kernel, linux-5.19.8-1-x86_64.pkg.tar.zst I can confirm that it has the same problem as the standard Arch 5.19.8 and 5.19.9 - intermitent choppy video. Here's the weird thing - it's not every time. Sometimes I boot, and it's fine. Sometimes I boot, and it's not fine. I tried both cold and warm boots to see if I could detect a pattern but nothing obvious. It looks like if you get a start where it works, it stays working, but I didn't test it enough to be confident. It behaves kind of like something is starting before the hardware is ready? Just a wild guess.

Anyway, I also tried the third kernel, linux-5.19.7.r78.gbb4be611c2f5-1-x86_64.pkg.tar.zst and can confirm that it works fine. I'm not sure what makes it different than the standard Arch 5.19.7, but that works fine too.

Hope this helps.

loqs · 2022-09-18 04:57:28

git bisect good
Bisecting: 38 revisions left to test after this (roughly 5 steps)
[cce30bc7ae4823eba2dfbe0c964f16d9c330c93c] USB: serial: option: add Quectel EM060K modem

https://drive.google.com/file/d/1dkl_A4 … sp=sharing linux-5.19.7.r117.gcce30bc7ae48-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1Ka0p6Q … sp=sharing linux-headers-5.19.7.r117.gcce30bc7ae48-1-x86_64.pkg.tar.zst
Edit:
guessing the next one will also be good (please check both)

git bisect good
Bisecting: 19 revisions left to test after this (roughly 4 steps)
[c4c798fe98adceb642050819cb57cbc8f5c27870] dma-buf/dma-resv: check if the new fence is really later

https://drive.google.com/file/d/1Db_WVD … sp=sharing linux-5.19.7.r136.gc4c798fe98ad-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/12fy3V5 … sp=sharing linux-headers-5.19.7.r136.gc4c798fe98ad-1-x86_64.pkg.tar.zst

Last edited by loqs (2022-09-18 05:15:19)

dr.dynamics · 2022-09-18 13:27:01

Ok, I tried both of these, and I didn't experience any issues with either of them. I tried to reboot several times with both of them to see if anything intermittent appeared, but I think they're both ok.

loqs · 2022-09-18 14:41:45

git bisect good
Bisecting: 9 revisions left to test after this (roughly 3 steps)
[54b8252562e99e767ff6ab1db2bedc56e1b3eb54] ALSA: seq: oss: Fix data-race for max_midi_devs access

https://drive.google.com/file/d/149MfUw … sp=sharing linux-5.19.7.r146.g54b8252562e9-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1rBh83- … sp=sharing linux-headers-5.19.7.r146.g54b8252562e9-1-x86_64.pkg.tar.zst
Edit:
Guessing the last result was good

git bisect good
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[c6c5bdf735443df04ad2e416742e45002b064f81] drm/i915: Skip wm/ddb readout for disabled pipes

https://drive.google.com/file/d/1Zix18j … sp=sharing linux-5.19.7.r151.gc6c5bdf73544-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1MLV8aY … sp=sharing linux-headers-5.19.7.r151.gc6c5bdf73544-1-x86_64.pkg.tar.zst

Last edited by loqs (2022-09-18 14:56:54)

dr.dynamics · 2022-09-18 16:11:27

Ok, I tried both of these as well, and still no issues. I've rebooted a few times with each of them, and no problems. I'm a little afraid that I could miss something because like I said before, it seems like the issue does not appear with every boot, but so far so good.

loqs · 2022-09-18 16:24:53

If linux-5.19.7.r151.gc6c5bdf73544-1-x86_64.pkg.tar.zst is good everything left is changes to the tty subsystem which seems unlikely to be the cause.

dr.dynamics · 2022-09-18 16:59:32

Ok, the intermittent nature of the problem makes it difficult to detect, but you are correct and the problem has appeared in r151. It took many reboots, but it eventually showed up. I am backtracking to r146 and will try it for a few hours, and will update.

Edit: I've been using r146 for a while, and many reboots, still with no appearance of the problem. I would guess it's between r146 and r151.

Last edited by dr.dynamics (2022-09-18 18:33:11)

seth · 2022-09-18 19:16:19

That'd be reasonable because it covers the 4 i915 related commits.

https://github.com/gregkh/linux/commit/ … ee4d562eee # backlight!
https://github.com/gregkh/linux/commit/ … e4209258ca # but GUC should™ be irrelevnat for your HW
https://github.com/gregkh/linux/commit/ … dabc2a33fb # bad ID match for the quirk? But then it's also HDMI…
https://github.com/gregkh/linux/commit/ … 002b064f81 # weird heisenbug?

Since this doesn't happen on every boot it might also help to see journals for a good and a bad boot (on the same kernel)

Do you use https://wiki.archlinux.org/title/Kernel … _KMS_start ?

loqs · 2022-09-18 20:03:43

git bisect bad
Bisecting: 2 revisions left to test after this (roughly 1 step)
[4cde8745d15e6a807bc89f031f9286ee4d562eee] drm/i915/backlight: Disable pps power hook for aux based backlight

https://drive.google.com/file/d/1IMfzm8 … sp=sharing linux-5.19.7.r148.g4cde8745d15e-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1FpJVAQ … sp=sharing linux-headers-5.19.7.r148.g4cde8745d15e-1-x86_64.pkg.tar.zst

dr.dynamics · 2022-09-18 23:32:01

No issues detected with r148. I'm trying to be cautious - use it, then test many reboots, repeat. Not super confident, but I think I would have seen something by now. So r149 or r150?

loqs · 2022-09-19 00:14:38

git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[747a192e46746f0a80ad24ebabed19dabc2a33fb] drm/i915/glk: ECS Liva Q2 needs GLK HDMI port timing quirk

https://drive.google.com/file/d/1LTkFen … sp=sharing linux-5.19.7.r150.g747a192e4674-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/17-4FG1 … sp=sharing linux-headers-5.19.7.r150.g747a192e4674-1-x86_64.pkg.tar.zst

dr.dynamics · 2022-09-19 12:37:04

No issues to report with r150. Could it be whatever changed between r150 and r151? I will continue to use r150 for the time being in case I was too quick to judge.

seth · 2022-09-19 12:55:55

That'd be the heisenbug and easily revertible.

loqs · 2022-09-19 15:30:47

git bisect good
c6c5bdf735443df04ad2e416742e45002b064f81 is the first bad commit
commit c6c5bdf735443df04ad2e416742e45002b064f81
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Jun 17 22:59:48 2022 +0300

    drm/i915: Skip wm/ddb readout for disabled pipes
    
    commit 0211c2a0ea600e25db3044daaeff4fe41c3ed6d9 upstream.
    
    The stuff programmed into the wm/ddb registers of planes
    on disabled pipes doesn't matter. So during readout just
    leave our software state tracking for those zeroed.
    
    This should avoid us trying too hard to clean up after
    whatever mess the VBIOS/GOP left in there. The actual
    hardware state will get cleaned up if/when we enable
    the pipe anyway.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5711
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220617195948.24007-1-ville.syrjala@linux.intel.com
    Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
    (cherry picked from commit b183db8f4783ca2efc9b47734f15aad9477a108a)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 drivers/gpu/drm/i915/intel_pm.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [7d0a458e1963128ee5a85bf0584bea5e75149946] Linux 5.19.7
git bisect good 7d0a458e1963128ee5a85bf0584bea5e75149946
# bad: [70cb6afe0e2ff1b7854d840978b1849bffb3ed21] Linux 5.19.8
git bisect bad 70cb6afe0e2ff1b7854d840978b1849bffb3ed21
# good: [bb4be611c2f5f50386b609e8437754bd16bd88f8] mmc: core: Fix UHS-I SD 1.8V workaround branch
git bisect good bb4be611c2f5f50386b609e8437754bd16bd88f8
# good: [cce30bc7ae4823eba2dfbe0c964f16d9c330c93c] USB: serial: option: add Quectel EM060K modem
git bisect good cce30bc7ae4823eba2dfbe0c964f16d9c330c93c
# good: [c4c798fe98adceb642050819cb57cbc8f5c27870] dma-buf/dma-resv: check if the new fence is really later
git bisect good c4c798fe98adceb642050819cb57cbc8f5c27870
# good: [54b8252562e99e767ff6ab1db2bedc56e1b3eb54] ALSA: seq: oss: Fix data-race for max_midi_devs access
git bisect good 54b8252562e99e767ff6ab1db2bedc56e1b3eb54
# bad: [c6c5bdf735443df04ad2e416742e45002b064f81] drm/i915: Skip wm/ddb readout for disabled pipes
git bisect bad c6c5bdf735443df04ad2e416742e45002b064f81
# good: [4cde8745d15e6a807bc89f031f9286ee4d562eee] drm/i915/backlight: Disable pps power hook for aux based backlight
git bisect good 4cde8745d15e6a807bc89f031f9286ee4d562eee
# good: [747a192e46746f0a80ad24ebabed19dabc2a33fb] drm/i915/glk: ECS Liva Q2 needs GLK HDMI port timing quirk
git bisect good 747a192e46746f0a80ad24ebabed19dabc2a33fb
# first bad commit: [c6c5bdf735443df04ad2e416742e45002b064f81] drm/i915: Skip wm/ddb readout for disabled pipes

5.19.8 with c6c5bdf735443df04ad2e416742e45002b064f81 reverted
https://drive.google.com/file/d/1r58v_2 … sp=sharing linux-5.19.8-1.1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/10R5OIS … sp=sharing linux-headers-5.19.8-1.1-x86_64.pkg.tar.zst

dr.dynamics · 2022-09-19 19:29:39

Using this kernel 5.19.8 with c6c5bdf735443df04ad2e416742e45002b064f81 reverted.
No problems to report yet.
Still bothered by how I missed the problem in r151 at first, so grain of salt here, but it looks like the problem has been identified.
Will be sure to report back if I see any issue.

dr.dynamics · 2022-09-22 19:59:45

Just came back to follow up - no issues so far with c6c5bdf735443df04ad2e416742e45002b064f81 reverted. Should I file bug report for this on bugzilla or is this a known problem?

loqs · 2022-09-22 20:17:38

Please report the issue upstream to the i915 developers. See How-to-file-i915-bugs.

rantanran · 2022-09-27 22:01:20

Just here to report that I ran into this as well:
https://bbs.archlinux.org/viewtopic.php … 8#p2059478

Starting with this kernel 5.19.8-arch1-1 I can see the flicker with every boot.

Using 5.19.7-arch1-1 and prior is okay for me.

dr.dynamics · 2022-11-10 18:06:22

Just here to update on this. Bug is still present in series 6 kernels, including kernel 6.0.7, but I have just noticed something else. The issue only appears if I boot from cold with the laptop plugged in. If I am on battery, the issue does not appear, and I can even plug in after booting with no problem. It's something about the booting while charging that initiates this issue.

seth · 2022-11-11 07:39:41

https://bbs.archlinux.org/viewtopic.php … 3#p2058593
Did you?

Arch Linux

#1 2022-09-16 23:42:24

video corruption with kernel 5.19.8, 5.19.9

#2 2022-09-17 05:16:27

Re: video corruption with kernel 5.19.8, 5.19.9

#3 2022-09-17 18:19:02

Re: video corruption with kernel 5.19.8, 5.19.9

#4 2022-09-17 19:04:09

Re: video corruption with kernel 5.19.8, 5.19.9

#5 2022-09-18 03:57:24

Re: video corruption with kernel 5.19.8, 5.19.9

#6 2022-09-18 04:57:28

Re: video corruption with kernel 5.19.8, 5.19.9

#7 2022-09-18 13:27:01

Re: video corruption with kernel 5.19.8, 5.19.9

#8 2022-09-18 14:41:45

Re: video corruption with kernel 5.19.8, 5.19.9

#9 2022-09-18 16:11:27

Re: video corruption with kernel 5.19.8, 5.19.9

#10 2022-09-18 16:24:53

Re: video corruption with kernel 5.19.8, 5.19.9

#11 2022-09-18 16:59:32

Re: video corruption with kernel 5.19.8, 5.19.9

#12 2022-09-18 19:16:19

Re: video corruption with kernel 5.19.8, 5.19.9

#13 2022-09-18 20:03:43

Re: video corruption with kernel 5.19.8, 5.19.9

#14 2022-09-18 23:32:01

Re: video corruption with kernel 5.19.8, 5.19.9

#15 2022-09-19 00:14:38

Re: video corruption with kernel 5.19.8, 5.19.9

#16 2022-09-19 12:37:04

Re: video corruption with kernel 5.19.8, 5.19.9

#17 2022-09-19 12:55:55

Re: video corruption with kernel 5.19.8, 5.19.9

#18 2022-09-19 15:30:47

Re: video corruption with kernel 5.19.8, 5.19.9

#19 2022-09-19 19:29:39

Re: video corruption with kernel 5.19.8, 5.19.9

#20 2022-09-22 19:59:45

Re: video corruption with kernel 5.19.8, 5.19.9

#21 2022-09-22 20:17:38

Re: video corruption with kernel 5.19.8, 5.19.9

#22 2022-09-27 22:01:20

Re: video corruption with kernel 5.19.8, 5.19.9

#23 2022-11-10 18:06:22

Re: video corruption with kernel 5.19.8, 5.19.9

#24 2022-11-11 07:39:41

Re: video corruption with kernel 5.19.8, 5.19.9

Board footer