[ccing Alex and the regressions list] Hi, this is your Linux kernel regression tracker. On 12.01.23 22:03, Rainer Fiebig wrote: > Hi! Since kernel 6.0.18 Note, 6.0.y is now EOL, you should move to 6.1.y. > resume from hibernate fails, the system hangs > and a hard reset is necessary. The CPU is a Ryzen 5600G, the system is > Linux From Scratch-11.1. FWIW, there is a report with a problems that looks somewhat similar here: https://bugzilla.kernel.org/show_bug.cgi?id=216917 But the reporter doesn't care anymore, as 6.1 works. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. > I found this in the system log: > > [...] > Jan 12 19:30:03 LUX kernel: [ 50.248036] amdgpu 0000:30:00.0: [drm] > *ERROR* [CRTC:67:crtc-0] flip_done timed out > Jan 12 19:30:03 LUX kernel: [ 50.248040] amdgpu 0000:30:00.0: [drm] > *ERROR* [CRTC:70:crtc-1] flip_done timed out > Jan 12 19:30:14 LUX kernel: [ 60.488034] amdgpu 0000:30:00.0: [drm] > *ERROR* flip_done timed out > Jan 12 19:30:14 LUX kernel: [ 60.488040] amdgpu 0000:30:00.0: [drm] > *ERROR* [CRTC:67:crtc-0] commit wait timed out > ^@^@^@^@^@^@^@^@^@^[...]@^@^@^@^@^@^@^@^@^@^@^@^@^@Jan 12 19:31:20 LUX > syslogd 1.5.1: restart. > [...] > > > Bisecting the problem turned up this: > > ~/Downloads/linux-stable-BLFS-11.1> git bisect bad > 306df163069e78160e7a534b892c5cd6fefdd537 is the first bad commit > commit 306df163069e78160e7a534b892c5cd6fefdd537 > Author: Alex Deucher <alexander.deucher@xxxxxxx> > Date: Wed Dec 7 11:08:53 2022 -0500 > > drm/amdgpu: make display pinning more flexible (v2) > > commit 81d0bcf9900932633d270d5bc4a54ff599c6ebdb upstream. > > Only apply the static threshold for Stoney and Carrizo. > This hardware has certain requirements that don't allow > mixing of GTT and VRAM. Newer asics do not have these > requirements so we should be able to be more flexible > with where buffers end up. > [...] > > > Let me know if you need more info. Thanks. > > Rainer Fiebig
