Arch Linux

gdl

Member

Registered: 2015-04-18

Posts: 6

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

I'm seeing this issue on my RX 570; another Polaris card.

Possibly relevantly, I had to disable power management and the Display Core driver (by adding the kernel parameters `amdgpu.dpm=0` and `amdgpu.dc=0`) in order to prevent my RX 570 from losing its mind (heavily corrupted graphics), especially when waking from sleep. Is anyone else who's having this issue using `amdgpu` kernel parameters?

I've also been seeing an infrequent display flicker where what looks to be a terminal or console replaces the entire screen for a single frame. I need to do some more testing, but I'm starting to think that they occur at the same time as the log gets spammed with those `[drm] scheduler comp_X.Y.Z is not ready, skipping` messages.

I do not have display flicker on Arch but interestingly it happens on Windows 11. A bit OT but I noticed that on Windows 11, 90% of the time I resume from suspend I have to turn off and on (power cable) the monitor a few times to finally wake up the GPU.
At least on Arch, I am 100% sure the monitor will turn on and the scheduler comp messages.

DeKay

Member

Registered: 2008-11-15

Posts: 36

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

No improvements with 6.13.1-arch1-1

Magnesium

Member

Registered: 2016-11-08

Posts: 21

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

I have this problem a long time, even with 6.14.0-rc1-1-mainline and sway (wayland)

but have found a possible workaround here https://bbs.archlinux.org/viewtopic.php?id=302767

downgrading mesa an vulkan-radeon to 24.2.7-1
and installing llvm18-libs

***** update *****
3 days in a row, resuming from sleep and hibernation, without crash!

[ia@sun ~] % date                                                                                                                                                                                                                [0][16:11:00]
Thu Feb 13 04:11:20 PM -03 2025
[ia@sun ~] % uptime                                                                                                                                                                                                              [0][16:11:20]
16:11:22 up 3 days,  5:09,  1 user,  load average: 0.57, 0.92, 0.88

**** update ****
unfortunately, had a crash: kernel null pointer dereferece
new tactics: using latest mesa and vulkan-radeon, downgrading kernel to 5.19.13 - yes you read it correctly
status: no more log spam [drm] scheduler stuff
after resuming from suspend, no more amdgpu error ringtest stuff
lets see if the system will remain stable more than four days in row, with sucessive suspending/hibernating and resuming.

Last edited by Magnesium (2025-02-21 18:05:59)

altoid

Member

From: Germany

Registered: 2019-09-19

Posts: 13

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

This also happens to me after resume from suspend.

Kernel build script and config (6.14.2) available here on my GitHub.

Apr 15 02:28:00 Workstation kernel: sd 0:0:0:0: [sda] Starting disk
Apr 15 02:28:00 Workstation kernel: amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.1.1 test failed (-110)
Apr 15 02:28:00 Workstation kernel: random: crng reseeded on system resumption
Apr 15 03:28:51 Workstation kernel: [drm] scheduler comp_1.1.1 is not ready, skipping
Apr 15 03:28:51 Workstation kernel: [drm] scheduler comp_1.1.1 is not ready, skipping
Apr 15 03:28:51 Workstation kernel: [drm] scheduler comp_1.1.1 is not ready, skipping
Apr 15 03:28:51 Workstation kernel: [drm] scheduler comp_1.1.1 is not ready, skipping

CPU: Xeon E3-1231 v3
GPU: RX 480 with 4GB of VRAM

No visual glitches, it works just fine but the console spam is obviously suggesting that something is wrong.

Last edited by altoid (2025-04-15 01:36:38)

DeKay

Member

Registered: 2008-11-15

Posts: 36

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

Which kernel introduced the issue? Is the issue still present in 6.13?

sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.13-1-x86_64.pkg.tar.zst

Do you need help performing the bisection requested by upstream?

Someone has done a git bisect to find the problematic commit. Hope this leads to a fix soon.

altoid

Member

From: Germany

Registered: 2019-09-19

Posts: 13

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

Someone has done a git bisect to find the problematic commit. Hope this leads to a fix soon.

I can offer you / anyone to look into this today.

