I will report that my GPD Pocket 2 with the Celeron 3965Y is stabilized by switching the IO Scheduler to mq-deadline, so BFQ bugs were, at least, the cause of the issues on my system. So definitely give that a try if you haven't.

In the meantime you can just echo mq-deadline | tee /sys/block/*/queue/scheduler to switch to a (in many cases faster anyways) different IO scheduler.

Yeah, but the machine having the issue is usually running that custom kernel (needs the features), so I'm going to see if that patch and that patch alone, when applied to a vanilla kernel, will fix the issue. Just started the COPR job for the rebuild. I'll let you know how it pans out.

What commit is reverted here? What's the changeset? I also maintain a custom kernel I use on several systems, I'd like to add the patch there too.

From what I can tell -- these issues occur on systems that do not support AVX/AVX2, like my Celeron 3965Y. That is probably relevant.

Causes hard lockups when a KVM guest is running on my GPD Pocket 2 with a Celeron 3965Y CPU and 8GB RAM. Runs fine for a random amount of time (less than an hour) and then the host OS hard locks up requiring me to hold the power button down. I can't get anything from dmesg and NMI watchdog isn't giving me anything before it hangs. Last tested kernel that functions correctly is 5.14.4.

@mtasaka I will post the issue here in any case. On some machines, after several attempts with the correct password, it eventually lets me in. The number of required attempts is unpredictable. On others, the only option is logging in via TTY or ssh and killing xscreensaver.

@mtasaka Are you sure you want a bug report for a package only in testing? I can create one if you like, but seems a bit odd, at least to me.

On every system that uses this version of xscreensaver, I am frequently unable to unlock the screen at all, and must jump to a TTY to kill the xscreensaver process.

Downgrading to the version in the stable "fedora" repo fixes the issue instantly. Whatever was changed, it's not an improvement.

I'll look into filing a bug report, though I'd hope it's the kind of obvious issue they'd find immediately. I'd pull this for all releases of Fedora.

Can you unpush this one as well @nonamedotc? The graphical distortions happen on both fc32 and fc33, and I would assume rawhide as well.

Can someone integrate the patch for aarch64 yet and spin off a new build?

Causes all sorts of interesting graphical distortions in some apps, fine in others. And, as mikoim mentioned, it distorts the window decoration buttons.

I would advise pulling this from testing. It's unusable, and a pain for those of us who keep testing enabled by default.