Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #94242 > unrolled thread

Bug#1142440: amdgpu Mullins: intermittent hibernation resume hang with page fault in drm_sched_job_arm

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1142440: amdgpu Mullins: intermittent hibernation resume hang with page fault in drm_sched_job_arm Bernard Kofi Osei <bernardkosei@gmail.com> - 2026-09-28 06:50 +0200
    Bug#1142440: amdgpu Mullins: intermittent hibernation resume hang with page fault in drm_sched_job_arm Uwe Kleine-König <ukleinek@debian.org> - 2026-10-14 11:00 +0200

#94242 — Bug#1142440: amdgpu Mullins: intermittent hibernation resume hang with page fault in drm_sched_job_arm

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

[toc] | [next] | [standalone]

#94466

[Multipart message — attachments visible in raw view] — view raw

On Mon, Sep 28, 2026 at 05:41:32AM +0100, Bernard Kofi Osei wrote:
> 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.

For upstream 6.12 is not very attractive. To convince them to act you'd
need to reproduce on something nearer to current mainline. The best
cost/effort ratio is probably reproducing using a kernel from
testing/unstable.

Best regards
Uwe

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web