Dear Maintainer,

Debian 13 trixie, kernel 6.12.95+deb13-amd64.

Hardware:
AMD A8-6410 Mullins integrated Radeon R4/R5 graphics
PCI ID 1002:9851, subsystem 103c:2268.

This CIK GPU is deliberately using amdgpu rather than the default
radeon driver, with these kernel parameters:

radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dpm=1

Hibernation uses a 16 GiB NOCOW Btrfs swapfile inside the LUKS2
encrypted root filesystem. The swapfile is active, and its Btrfs
physical resume offset matches the resume_offset on the kernel
command line:

resume=/dev/mapper/sda8_crypt
resume_offset=8278889

The Dracut initramfs contains the resume module and
systemd-hibernate-resume.

One manually initiated hibernation and resume completed successfully,
restoring the full desktop session, including unsaved editor contents.

A subsequent hibernation resume failed intermittently. After entering
the LUKS passphrase, the restored desktop became visible, but the system
froze before the GNOME lock-screen password field appeared. Caps Lock
continued to respond, but the graphical session and Ctrl+Alt+F3 did not.
Several short presses of the power button had no effect, and a forced
power-off was required.

The previous-boot kernel journal showed this sequence after restoration:

amdgpu_ring_test_helper: ring comp_1.0.0 through comp_1.0.7 test
failed (-110)

amdgpu: SRBM_SOFT_RESET=0x00100040

[drm] scheduler comp_1.0.x is not ready, skipping

#PF: error_code(0x0000) - not-present page
RIP: drm_sched_job_arm+0x23/0x60 [gpu_sched]

The call trace included amdgpu_cs_ioctl, drm_ioctl_kernel,
drm_ioctl and amdgpu_drm_ioctl. The page fault occurred more than once.

The journal also contained:

pstore: backend (efi_pstore) writing error (-22)

There was no captured "Kernel panic - not syncing" line. However, a
kernel page fault/oops in the AMDGPU scheduler was recorded and the
machine became unusable.

The same amdgpu_irq_put warning in the DCE 8 suspend path is observed
during both suspend and hibernation:

WARNING at drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:631 amdgpu_irq_put
dce_v8_0_hw_fini
dce_v8_0_suspend
amdgpu_device_suspend

Ordinary suspend-to-RAM has resumed successfully multiple times,
including after an approximately 18.5-hour suspend. The fatal failure
has so far occurred during hibernation restoration.

I can provide the full previous-boot kernel journal and test an updated
Debian kernel if requested.

Hello,

I have now tested the immediately preceding Debian kernel on the same
machine:

    6.12.94+deb13-amd64

The hardware and configuration were 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 16 GiB Btrfs hibernation swapfile was active and the 6.12.94
initramfs contained the Dracut resume module.

Results with 6.12.94:

- graphical rendering was normal;
- an ordinary suspend/resume succeeded;
- two hibernation/resume cycles succeeded;
- the restored desktop remained usable;
- no page fault in drm_sched_job_arm was observed during these tests.

However, 6.12.94 still produced the same underlying AMDGPU recovery
errors seen with 6.12.95:

    WARNING at amdgpu_irq_put
    dce_v8_0_hw_fini
    dce_v8_0_suspend

    amdgpu_ring_test_helper:
    ring comp_1.0.0 through comp_1.0.3 test failed (-110)

    amdgpu: SRBM_SOFT_RESET=0x00100040

    [drm] scheduler comp_1.0.x is not ready, skipping

The scheduler-not-ready messages continued repeatedly after the
successful resume.

The observed difference so far is:

- 6.12.94: the AMDGPU compute-ring recovery failure occurred, but the
  system remained usable in the tests performed;
- 6.12.95: the same failure sequence was followed by repeated kernel
  page faults in drm_sched_job_arm and an unusable system requiring a
  forced power-off.

This suggests that the underlying AMDGPU hibernation/resume problem
predates 6.12.95, although 6.12.95 may be more likely to progress into
the fatal GPU scheduler fault.

I have attached the filtered 6.12.94 kernel journal from the successful
suspend and hibernation tests.

Regards,
Bernie Osei



<http://www.wisestamp.com/email-install?utm_source=extension&utm_medium=email&utm_campaign=footer>


*Disclaimer*
This message is intended only for the use of the person(s) ("Intended
Recipient") to whom it is addressed. It may contain information, which is
privileged and confidential. Accordingly any dissemination, distribution,
copying or other use of this message or any of its content by any person
other than the Intended Recipient may constitute a breach of civil or
criminal law and is strictly prohibited. If you are not the Intended
Recipient, please contact the sender as soon as possible.

Hello,

I'm confused, there are two mails in this bug log, senders differ, but
they are still the same person? If not, replying to the bug someone else
opened is only usefull if you're quite sure you see the exact same bug.

These bugs are hard for us (= Debian kernel team) to handle. It would be
best if you (two?) could retest with the latest 6.12 kernel from stable
and the latest kernel from testing/unstable. If the problem still
happens there, it't probably best to report that upstream.

This kind of trailer doesn't really make sense when sending a Debian bug
report that is publically archived.

Best regards
Uwe

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