Hi Geert, Jens,
thanks for the hint - applying 10825410b956dc1e on top of 5.17-rc1 does
indeed fix the issue.
nr_tags == 1 on the Falcon may explain why I ran into this. Oddly
enough, I have the same on ARAnyM. Adding a second 'disk' there does
reproduce the issue on ARAnyM though. nr_tags == 1 && nr_disks > 1
appears to be sufficient to reproduce this.
I surmised I couldn't be the only one to run into this, but hadn't seen
any other reports yet.
Cheers,
Michael
Am 05.02.2022 um 21:31 schrieb Geert Uytterhoeven:
Hi Michael,
On Sat, Feb 5, 2022 at 1:04 AM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
commit 180dccb0dba4f5e84a4a70c1be1d34cbb6528b32 (blk-mq: fix tag_get
wait task can't be awakened) does cause a regression on my m68k hardware
test rig (m68k Falcon030, IDE disk attached through pata-falcon driver
which does use polled IO instead of interrupts, so may be a little on
the slow side).
Bisection between v5.16 and v5.17-rc1 points to
180dccb0dba4f5e84a4a70c1be1d34cbb6528b32 as the culprit, which is
corroborated by reverting that commit in v5.17-rc1 and booting as
rapidly as before.
Now you know the culprit, it looks like several other people ran into this.
Does this fix help?
https://lore.kernel.org/all/1643040870.3bwvk3sis4.none@localhost/
It is commit 10825410b956dc1e ("blk-mq: Fix wrong wakeup
batch configuration which will cause hang") in v5.17-rc2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
