Comment 7 for bug 1946368

To summarize the current findings after several days of testing:

* In all monitors the freeze manifests the same, with the same dmesg output
* Some monitors, in particular it seems higher-frame-rate (100+Hz) monitors (but by no means exclusive to these) trigger the freeze quite easily, often before the login screen even appears
* Other monitors, in particular lower-frame-rate (60Hz) monitors do trigger the freeze, but only after some activity
* A few monitor(s) (so far only a 60Hz one) don't trigger the freeze at all (thanks to brian-murray for additional testing on this)

Over the weekend I tested the 5.11.0-1019 and 5.11.0-1021 linux-raspi kernels from hirsute, installing them onto the impish image. With my (60Hz) monitor, I was unable to reproduce the crash with either of these, but jawn-smith *did* reproduce the issue with the hirsute kernel on his high-frame-rate monitor.

In other words, even rolling all the way back to the hirsute kernel won't eliminate the freeze for everyone. The good news is that fkms does appear to reliably work around the issue (thanks for knoedelfan and fprietog for the reports in #3 and #4), although that in itself comes with its own issues (though none as severe as the display freezing).