Created attachment 132656 [details] Screenshot of the virtual console with artifacts Recently I received new PC and after Linux installation I noticed artifacts on virtual terminal's screen. Screenshot from virtual console is in the attachment. The sequence to achieve the artifacts is as follow: 1. Start Linux in text mode (virtual terminal, not X11 GUI) 2. Everything in virtual terminals is ok 3. Run X11 (xorg) 4. Switch back to virtual terminals 5. Now the artifacts appear on every virtual terminal The artifacts appear only after switching from xorg to virtual terminals. I use i7-6700 processor on recently updated Arch Linux. Xorg-server: 1.19.3-2 Kernel 4.12.0 compiled by myself. Output from "fbset -i": mode "1920x1080" geometry 1920 1080 1920 1080 32 timings 0 0 0 0 0 0 0 accel true rgba 8/16,8/8,8/0,0/0 endmode Frame buffer device information: Name : inteldrmfb Address : 0xd0040000 Size : 8294400 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 1 YPanStep : 1 YWrapStep : 0 LineLength : 7680 Accelerator : No
I noticed that it appear only on multi-head configuration. Seems like randr is somehow involved in this issue. I switched monitors (left and right) and after I reconfigured X-window environment with xrandr the problem occured again on the right monitor. So the issue concerns right monitor after reconfiguring with randr.
For testing purposes I recompiled older kernel 4.8.0 and there is no such artifacts - everything is working fine. Additionally I have tested the newest kernel 4.13-rc2 - and here still the issue occurs. So it seems like there is some kind of regression in kernel sources.
Ok, I did bisect on kernel and here below is what I found out. [root@localhost linux-git]# git bisect bad e62929b3f628f4dd023b95bdf63d486d877b8e1e is the first bad commit commit e62929b3f628f4dd023b95bdf63d486d877b8e1e Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Nov 8 13:55:33 2016 +0100 drm/i915/gen9+: Program watermarks as a separate step during evasion, v3. The watermark updates for SKL style watermarks are no longer done in the plane callbacks, but are now called in a separate watermark update function that's called during the same vblank evasion, before the plane updates. This also gets rid of the global skl_results, which was required for keeping track of the current atomic commit. Changes since v1: - Move line unwrap to correct patch. (Lyude) - Make sure we don't regress ILK watermarks. (Matt) - Rephrase commit message. (Matt) Changes since v2: - Fix disable watermark check to use the correct way to determine single step watermark support. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lyude <cpaul@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-3-git-send-email-maarten.lankhorst@linux.intel.com [mlankhorst: Small whitespace fix in skl_initial_wm] :040000 040000 4abc0f4fff120402078594f21598019c8d342bbc 4dd296dd5a107668be34da73722d370438638a0a M drivers [root@localhost linux-git]# git bisect log git bisect start '--' 'drivers/gpu/drm/i915' # bad: [650fc870a2ef35b83397eebd35b8c8df211bff78] Merge tag 'docs-4.13' of git://git.lwn.net/linux git bisect bad 650fc870a2ef35b83397eebd35b8c8df211bff78 # good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8 git bisect good c8d2bc9bc39ebea8437fd974fdbc21847bb897a3 # bad: [a318b4c4ea9aa9ad6279286f7989ce4a75d5fd76] drm/i915: Intel panel downclock cleanup git bisect bad a318b4c4ea9aa9ad6279286f7989ce4a75d5fd76 # good: [c0c8b9ed1b0c14d91ff73624df6d918bb47c8a5e] Merge tag 'drm-for-v4.9' into drm-intel-next-queued git bisect good c0c8b9ed1b0c14d91ff73624df6d918bb47c8a5e # good: [bae781b259269590109e8a4a8227331362b88212] drm: Nuke modifier[1-3] git bisect good bae781b259269590109e8a4a8227331362b88212 # bad: [793b61ea9f9972be0836a9a15d0d6a520daaf124] drm/i915: i915_gem_alloc_context_obj can be static git bisect bad 793b61ea9f9972be0836a9a15d0d6a520daaf124 # bad: [3975797f3e72bd115c6ba80210c5fe65ebd9e14e] Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued git bisect bad 3975797f3e72bd115c6ba80210c5fe65ebd9e14e # good: [2b3c83176e908401f31e26a4c0ba71f6248b11c1] drm/i915: Stop skipping the final clflush back to system pages git bisect good 2b3c83176e908401f31e26a4c0ba71f6248b11c1 # good: [bb89485e999181a329cafa8e798b6bbf10c1a52a] drm/i915: Create distinct lockclasses for execution vs user timelines git bisect good bb89485e999181a329cafa8e798b6bbf10c1a52a # good: [ccf010fb943a649a3ca74bb5cd489a642afaa7ae] drm/i915: Add an atomic evasion step to watermark programming, v4. git bisect good ccf010fb943a649a3ca74bb5cd489a642afaa7ae # bad: [27745e829a5cb896249f355f5bdab3249c5455e2] drm/i915/execlists: Use a local lock for dfs_link access git bisect bad 27745e829a5cb896249f355f5bdab3249c5455e2 # bad: [512b552798bfa3c4e665c34b9618d05c71b753ad] drm/i915/gen9+: Preserve old allocation from crtc_state. git bisect bad 512b552798bfa3c4e665c34b9618d05c71b753ad # bad: [e62929b3f628f4dd023b95bdf63d486d877b8e1e] drm/i915/gen9+: Program watermarks as a separate step during evasion, v3. git bisect bad e62929b3f628f4dd023b95bdf63d486d877b8e1e # first bad commit: [e62929b3f628f4dd023b95bdf63d486d877b8e1e] drm/i915/gen9+: Program watermarks as a separate step during evasion, v3. I hope those information will be more helpful.
Is there anything in dmesg?
Created attachment 133065 [details] dmesg from 4.9.0-rc2 with artifacts This is the dmesg from first bad commit on 4.9.0-rc2 with artifacts.
Created attachment 133066 [details] dmesg from 4.13.0-rc2 with artifacts
I attached 2 dmesg files from 2 bad kernels (with artifacts on screen): - 4.9.0-rc2 - 4.13.0-rc2 I see nothing wrong in any of those dmesg apart from warning in 4.9.0-rc2.
I forgot to write that those artifacts are quite different on both bad kernels. On 4.9.0-rc2 it looks like one line with artifacts, but on 4.13 it looks like multiple line artifacts - as it can be seen on attached screenshot. So in other words - there are two artifacts. First one appeared in e62929b3f628f4dd023b95bdf63d486d877b8e1e and it was only one-line artifact (unfortunately no screenshot attached). Then somewhere between 4.9.0-rc2 and 4.13.0-rc2 another one (multi-line) artifacts appeared (in attached screenshot).
Any progress? I've tested newest kernel 4.15.0 and the problem still occurs. And it is even worse - because the artifacts appears on both screens.
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.