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

[Martin Alderson]

  ▎ Anything using io_uring?

  Yes - several processes with io_uring rings active on the affected machine:

  - Ghostty (terminal, uses liburing natively) — 6 io_uring fds
  - Obsidian, Slack, Kuro - Electron apps, 3-7 io_uring fds each

  These are all running from boot / login and stay resident. The
io_uring fd count lines up with the stuck procs_blocked value (it only
  grows, never decays).

Thanks for the pointer.

Martin

On Sat, Apr 11, 2026 at 6:24 PM Christian Loehle
<christian.loehle@xxxxxxx> wrote:
>
> 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/