I was reverse engineering the Polaris firmware anyway, so I might as well recompile the kernel but undo that commit, then debug it and try to re-create that commit but without the side-effects we all are experiencing.

After all, I have to delete my latest commit, namely Linux 6.14.2, in my (Arch Build System) kernel repository anyway since I forgot to enable UDF filesystem drivers / CONFIG_UDF_FS in the kernel config.

I will try to get it to work when I have some free time!

Last edited by altoid (2025-04-15 07:46:50)

DeKay

Member

Registered: 2008-11-15

Posts: 36

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

I can offer you / anyone to look into this today.

That would be amazing!

altoid

Member

From: Germany

Registered: 2019-09-19

Posts: 13

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

@DeKay: I have to apologize, since holidays are coming up I now have a bunch of stuff to do.

I will try to get to it once I have the time.

Maybe the guys in the ticket(s) will get it first.

A -110 return value usually means timeout, so the card failed to resume some compute queues and an application tries to use them despite the driver not having them initialized fully.

The commit in question is related to retimer test pattern sequencing in the AMD Display Core (drm/amd/display).

I did take a manual look and some code stands out to me, although I am not very familiar with this code-base (AMDGPU) at all.

The commit that our friend landed on after bisecting is mostly related to DisplayPort and I don't really see (yet) how it could interfere.

I will try some stuff while I still have time.

DeKay

Member

Registered: 2008-11-15

Posts: 36

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

@altoid. No worries. But before you do anything, be sure to check back to the ticket first. There is some dispute on that bisect and a new theory as to what causes the problem.

altoid

Member

From: Germany

Registered: 2019-09-19

Posts: 13

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

@DeKay: Thank you for the heads up.

Yes, I had a strong feeling (from a developers viewpoint) that this commit is not at all related.

We will see soon

Last edited by altoid (2025-04-17 22:14:36)

itektur

Member

Registered: 2014-03-01

Posts: 23

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

Chiming in because I just found this thread which is awesome because I have the same issue since what feels like forever.

Some machine details:

Motherboard: X570-A PRO (MS-7C37)
CPU: AMD Ryzen 9 5900X 12-Core Processor
Video: Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]
uname: Linux hostname 6.14.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 10 Apr 2025 18:43:59 +0000 x86_64 GNU/Linux

I am using Xorg and Fluxbox without any compositing whatsoever (so no transparencies even if I or applications ask for it).

The most prominent symptom is the logspam that happens after the first suspend/resume (no surprises here):

Apr 21 14:04:50 hostname kernel: [drm] scheduler comp_1.2.0 is not ready, skipping
Apr 21 14:04:51 hostname kernel: [drm] scheduler comp_1.3.1 is not ready, skipping
Apr 21 14:04:51 hostname kernel: [drm] scheduler comp_1.2.0 is not ready, skipping
Apr 21 14:04:51 hostname kernel: [drm] scheduler comp_1.3.1 is not ready, skipping
Apr 21 14:04:51 hostname kernel: [drm] scheduler comp_1.2.0 is not ready, skipping
Apr 21 14:04:52 hostname kernel: [drm] scheduler comp_1.3.1 is not ready, skipping
Apr 21 14:04:52 hostname kernel: [drm] scheduler comp_1.2.0 is not ready, skipping
Apr 21 14:04:52 hostname kernel: [drm] scheduler comp_1.3.1 is not ready, skipping
Apr 21 14:04:52 hostname kernel: [drm] scheduler comp_1.2.0 is not ready, skipping
Apr 21 14:04:53 hostname kernel: [drm] scheduler comp_1.3.1 is not ready, skipping
Apr 21 14:04:53 hostname kernel: [drm] scheduler comp_1.2.0 is not ready, skipping

However, there are a few more things I would like to add that might or might not be related:

• I use only one display/monitor. I use guake (and tmux) for virtual terminals. If I turn guake into fullscreen, the logspam stops!

