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 <[email protected]> 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 -- [email protected]
>
> 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
>