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.
Engaging PSR on some panels with v6.1.0-rc2 causes graphics freeze
I built kernel v6.1.0-rc2 and booted this kernel on my Lenovo Thinkpad Z13 (Ryzen 7 Pro 6850U - Rembrandt).
With this kernel, the display does not get updated with cursor movement (meaning: when I move the mouse the display does not show cursor movement) and the machine freezes very soon after boot.
Hardware description:
CPU: Ryzen 7 Pro 6850U
GPU: 63:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev d1)
I'm afraid not, the laptop does not respond to Ctrl+Alt+F5 after this freeze, and the logs are lost after I long-press the power key. I don't have another machine at the moment so can't try to SSH into the laptop.
What you're looking for is the "s" option. Wait a little bit after it happens, and then try to use that to flush, then "u" to unmount, and "b" to reboot.
I don't know what your kernel has enabled, some of those features might not work (read more on that page about it to learn).
I noticed there was a new BIOS update "1.22-1.51" yesterday. I assume this means the firmware is still 1.22 but the EC is 1.51? Anyway, I tried it and this didn't solve the issue.
I happen to have a Z13 with a 6850U as well, but I don't reproduce this behavior on 6.1-rc2.
My first suspicion would be that this is a PSR issue with your panel.
Does your panel advertise PSR support? For me at an idle Ubuntu 22.04 Wayland desktop PSR engages at least momentarily:
Does disabling PSR help? On the kernel command line amdgpu.dcdebugmask=0x10.
If it does, can you please share your EDID from /sys/class/drm/card0-eDP-1/edid?
I did not do anything special with 5.19, it works without any kernel parameters. I did not check any other 6.x kernel so don't know when exactly it broke.
I did not do anything special with 5.19, it works without any kernel parameters. I did not check any other 6.x kernel so don't know when exactly it broke.
Based on that you've shared so far in this issue i'm suspecting that the kernel did not try to enable PSR on your panel previously but with some of the changes that happened between 5.19 and 6.1 the kernel tries to enable PSR but fails. It will be helpful to know more about your panel (edid).
By the way which version of the Z13 do you have? Do they use different full HD panels or do you have 4K version?
Mine has a panel with a native resolution of 2880x1800. The panel is made by SDC. here is my edid.
I did not check any other 6.x kernel so don't know when exactly it broke.
Would it be possible for you to please check if it happened with a 6.0 kernel too? Even better would be if you can bisect down to the specific commit that it starts to happen.
I can give it a shot, which version or tag should I use?
Between v6.0 and v6.1-rc2.
Not sure if I have time to do a proper bisect, I feel clumsy working with the kernel source and this seems to be a very tedious task.
Yeah it is a tedious effort, but it makes fixing things infinitely easier to know what/how it broke. If the panel I had reproduced it I would take care of it.
CC @mpearson. Does anything you have on hand reproduce this with 6.1-rc2 or later?
Hmm - that's a shame, it doesn't match my system which would have made doing a bisect easier. I'll double check if I can reproduce anyway.
Will check with the team if we have some with that specific panel
Mark
I just compiled v6.0.0 and this does not exhibit the same problem, PSR seems to be working fine on this version:
Well that's good to narrow down where the regression may be. We now know the following:
your panel did not support PSR in 5.19
your panel did support PSR in 6.0 (and it worked!)
your panel did support PSR in 6.1 but has a problem
If you can get it down to a specific commit that would be great. 6.1-rc introduced PSR SU, and lots of fixes for it.
Another thing that would be really useful to try is to grab the latest DMUB firmware (uploaded 9/13/22 to linux-firmware). When I tested I tested using DMUB 0x0400002A which is the latest uploaded to linux-firmware.git. You can find the version by looking at dmesg | grep DMUB. I haven't seen a full dmesg log of yours, so I don't know if you're using a different version. If it turns out that it works with the newer firmware our only action to solve this problem might be to gate this feature on a minimum version.
Here is the EDID for this display:
OK so you have panel from CSO, that has a native resolution of 1920x1200.
Hmm - that's a shame, it doesn't match my system which would have made doing a bisect easier. I'll double check if I can reproduce anyway. Will check with the team if we have some with that specific panel
To make tracking it down easier, here is the output from edid-decode < foo
Block 0, Base EDID: EDID Structure Version & Revision: 1.4 Vendor & Product Identification: Manufacturer: CSO Model: 4878 Made in: 2021 Basic Display Parameters & Features: Digital display Bits per primary color channel: 8 DisplayPort interface Maximum image size: 29 cm x 18 cm Gamma: 2.20 Supported color formats: RGB 4:4:4 First detailed timing includes the native pixel format and preferred refresh rate Display is continuous frequency Color Characteristics: Red : 0.6533, 0.3271 Green: 0.2939, 0.6123 Blue : 0.1376, 0.0615 White: 0.3271, 0.3476 Established Timings I & II: none Standard Timings: none Detailed Timing Descriptors: DTD 1: 1920x1200 60.002 Hz 8:5 75.062 kHz 156.130 MHz (286 mm x 179 mm) Hfront 48 Hsync 32 Hback 80 Hpol N Vfront 3 Vsync 6 Vback 42 Vpol N Display Range Limits: Monitor ranges (Bare Limits): 48-60 Hz V, 74-74 kHz H, max dotclock 150 MHz Alphanumeric Data String: 'CSOT T3' Alphanumeric Data String: 'MND307JA1-2'
@leoliu can you take a look at this issue? Regression from 6.0 to 6.1-rc1 with PSR support hanging some systems.
I am not noticing the mouse pointer issue on Lenovo Z13 with kernel 6.1-rc2.
The display panel resolution is 1920X1200
Attaching the details.debug-info.txt
Just reading over the issue and comments now, sorry in advance if I've missed something. A few things to try/get:
your panel did support PSR in 6.0 (and it worked!)
your panel did support PSR in 6.1 but has a problem
Can you try enabling visual confirm to see if cursor updates are actually doing PSR selective updates on v6.0 and v6.1? Add this to your kernel cmdline: amdgpu.visualconfirm=5.
If cursor updates are doing SU, you will see a green bar at the right edge of the panel updating with the cursor's vertical position. Otherwise, PSR SU is not being enabled.
Can you upload the full dmesg with drm.debug=0x16 enabled? It will be quite verbose, but it'll have PSR-related log entries that I'd like to see.
How likely is it that an AMD specific bisect can find the problem? eg. git bisect start -- drivers/gpu/drm/amd ? This says: Bisecting: 304 revisions left to test after this (roughly 8 steps) between 6.0 and 6.1-rc2 so I think this is not too bad and I can try bisecting.
Since we know it's a PSR issue; I think it's very likely that such a bisect catches it. If it's indeterminate, at least the log can be fed back into a bigger bisect though.
I am not fully convinced that the hamg/freeze and the cursor problem are the same issue. But let's keep this ticket about the cursor issue and I'll open a new one for the hang if that keeps happening.
Can you confirm if you revert that on top of latest 6.1-rc everything is OK then? There is a minor dependency that needs revert first (IE git revert f00844daa5212aac609d9cb97ce5e0a74c67890a b73353f7f3d434e90da9f0e127bba1fe26cb1287).
Yeah I'm not suggesting we're at the point the revert is the proper solution, just want to make sure you're not looking at two problems since you said the cursor behavior and hang might not be the same root cause.
just want to make sure you're not looking at two problems since you said the cursor behavior and hang might not be the same root cause
I just bisected the cursor issue. However I got 'random' hangs with other kernel versions too, hence I think it may not be the same problem, but I'll open a separate issue about that one if I still experience it after the cursor issue is fixed.
Mario Limonciellochanged title from Rembrandt laptop mouse cursor and freeze issues with v6.1.0-rc2 to Engaging PSR on some panels with v6.1.0-rc2 causes graphics freeze
changed title from Rembrandt laptop mouse cursor and freeze issues with v6.1.0-rc2 to Engaging PSR on some panels with v6.1.0-rc2 causes graphics freeze
On kernel v6.1-rc2 with the above cursor fix applied, I can trigger a hang by launching powertop in the terminal. I am unsure if this is related to the cursor problem or not but thought it may be useful to mention here.
Thus far, 3/3 times the laptop hanged instantly from powertop on this kernel. I'm looking at journalctl -k -b-1 but it seems there are no error messages at all in the log.
Just opening it? Or interacting with something?
As a thought; do you by chance have a USB4 or TBT3 dock connected? Does it only happen with that connected?
Ah... that was a weird enough result that I checked another bisect from rc2 to rc3.
It's actually fixed by 4b66ff46f2e1 ("perf: Fix missing raw data on tracepoint events").
My patch isn't necessary (or correct) for this.