[i915] Noise-like lines of graphics corruption when moving windows in Xorg sessions

That said, hmm, it took an hour or so after the backtrace for it to cause visual distortion or I misremember, or it gets worse over time.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1896091

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Attached dmesg from journalctl. To the best of my knowledge, this is all that's missing, as apport now has no raw dmesg access anymore and missed to upload the dmesg.

The corruption also happens in build 5.9.0-050900rc4drmintelnext20200915-generic but the error in dmesg does not, and it's less, it only happens on window management actions (switch window

Surprisingly with that, restarting gnome-shell actually fixes the issue (it did not with normal kernel).

Also adding a gnome-shell task. This happens on 5.8.0-21-generic from proposed too, and restarting gnome-shell stops the corruptions, so it's possible this is a gnome issue.

Blocks/lines around areas of the screen that are changing may just be bug 1898080.

... so if mutter 3.38.1 does not resolve the problem, I would be interested to see the corruption in action. Probably with a video.

Corrupt lines, red flashing across the top bar: https://photos.app.goo.gl/TgYxkVHRnsrV5wCR9

I use Xorg, and almost exclusively see it on my external monitor. After locking the screen and having it locked for a while. Saw it once on the internal one in a week, but like daily on external.

Thanks for the video. Corruption of that type is usually a kernel problem only. I can't imagine any way in which mutter can cause that one...

Please try some older/newer kernels.

Please test latest drm-tip kernel:
https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/

If the issue is not fixed upstream, please file an upstream bug at intel graphics:
https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs

Oh, drmtip exists too, I thought you said drmnext which was stuck on 09-18 (and I tested 09-15 which was more stable but not perfect). I'm currently just running the 5.9.1 mainline kernel for testing purposes, which so far (2 days in seems stable), but might just break later today, who knows.

I noticed the same bug in mutter 40, then tried to bisect it and found the same in mutter 3.36. So yeah this appears to be a new kernel (or Mesa) bug. It doesn't seem to happen much if at all if you run gnome-shell. Only in mutter for me.

It happened a lot more when docked (ext USB-C monitor) than on the laptop itself.

Kernel 5.9.1 seems good so far. I've not seen the issue yet and my uptime is 3 days 15 hours without any suspending in between, just screen locked.

I've got similar results. In fact I can't find any mainline kernel that exhibits corruption. Only the newer groovy kernels do:

good 5.8.0-16-generic
bad 5.8.0-23-generic
bad 5.8.0-25-generic

good 5.8.1-050801-generic
good 5.8.13-050813-generic
good 5.8.16-050816-generic

good 5.9.0-050900drmtip20201022-generic

Are there any i915 parameters we should try?

Still broken in 5.8.0-26-generic

I'm on 20.10 using KDE, 5.8.0-26-generic, on a dell xps 13 2-in-1 and the problem is rather severe.

The problem goes away after the screen times out and I have to log back in.

PSR is disable on Ubuntu. Please try kernel parameter "i915.enable_psr=1".

Verified the first broken version was 5.8.0-19-generic ...

good 5.8.0-16-generic
good 5.8.0-18-generic
bad  5.8.0-19-generic
bad  5.8.0-20-generic
bad  5.8.0-23-generic
bad  5.8.0-25-generic
bad  5.8.0-26-generic

good 5.8.1-050801-generic
good 5.8.13-050813-generic
good 5.8.16-050816-generic

good 5.9.0-050900drmtip20201022-generic

Here's a little 173 line diff where I think the regression might have occurred between 5.8.0-18-generic and 5.8.0-19-generic.

Enabling PSR does not fix it. The bug remains.

Four commits to test:
$ git log --pretty=oneline Ubuntu-5.8.0-18.19..Ubuntu-5.8.0-19.20 drivers/gpu/drm/i915
ae8bb7c11c7e5379394557469a777885e0644ce4 drm/i915/tgl+: Fix TBT DPLL fractional divider for 38.4MHz ref clock
6337b734a9d7ab1467538229716755b5ba40f8fa drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
a6a73a8b0b90cae710ab604ca973301a8e0ed851 drm/i915: Fix sha_text population code
10de2b0ee536988cb1a4dd605950b0f616611ac8 drm/i915: Fix cmd parser desc matching with masks

