Hello Uwe,
Thank you for the reply.
First, to clear up the sender confusion: Nana K Gyasi and Bernie Osei in
this bug log are one and the same person — me. I used two different mail
identities when sending the original report and the follow-up. I
apologise for the confusion this caused.
I have now completed the requested retest with the current Debian stable
6.12 kernel that was available to this machine when I began the test:
6.12.107+deb13-amd64
Debian 6.12.107-1
The hardware and relevant configuration are unchanged:
AMD A8-6410 Mullins Radeon R4/R5
PCI ID 1002:9851, subsystem 103c:2268
radeon.cik_support=0
amdgpu.cik_support=1
amdgpu.dpm=1
resume=/dev/mapper/sda8_crypt
resume_offset=8278889
The hibernation image remains on the 16 GiB Btrfs swapfile inside the
encrypted filesystem.
The result is that the problem is still reproducible on 6.12.107.
I first tested an ordinary suspend/resume. The machine remained usable,
but the kernel again logged the underlying AMDGPU recovery problem,
including:
WARNING at amdgpu_irq_put
amdgpu: SRBM_SOFT_RESET=0x00100040
I then performed a short hibernation/resume cycle. The hibernated
session restored successfully and remained usable, but the kernel again
logged compute-ring failures with -110, the soft reset, and repeated:
[drm] scheduler comp_1.0.x is not ready, skipping
This was consistent with my earlier observation that short hibernations
can appear to work despite the AMDGPU recovery errors.
I therefore repeated the test with an extended hibernation, since
historically that is when the serious failure has been most reproducible.
On the extended resume, the failure occurred again.
After the normal boot/initramfs path and LUKS unlock, the physical
display showed the previous desktop contents, including work which had
been left visible before hibernation. The graphical session was
otherwise unusable. I could not recover local control or switch to a
text VT with the function keys.
SSH was still working, so I was able to capture the system state before
rebooting.
The kernel journal from that failed resume contained:
amdgpu_irq_put 6 occurrences
SRBM_SOFT_RESET 3 occurrences
ring comp 13 occurrences
scheduler comp 668 occurrences
drm_sched_job_arm 2 matches
Oops: 1 occurrence
The significant failure is:
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:drm_sched_job_arm+0x23/0x60 [gpu_sched]
Immediately before this, the compute rings had failed again, including:
amdgpu_ring_test_helper:
ring comp_1.0.0 test failed (-110)
...
ring comp_1.0.7 test failed (-110)
followed by repeated scheduler-not-ready messages.
So the same fatal drm_sched_job_arm scheduler failure which I previously
reproduced on 6.12.95 is also reproducible on 6.12.107.
This changes my earlier interpretation of the 6.12.94/6.12.95
comparison. I no longer think the available evidence supports treating
6.12.95 as a likely regression boundary. The underlying fault was
already present on 6.12.94, and 6.12.107 can also progress into the
fatal scheduler Oops. Short successful hibernation cycles appear not to
be sufficient to show that the problem is absent.
There is also a display/locking symptom which may be worth recording
separately.
Immediately before the extended hibernation I observed the display
blank, then show the desktop again just before the machine actually
powered down.
After the failed resume, the old desktop contents remained visibly
displayed on the physical panel. However, from SSH:
loginctl show-session 3
reported:
Type=wayland
Active=yes
State=active
LockedHint=yes
Running:
loginctl lock-sessions
made no visible difference to the physical display.
I therefore had a state in which the session was reported as logically
locked, but stale pre-hibernation desktop contents — including
potentially private work — remained visible on the screen. I do not know
whether this has the same root cause as the AMDGPU scheduler failure, so
I am reporting it as an observed symptom rather than drawing that
conclusion.
I preserved the full kernel journal and additional failed-state
diagnostics before rebooting.
After reboot, the machine returned to normal operation on 6.12.107. The
encrypted root filesystem and Btrfs filesystem are healthy and there are
no failed systemd units.
I have not yet completed the requested test with the latest kernel from
Debian testing/unstable. I intend to do that next using an
isolated/reversible kernel installation while keeping the stable kernel
available for fallback.
If useful, I can attach the complete kernel journal from the failed
6.12.107 extended resume, along with the focused failure extract and
session-lock-state capture.
Please let me know if there is any additional tracing or diagnostic
information which would be particularly useful for the testing/unstable
run, or whether you would prefer that I open the upstream report now
based on this 6.12.107 reproduction.
Regards,
Bernie Osei