• However, even with guake at fullscreen the whole time, switching to another window of another application (which will then be displayed on top of guake) will add a few logspam lines again. The number of log lines seems to be number of different comp_* times the number of windows being "dirty" and then redrawn, at least most of the time. For example, in my case, There are comp_1.2.0 and comp_1.3.1, so the first number is 2. If I switch to another window (using keyboard shortcuts) such that it was hidden by guake and now is brought to the foreground, that other window needs to be redrawn, so the second number is 1. Thus, 2 * 1 = 2 new log lines. Switching back to guake such that the other window disappears means that guake is dirty so the second number will also be 1 in this case. Two lines. Switching focus such that 2 windows reappear on top of guake makes 4 lines and so on. Moving windows around with their contents being displayed during movement means lots of redraws because of windows being dirty/repositioned, thus, OMG many lines.

• If guake is at display but not fullscreen, I get my usual logspam back at kind of a fixed interval. On top of the log lines I get from moving windows or redisplaying them because of switching virtual desktops and so on, that is. Not sure what that regular interval correlates to (seems to be once every half-second).

The whole issue becomes apparent after the first suspend/resume cycle, but there are other symptoms that seem to worsen over time:

• After a month or two or three of suspending/resuming every day, mpv starts behaving strangely. That is, it seems to have a hard time starting video playback, as if the harddisk were broken or something. However, audio playback works fine throughout. Starting a new video takes almost a second! If it has become that bad, I basically know that the next suspend/resume cycle will result in a frozen system (or at least a frozen X) right after resume (or at least when the next logspam line should appear, can't quite remember). No screensaver, btw. Everything is being displayed and I can move the mouse cursor around but that's it. Not even Numlock will work (LED will not respond).

• Similarly, if it is not just mpv having issues, it might happen that, after a suspend/resume, every process I start from then on will freeze as soon as it asks too much of the video card. More specifically, geany, firefox and mpv, for example, are all listed in nvtop, and new processes of them will all freeze. The only thing I see of them is the window decoration, but no content whatsoever. New processes of programs that do not appear in nvtop will work just fine. Also, processes which already have opened all the windows they need also continue to work. (I cannot remember whether still-working nvtop-listed processes can open new windows without problems.) However, similar to the situation with mpv above, this is usually the last day anything works at all. If I suspend and then resume the next day, everything will be frozen and I need to make use of the reset button.

• By the way, guake is listed in nvtop as well.

I hope that helps solving the issue.

DeKay

Member

Registered: 2008-11-15

Posts: 36

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

Chiming in because I just found this thread which is awesome because I have the same issue since what feels like forever.

Some machine details:

Motherboard: X570-A PRO (MS-7C37)
CPU: AMD Ryzen 9 5900X 12-Core Processor
Video: Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]
uname: Linux hostname 6.14.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 10 Apr 2025 18:43:59 +0000 x86_64 GNU/Linux

<snip>

• I use only one display/monitor. I use guake (and tmux) for virtual terminals. If I turn guake into fullscreen, the logspam stops!

• However, even with guake at fullscreen the whole time, switching to another window of another application (which will then be displayed on top of guake) will add a few logspam lines again. The number of log lines seems to be number of different comp_* times the number of windows being "dirty" and then redrawn
  <snip>

The whole issue becomes apparent after the first suspend/resume cycle, but there are other symptoms that seem to worsen over time:

<snip>

I hope that helps solving the issue.

Awesome detective work  @itektur.  Could you add your findings to the bug I filed on the drm/amd Gitlab. I think this is starting to get developer interest now that recent findings have narrowed down the issue somewhat. Your findings will help.

kschendel

Member

Registered: 2025-04-21

Posts: 1

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

I get 4 of these every time I switch activities (essentially, desktops) in KDE Plasma.  5800X and RX550, running 6.12.16 x86_64.  Single monitor.  Every activity switch gets me 4 of those stupid warnings.

The KDE stuff is whatever was in OpenSUSE Tumbleweed as of the 2025-04-02 update.  If anyone needs more info and can tell me how to get it, I'm happy to oblige.

I hadn't been paying much attention to this;  however I now need to track down a separate issue and the logs are so full of this garbage that I can't get anywhere.  I'm going to simply remove the offending printk and recompile, but I thought I would report this first.

Last edited by kschendel (2025-04-22 06:23:45)

altoid

