Re: [BUG] procs_blocked / PSI io pressure stuck high from boot with zero tasks in D state

[Christian Loehle]

On 4/10/26 17:15, Martin Alderson wrote:
> 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) .
> 
Anything using io_uring?
See also
https://lore.kernel.org/lkml/14bc6266-5bc9-4454-9518-d1016bfe417b@xxxxxxxxxxx/