Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
amdgpu - regression - bisected - Framework 16 laptop on kernel 6.9.0 results in screen flickering
As mentioned in the thread, the second bisection makes more sense for this issue. The issue is with Freesync Panel Replay on a static screen, which is a new feature to kernel 6.9.
This issue can be worked around for now on Framework 16 by amdgpu.dcdebugmask=0x400 which disables Freesync panel replay.
IMO, this issue should be resolved before the stable release of kernel 6.9.
I believe the workaround is not a proper solution, since more Framework 16 laptops might stop functioning upon kernel upgrade to 6.9.
Ideally it should be properly fixed, but it is late in the release cycle, so little time remains. At least the screen flickering should be prevented, i.e. by disabling the feature (for now) or reverting one or more commits.
Here's one option to try for now. This turns off panel replay on Phoenix:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.cindex a5dc0081d4b6..7f3eb2aa5562 100644--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c@@ -4569,7 +4569,6 @@ static int amdgpu_dm_initialize_drm_device(struct amdgpu_device *adev) /* Determine whether to enable Replay support by default. */ if (!(amdgpu_dc_debug_mask & DC_DISABLE_REPLAY)) { switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) {- case IP_VERSION(3, 1, 4): case IP_VERSION(3, 1, 5): case IP_VERSION(3, 1, 6): case IP_VERSION(3, 2, 0):
Maybe we can do that until it's fixed properly.
Or alternatively we might be able to flag the individual panel to not do replay for now, but I'm not sure how many panels are around on Framework 16. Can you share your EDID? Let's see.
I'd prefer if we're going to be doing quirks that we quirk the panel from replay instead of removing replay entirely from Phoenix.
Your patch did not apply cleanly to kernel 6.9-rc5.
I have patched rc5 manually by removing the same line as your patch, see below for my patch.
The patch prevents the issue; there is no screen flickering.
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.cindex 6d2f60c61dec..ecf94bf371ae 100644--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c@@ -4536,7 +4536,6 @@ static int amdgpu_dm_initialize_drm_device(struct amdgpu_device *adev) /* Determine whether to enable Replay support by default. */ if (!(amdgpu_dc_debug_mask & DC_DISABLE_REPLAY)) { switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) {- case IP_VERSION(3, 1, 4): case IP_VERSION(3, 1, 5): case IP_VERSION(3, 1, 6): case IP_VERSION(3, 2, 0):
Attempt #1 (closed) to retrieve EDID.
Is this correct?
arthur@pb450:~$ sudo get-edid | parse-edidThis is read-edid version 3.0.2. Prepare for some fun.Attempting to use i2c interfaceNo EDID on bus 0No EDID on bus 1No EDID on bus 2No EDID on bus 3No EDID on bus 4No EDID on bus 5No EDID on bus 6No EDID on bus 7No EDID on bus 8No EDID on bus 9No EDID on bus 10No EDID on bus 12No EDID on bus 13No EDID on bus 14No EDID on bus 15No EDID on bus 16No EDID on bus 17No EDID on bus 18No EDID on bus 19No EDID on bus 213 potential busses found: 11 20 22Will scan through until the first EDID is found.Pass a bus number as an option to this program to go only for that one.256-byte EDID successfully retrieved from i2c bus 11Looks like i2c was successful. Have a good day.Checksum CorrectSection "Monitor" Identifier "" ModelName "" VendorName "BOE" # Monitor Manufactured week 48 of 2022 # EDID version 1.4 # Digital Display DisplaySize 340 220 Gamma 2.20 Option "DPMS" "false" #Extension block found. Parsing...I only know about extension blocks of type 02h. PLEASE email me!Something strange happened. Please contact the author,Matthew Kern at <pyrophobicman@gmail.com>
I would use edid-decode instead of parse-edid as I expect it will be able to decode the rest of the blocks. I'm aware of F16 with this specific model panel (snippet of output from edid-decode)
Alphanumeric Data String: 'BOE CQ' Alphanumeric Data String: 'NE160QDM-NZ6'
In the EDID there is a DisplayID extension for it. This is what the driver looks for to decide to turn on replay. You can also use dynamic debugging and look for the message Panel supports Replay Mode
I don't think VRR is a correct label for this. As I understand it, it will be able to reproduce even with VRR turned off. It's any time that panel replay is enacted (static screen).
Just want to drop an update here on this issue. There is an internal fix, but it doesn't work in KDE after suspend/resume and another fix will be needed. So it will be a few patch series when this is ready.
Booting with Plymouth temporary disabled (kernel parameters: plymouth.enable=0 disablehooks=plymouth) makes the passphrase input visible and responsive.
The stack trace remains but this time there is an additional amdgpu error.
[ 27.076007] amdgpu 0000:c2:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)[ 27.076051] [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
I think it's worth double checking behavior on 6.11.2 with just the replay series added. This will help isolate if there is a different but related regression.
It should be the final patch that turned on panel replay that did it. As this is different than the original issue for this bug, let's track the regression in #3682 (closed) instead.
I agree that this seems to be a regression unrelated to screen flickering. However bug #3682 (closed) does not seem to be the same problem.
I'm not convinced yet they're different. It just might be another way to trip the same issue.
Would you mind to create a new bug report for the regression with panel replay and Plymouth?
Sure; go ahead and make a new issue. If they do end up being the same we can de-dupe. Also, please file a bug at Plymouth about this and mention the drm/amd issue in the Plymouth issue and the Plymouth issue in your new drm/amd issue.