Member

From: Germany

Registered: 2019-09-19

Posts: 13

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

@itektur: Thank you a lot for actually contributing to the ticket!

I must say that I have not gotten very far - mostly, due to lack of time and patience.

The only thing I tried was compiling and running the latest mainline kernel that was available at the time - 6.15-rc2 - which you will not be able to compile unless you disable many, many different features (the landlock LSM being one of them) due to compiler errors.

It did have a whole bunch of drm/amdgpu related new commits in it, though nothing specific to this issue.. and after booting it, the problem persisted.

If you want to try for yourself, 6.15-rc3 just came out, and it should compile just fine if you replace your kernel config with my minimal one from my GitHub - make sure to disable landlock though!

Then, I dug further into the documentation of drm and amdgpu module related parameters.

Here are some interesting parameters for debugging, harvested from here and here.

[drm.debug]
| Bitflag | Meaning                             |
|---------|-------------------------------------|
| 0x1     | CORE (DRM core code)                |
| 0x2     | DRIVER (vendor‐specific driver code)|
| 0x4     | KMS (Kernel Mode Setting)           |
| 0x8     | PRIME (buffer‐sharing code)         |
| 0x10    | ATOMIC (atomic modesetting)         |
| 0x20    | VBL (vblank/event handling)         |
| 0x40    | STATE (atomic‐state debugging)      |
| 0x80    | LEASE (leasing code)                |
| 0x100   | DP (DisplayPort code)               |
| 0x200   | DRMRES (managed‐resources tracking) |
[amdgpu.debug]
| Bitflag | Meaning                                |
|---------|----------------------------------------|
| 0x1     | Debug VM handling                      |
| 0x2     | Simulate Large BAR                     |
| 0x4     | Disable GPU soft recovery              |
| 0x8     | Use VRAM for firmware buffer           |
| 0x10    | Enable RAS ACA logging                 |
| 0x20    | Enable experimental reset paths        |
| 0x40    | Disable GPU ring reset                 |
| 0x80    | Use VRAM for SMU debug memory pool     |

Of particular interest to me are the

amdgpu.debug = 0x4 | 0x20 | 0x80

bit flags, but the full DRM debug output would be nice to see as well.

Later, I will play around with the options from the two tables above, as well as with power management related driver options such as:

amdgpu.aspm
amdgpu.runpm

I also finally got to the AMDGPU soft-recovery code for ring failures and have some ideas to try out on my mind!

Should I stumble upon something interesting, I will edit this post (or, post a new reply altogether).

Thank you to everyone that posted in the ticket, and if you did, you should probably enable some verbose debug messages!

Consult the tables and the two links I posted for more information, until I have some time (and patience) to test my theories.

P.S: It should be obvious, but you can get around this bug if you suspend your machine without any hardware acceleration features currently being used / activated by applications (VA-API, Vulkan, et cetera).

Of course that is not a fix, but for machines with high-uptime requirements it is a temporary workaround.

Edit:

I noticed that

amdgpu.debug

is not exposed to the user by default, but you can patch

amdgpu_init_debug_options

or alternatively add the module parameter yourself.

Last edited by altoid (Today 00:40:57)

altoid

Member

From: Germany

Registered: 2019-09-19

Posts: 13

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

Hi, can everyone try

amdgpu.reset_method = 0

on your kernel command line?

Completely fixes it for me, suspend and resume worked 3 (now 5..) times in a row with both Firefox and Spotify using hardware acceleration, and rings don't timeout anymore.

This is definitely related to an older issue, and will likely take a bit longer to "properly" fix.

I also posted the same finding on GitLab... hope this works, at least temporarily.

Last edited by altoid (Yesterday 12:29:16)

itektur

Member

Registered: 2014-03-01

Posts: 23

Re: It's back: Log spam: [drm] scheduler comp_1.0.2 is not ready, skipping

Hi, can everyone try

amdgpu.reset_method = 0

on your kernel command line?

Completely fixes it for me, suspend and resume worked 3 (now 5..) times in a row with both Firefox and Spotify using hardware acceleration, and rings don't timeout anymore.

Works for me as well, thanks.