Bug 2203549
| Summary: | Severe video glitches with kernel >= 6.2.13 on an Intel Alder Lake-UP3 GT2 [Iris Xe Graphics] video card | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Éric Brunet <eric.brunet> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 38 | CC: | acaringi, adscvr, airlied, alciregi, bskeggs, hdegoede, hpa, jarodwilson, jforbes, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, ptalbert, steved | ||||
| Target Milestone: | --- | Keywords: | Desktop, Regression | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2023-06-17 22:59:51 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 1964404 [details]
Small video of the screen showing the problem
I am attaching a small video, taken from a phone, of my computer screen, just after logging in an empty kde session.
While I move the mouse, the video glitch on the right appears and disappears several times.
It is possible to bisect stable, it is just a different tree upstream. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git and there is as separate branch per linus release, so linux-6.2.y corresponds with what is in 6.2 here. Out of curiosity though, does this happen with 6.3.2? https://koji.fedoraproject.org/koji/buildinfo?buildID=2199126 Thanks for your answer. Unfortunately, the problem is still present with 6.2.15 and 6.3.2 (using fedora's packages). I'll try to get the bisection working... Took me a good part of the morning, but I could bisect the problem: it is caused by commit e2b789bc3dc34edc87ffb85634967d24ed351acb, which is a one-liner (in full at the bottom of this message).
I checked that vanilla 6.3.2 had the bug, and that 6.3.2 with that commit reverted didn't.
I am now sending a message at stable.org
commit e2b789bc3dc34edc87ffb85634967d24ed351acb (HEAD)
Author: Ville Syrjälä <ville.syrjala.com>
Date: Wed Mar 29 20:24:33 2023 +0300
drm/i915: Fix fast wake AUX sync len
commit e1c71f8f918047ce822dc19b42ab1261ed259fd1 upstream.
Fast wake should use 8 SYNC pulses for the preamble
and 10-16 SYNC pulses for the precharge. Reduce our
fast wake SYNC count to match the maximum value.
We also use the maximum precharge length for normal
AUX transactions.
Cc: stable.org
Cc: Jouni Högander <jouni.hogander>
Signed-off-by: Ville Syrjälä <ville.syrjala.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329172434.18744-1-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander>
(cherry picked from commit 605f7c73133341d4b762cbd9a22174cc22d4c38b)
Signed-off-by: Jani Nikula <jani.nikula>
Signed-off-by: Greg Kroah-Hartman <gregkh>
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 664bebdecea7..d5fed2eb66d2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -166,7 +166,7 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp,
DP_AUX_CH_CTL_TIME_OUT_MAX |
DP_AUX_CH_CTL_RECEIVE_ERROR |
(send_bytes << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) |
- DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(32) |
+ DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(24) |
DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
if (intel_tc_port_in_tbt_alt_mode(dig_port))
I got several answers from the e-mail I sent to stable.org and the people involved in the problematic commit. Two things: - there is a work-around: the problem disappears when booting with "i915.psr_safest_params=1" (or with "i915.enable_psr=0") - I have opened a new issue on https://gitlab.freedesktop.org/drm/intel/-/issues/8480 As discussed on the drm/intel bug page, a fix has been written. The fix is present in kernel v6.3.8, which has just been shipped by fedora. With that new kernel, the video glitch is no longer present. I am closing this bug now. |
I have a HP Elite x360 1049 G9 2-in-1 notebook running fedora 38. It was working very well, but with recent updates I have a severe video glitch: sometimes, when the content of the screen changes, a large vertical band flashes on the right of the screen. The band occupies about 20% of the screen, and is made of random, changing pixels. I just need to move the mouse pointer a couple of seconds to see the band appears and disappears. Besides that, everything works fine. The bug appeared with the kernel 6.2.13, and is still present with 6.2.14. My computer works well with the 6.2.12 kernel with a fully uptodate fedora 38. The bug occurs both with Xorg and wayland. (I am using KDE, by the way). The video card is % sudo lspci -vk -s 00:02.0 00:02.0 VGA compatible controller: Intel Corporation Alder Lake-UP3 GT2 [Iris Xe Graphics] (rev 0c) (prog-if 00 [VGA controller]) DeviceName: Onboard IGD Subsystem: Hewlett-Packard Company Device 896d Flags: bus master, fast devsel, latency 0, IRQ 143 Memory at 603c000000 (64-bit, non-prefetchable) [size=16M] Memory at 4000000000 (64-bit, prefetchable) [size=256M] I/O ports at 3000 [size=64] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c <?> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [100] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [300] Page Request Interface (PRI) Capabilities: [320] Single Root I/O Virtualization (SR-IOV) Kernel driver in use: i915 Kernel modules: i915 Relevant kernel boot messages: (appart from timestamps, these lines are identical for 6.2.12 and 6.2.14) [ 2.790043] i915 0000:00:02.0: vgaarb: deactivate vga console [ 2.790089] i915 0000:00:02.0: [drm] Using Transparent Hugepages [ 2.790497] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 2.793812] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/adlp_dmc_ver2_16.bin (v2.16) [ 2.825058] i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1 [ 2.825061] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3 [ 2.842906] i915 0000:00:02.0: [drm] HuC authenticated [ 2.843778] i915 0000:00:02.0: [drm] GuC submission enabled [ 2.843779] i915 0000:00:02.0: [drm] GuC SLPC enabled [ 2.844200] i915 0000:00:02.0: [drm] GuC RC: enabled [ 2.845010] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized [ 3.964766] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 1 [ 3.968403] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 3.968981] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input18 [ 3.977892] fbcon: i915drmfb (fb0) is primary device [ 3.977899] fbcon: Deferring console take-over [ 3.977904] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device [ 4.026120] i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A So, has there been some changes to the i915 driver between 6.2.12 and 6.2.13 ? I toyed with the idea of git-bisecting the problem, but I don't know how to match the fedora versions 6.2.12 and 6.2.13 to commits in the official linux tree. I have the vague memory that there was a specific tool for bisecting fedora kernels, but I cannot find it, so I must have dreamt it. What relevant information could I provide? Reproducible: Always Steps to Reproduce: 1. Boot the computer with kernel 6.2.13 or 6.2.14 2. Move the mouse Actual Results: Visual glitch Expected Results: No visual glitch