Messages in this thread |  | | From | Martin Alderson <> | | Date | Fri, 10 Apr 2026 17:15:20 +0100 | | Subject | [BUG] procs_blocked / PSI io pressure stuck high from boot with zero tasks in D state |
| |
Hi,
I'm hitting what looks like a kernel accounting bug where nr_iowait / procs_blocked and PSI io pressure are pinned high from the moment the system boots, with no tasks actually blocked on I/O and no real device activity to explain it.
## System - Kernel: 7.0.0-rc7 vanilla (7.0.0-0.rc7.260409.7f87a5ea.256.vanilla.fc43.x86_64) - Also reproduces on the stock Fedora 43 kernel I was running before switching to the vanilla 7.0-rc series — this is not a 7.0-rc regression, it's longer-standing. - CPU: AMD Ryzen 9 7900 (Raphael), 24 threads - Board: ASUS PRIME B650-PLUS - Distro: Fedora 43, GNOME on Wayland - Root FS: ext4 on NVMe (Corsair MP600 Pro) - Also mounted: btrfs on SATA
## Symptom
From boot, with the machine otherwise idle:
$ grep procs /proc/stat procs_running 1 procs_blocked 4
$ cat /proc/pressure/io some avg10=82.78 avg60=83.13 avg300=80.96 total=19613045470 full avg10=81.76 avg60=81.74 avg300=79.26 total=19138664524
$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu------- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 4 0 45064848 624228 10139452 0 0 107 274 4468 5 2 1 80 17 0 0 4 0 45072984 624228 10136356 0 0 0 0 14842 14678 1 1 82 16 0 0 4 0 45072264 624228 10136356 0 0 0 0 12841 13445 1 1 82 16 0 0 4 0 45080972 624228 10136356 0 0 0 0 13930 14327 1 1 82 16 0 0 4 0 45081692 624228 10136356 0 0 0 28 13537 13828 1 1 82 16 0
b=4, wa=16-17%, but bi/bo are zero across every sample after the first.
iostat -x 1 confirms no actual device activity anywhere:
avg-cpu: %user %nice %system %iowait %steal %idle 1.13 0.00 0.46 17.39 0.00 82.09 Device r/s rkB/s w/s wkB/s aqu-sz %util nvme0n1 0.00 0.00 0.00 0.00 0.00 0.00 sda 0.00 0.00 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 0.00 0.00 0.00 zram0 0.00 0.00 0.00 0.00 0.00 0.00
And critically - there is nothing actually in D state to account for procs_blocked=4:
$ ps -eL -o pid,tid,stat,wchan:40,comm | awk '$3 ~ /D/' (no output)
Nothing at the process level either. The counter is stuck, and it's stuck at a value (4) higher than any real count I can find anywhere in the system.
## Reproduction
100% reproducible on this machine: boot, wait for the desktop, check /proc/stat. procs_blocked is already non-zero. It only grows, never decays - current uptime is 15h40m and the counter has been >= 4 the whole time. PSI io "some" and "full" both sit around 80%+ indefinitely.
Workload during reproduction is a plain idle GNOME session (Chrome, a few terminals). Load average 0.40. No hung-task warnings in dmesg, kernel log is otherwise clean.
## What I've ruled out
- Not a stuck userspace task - nothing in D state at process or thread level (ps -eL -o stat). - Not a stuck kernel thread - same check covers kthreads. - Not real device pressure - iostat shows 0.00 %util across nvme, both SATA disks, and zram across sustained 1s samples. - Not hung-task related - no "INFO: task ... blocked for more than" warnings in dmesg. - Not cgroup-scoped weirdness - both /proc/pressure/io (system-wide) and /proc/stat show it. - Not a display/compositor artifact - reproduces on a cold boot to a TTY before GNOME starts. - Not a 7.0-rc regression - reproduces identically on the previous Fedora 43 6.19 kernel(s) .
## Impact
top, htop, and any monitoring reading PSI all show bogus I/O pressure from boot. More importantly, anything making scheduling or throttling decisions based on PSI - systemd-oomd especially, which uses PSI io and memory thresholds to decide when to kill processes - could easily misbehave on this system.
Thanks, Martin
|  |