Haven't any idea what's wrong with scx_loader

Hi, I encounter some problem with scx_scheds setup. It sometimes happen, and sometimes not. But this issue usually appear on https://github.com/whitehara/kernel-patch-fedora than this official build. It looks confusing because it often happen on official build too. It problem like this

```
● scx_loader.service - DBUS on-demand loader of sched-ext schedulers
Loaded: loaded (/usr/lib/systemd/system/scx_loader.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Sun 2026-07-05 16:44:59 WIB; 2s ago
Invocation: d5fed147f5b14127adc3eb7388473432
Main PID: 731742 (scx_loader)
Tasks: 11 (limit: 9140)
Memory: 7.3M (peak: 28.2M)
CPU: 463ms
CGroup: /system.slice/scx_loader.service
└─731742 /usr/bin/scx_loader

Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: makes BPF programs fail to load with 'func_proto incompatible with
Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: vmlinux'. This happens when the kernel was built with pahole < 1.26.
Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: Fix: boot a kernel whose BTF was generated with pahole >= 1.26.
Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: Affected distros include Ubuntu 24.04 LTS. See kernel commit
Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: 9edd04c4189e ("docs: Raise minimum pahole version to 1.26 for
Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: KF_IMPLICIT_ARGS kfuncs").
Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: Caused by:
Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: 0: Failed to load BPF program
Jul 05 16:45:00 ThinkPad-X280 scx_loader[732177]: 1: Invalid argument (os error 22)
Jul 05 16:45:01 ThinkPad-X280 scx_loader[731742]: [ERROR]: Failed to start scheduler (attempt 5/5)
```
Any idea what's wrong with it? I report it on [Whitehara repo](https://github.com/whitehara/kernel-patch-fedora/issues/4) too for tracing it. This is my config

```
$ cat /etc/scx_loader.toml
default_sched = "scx_bpfland"
default_mode = "Auto"

[scheds.scx_bpfland]
auto_mode = ["-f","-k","-m","auto","-P"]
gaming_mode = ["-m","performance","-f"]
lowlatency_mode = ["-m","performance", "-w"]
powersave_mode = ["-s","20000","-t","100","-I","100"]
server_mode = ["-s","2000","-S"]

[scheds.scx_tickless]
auto_mode = []
gaming_mode = []
lowlatency_mode = []
powersave_mode = []
server_mode = []

[scheds.scx_flash]
auto_mode = []
gaming_mode = []
lowlatency_mode = []
powersave_mode = []
server_mode = []

[scheds.scx_rusty]
auto_mode = []
gaming_mode = []
lowlatency_mode = []
powersave_mode = []
server_mode = []

[scheds.scx_p2dq]
auto_mode = []
gaming_mode = []
lowlatency_mode = ["-y"]
powersave_mode = []
server_mode = ["--keep-running"]

[scheds.scx_lavd]
auto_mode = []
gaming_mode = ["--performance"]
lowlatency_mode = ["--performance"]
powersave_mode = ["--powersave"]
server_mode = []
```

Thanks for your hard work :)

Start with the scx_loader.service status and logs in the report, then compare the /etc/scx_loader.toml configuration with the failing scx_bpfland startup attempts. Reproduce the intermittent failure on the official and Whitehara kernel builds, and use the referenced Whitehara issue for comparison. Done means identifying a reproducible cause and documenting the affected build or configuration.

Written by the indexing model from the issue text.