Can I assume "tgl+" means it's code I don't use on Kaby Lake?

Yea, so only two commits need to be tested.

Two days later... my bisection has failed. Also probably related -- in git the tag Ubuntu-5.8.0-18.19 has the bug, but not in the binary release. Perhaps I need to be more careful with the configs used instead of defaulting. Or maybe I will just start hacking around the aforementioned commits.

I think I might have got some incorrect results in comment #39. Because the bug still occurs when I build from git all the way back to Ubuntu-5.8.0-13.14. Also reverting the four commits in comment #42 does not fix it. The only thing that solves the bug is going to a mainline kernel/branch/tag.

I went back further in the history of i915 changes and found the offending commit:

https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/groovy/commit/?id=c1484c9939

If you revert c1484c9939 then the bug goes away.

Also verified Ubuntu-5.8.0-30.32 has the bug. And then reverting c1484c9939 fixes it.

Can we just revert c1484c9939, please? Even the commit message suggests it's not needed after v5.4.

Ok, let me send an SRU.

https://lists.ubuntu.com/archives/kernel-team/2020-November/114803.html

Awesome, thanks!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-groovy' to 'verification-done-groovy'. If the problem still exists, change the tag 'verification-needed-groovy' to 'verification-failed-groovy'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

I have installed "5.8.0-32-generic #34-Ubuntu" and will report if I experience the issue again. It sometimes takes a couple of days to manifest.

Been running for 1d 15h sofar and it seems to be fine

Been affected by this bug on Thinkpad T560 w/ i915 since mid September (2020). I have been using -proposed over the last few days. So far, it seems to have fixed the issue for me, the "interference lines" have not reoccurred since.

No re-occurrences of the issue since installing the new kernel on 12-02.

I think we've gotten enough (independent) verifications of this now to mark it as done.

Today I got an update to 5.8.0-33-generic (from 5.8.0-31-generic) but unfortunately the problem didn't solved.

That's correct. 33 was a hot fix release for a data loss in 31 that did not include the changes from 32. They'll come back in 34.

This bug reoccurred just now for the first time since I installed the patched kernel.

Am currently on

```
Linux floombort 5.8.0-34-generic #37-Ubuntu SMP Thu Dec 10 18:01:14 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
```

And Alt+F2 then 'r' fixed it again.

I can also confirm that on 5.8.0-34 I am getting this bug still as well. It *seems* to mostly start happening after resuming from suspend, but its too random to say for sure.

It's possible you see a different bug, I'd suggest opening a new bug report about it with ubuntu-bug so the kernel team actually has some data about the system rather than just small comments.

I think we can all agree that the patch (well removal of patch :)) made a vast improvement in terms of stability. It used to happen daily for me but doesn't anymore.

I have a similar issue with Core i3-9100 desktop (Ubuntu 20.10 clean install) and a HP Probook 430 G6 (Core i5-82xx).
Example:
https://aws1.discourse-cdn.com/standard17/uploads/ubuntubudgie/original/2X/1/1f3f03e248964bc470caf7748cf7d8aa424474fc.jpeg

Might be the same as:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1896627
because on the laptop, it mostly (but not only) happens when I use the touchpad or mouse and gets even worse when I scroll very slow.

This bug was fixed in the package linux - 5.8.0-34.37

---------------
linux (5.8.0-34.37) groovy; urgency=medium

  * groovy/linux: 5.8.0-34.37 -proposed tracker (LP: #1907576)

  * Packaging resync (LP: #1786013)
    - update dkms package versions

  * [Ubuntu 21.04 FEAT] mpt3sas: Request to include the patch set which supports
    topology where zoning is enabled in expander (LP: #1899802)
    - scsi: mpt3sas: Define hba_port structure
    - scsi: mpt3sas: Allocate memory for hba_port objects
    - scsi: mpt3sas: Rearrange _scsih_mark_responding_sas_device()
    - scsi: mpt3sas: Update hba_port's sas_address & phy_mask
    - scsi: mpt3sas: Get device objects using sas_address & portID
    - scsi: mpt3sas: Rename transport_del_phy_from_an_existing_port()
    - scsi: mpt3sas: Get sas_device objects using device's rphy
    - scsi: mpt3sas: Update hba_port objects after host reset
    - scsi: mpt3sas: Set valid PhysicalPort in SMPPassThrough
    - scsi: mpt3sas: Handling HBA vSES device
    - scsi: mpt3sas: Add bypass_dirty_port_flag parameter
    - scsi: mpt3sas: Handle vSES vphy object during HBA reset
    - scsi: mpt3sas: Add module parameter multipath_on_hba
    - scsi: mpt3sas: Bump driver version to 35.101.00.00

  * CVE-2020-12912
    - hwmon: (amd_energy) modify the visibility of the counters

  * Intel Tiger Lake IDs supplement (LP: #1904521)
    - mtd: spi-nor: intel-spi: Add support for Intel Tiger Lake-H SPI serial flash
    - pinctrl: tigerlake: Add support for Tiger Lake-H

  * [i915] Noise-like lines of graphics corruption when moving windows in Xorg
    sessions (LP: #1896091)
    - Revert "UBUNTU: SAUCE: drm/i915: Synchronize active and retire callbacks"

  * Fix no headset sound after S3 on Intel HDA (LP: #1904595)
    - ALSA: hda: Refactor codec PM to use direct-complete optimization
    - ALSA: hda: Separate runtime and system suspend
    - ALSA: hda: Reinstate runtime_allow() for all hda controllers

  * Ask 8821C Bluetooth controller to drop old firmware (LP: #1904221)
    - Bluetooth: btrtl: Ask 8821C to drop old firmware
    - Bluetooth: btrtl: fix incorrect skb allocation failure check

  * Use ACPI S5 for reboot (LP: #1904225)
    - PM: ACPI: reboot: Use S5 for reboot

  * Groovy update: v5.8.18 upstream stable release (LP: #1904941)
    - netfilter: nftables_offload: KASAN slab-out-of-bounds Read in
      nft_flow_rule_create
    - io_uring: don't run task work on an exiting task
    - io_uring: allow timeout/poll/files killing to take task into account
    - io_uring: move dropping of files into separate helper
    - io_uring: stash ctx task reference for SQPOLL
    - io_uring: unconditionally grab req->task
    - io_uring: return cancelation status from poll/timeout/files handlers
    - io_uring: enable task/files specific overflow flushing
    - io_uring: don't rely on weak ->files references
    - io_uring: reference ->nsproxy for file table commands
    - io_wq: Make io_wqe::lock a raw_spinlock_t
    - io-wq: fix use-after-free in io_wq_worker_running
    - io_uring: no need to call xa_destroy() on empty xarray
    - io_uring: Fix use of XArray in __io_uring_files_cancel
    - io_uring: Fix XArray usage in io_ur...

This bug was fixed in the package linux - 5.8.0-36.40+21.04.1

---------------
linux (5.8.0-36.40+21.04.1) hirsute; urgency=medium

  * Packaging resync (LP: #1786013)
    - update dkms package versions

  [ Ubuntu: 5.8.0-36.40 ]

  * debian/scripts/file-downloader does not handle positive failures correctly
    (LP: #1878897)
    - [Packaging] file-downloader not handling positive failures correctly

  [ Ubuntu: 5.8.0-35.39 ]

  * Packaging resync (LP: #1786013)
    - update dkms package versions
  * CVE-2021-1052 // CVE-2021-1053
    - [Packaging] NVIDIA -- Add the NVIDIA 460 driver

 -- Kleber Sacilotto de Souza <email address hidden> Thu, 07 Jan 2021 11:57:30 +0100

Issue started reoccurring with upgrade to 5.8.0.44, only after a screen lock, and ALT-F2 + 'r' fixes the problem until the next screen lock.