works fine on Processors: 8 × Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000 no regressions.
Works for me: desktop 16GB Intel i7-3770 CPU & laptop 8GB Intel i5-2520M CPU Lenovo T420 (the desktop ran the performance test in 10m9s -- but the laptop took 9m33s, about 10 times longer) - all using the Mate Desktop Environment.
[[[ In kernel-5.14.6-300.fc35 the laptop was 10 times slower than the desktop! ]]]
Works for me.. I have been running the 5.14.x kernel's for a while now..
The enabled Default and Performance tests pass OK. AMD 965, x86_64 work station, SSD's > RAID1. Plasma DE from Zawertun's COPR, X-org, nVidia GTX 650 (GK107) nVidia RPM's from RPMFusion (470.74)
using correct kernel & version of Fedora!
AMD Ryzen 9 5950X 16-Core Processor
64 GB of RAM
Mate Desktop Environment
Got error when executing: semanage boolean -m --on selinuxuser_execheap
libsepol.context_from_record: type cloud_what_var_cache_t is not defined
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert system_u:object_r:cloud_what_var_cache_t:s0 to sid
invalid context system_u:object_r:cloud_what_var_cache_t:s0
libsemanage.semanage_validate_and_compile_fcontexts: setfiles returned error code 255.
OSError: [Errno 0] Error
Got errors in performance test, which claimed to have passed!
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/11/../../../libtirpc.so when searching for -ltirpc
/usr/bin/ld: skipping incompatible /lib/libtirpc.so when searching for -ltirpc
/usr/bin/ld: skipping incompatible /usr/lib/libtirpc.so when searching for -ltirpc
/usr/bin/ld: cannot find -ltirpc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/11/../../../libtirpc.so when searching for -ltirpc
/usr/bin/ld: skipping incompatible /lib/libtirpc.so when searching for -ltirpc
/usr/bin/ld: skipping incompatible /usr/lib/libtirpc.so when searching for -ltirpc
collect2: error: ld returned 1 exit status
gmake[2]: [Makefile:293: ../bin/x86_64-linux-gnu/bw_file_rd] Error 1
make[1]: [Makefile:114: lmbench] Error 2
make: *** [Makefile:23: results] Error 2
./performance/lmbench3 PASS
Looks ok for me. Works on baremetal (non UEFI mode) AMD Ryzen5 3600, Mainboard MSI B450M Mortar Max with prop. nvidia driver from rpmfusion.org (GTX980 card). Works with Gnome-Desktop (Xorg). Regression test passed (paxtest, selinux-dac-controls and libhugetlbfs skipped). VirtualBox 6.1.26 from Oracle seems to works too.
After updating to this kernel I got three system freezes within two hours - and a corruption that broke a git folder (this is on BTRFS). On a Thinkpad 460p. After downgrading to 5.13.19 (no other changes) things seem to be stable again.
Something is wrong with this update. I upgraded from the 3.14.5 kernel and the system froze after some time. I had to reboot via reset. This has not happened for a long time. The system worked stably with the kernel 5.13.*, 5.14.4 and 5.14.5
Doesn't work on 2 machines - one router restarts every 5 minutes now (presumably panics and reboots), another started panicink in console repeatedly, killed ipv4 (but was still responding to ipv6 pings).
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.
Just out of curiosity? Are all of the people with random lockups using btrfs? Just seeing if these are all the same issue, or different. Sadly very few people have opened bugs or given data.
Hi!
Just XFS and Ext4 on the servers affected at my end. I have totally 8 different servers crashing consistently with this update. HP ProLiant DL380 G7 and IBM BladeCenter HS22. It took an hour till a day for them to crash.
I can look for more traces in the logs if it's of interest.
The system is on btrfs. Xeon E5-2650 v2 processor. An old processor. There were freezes on Fedora 32 under ext4. But a long time ago. There was a partially broken file system due to the user's fault. Therefore, the Fedora 34 was re-installed on a clean ssd.
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.
I wish I was unable to provide additional detail, but after a day or so of running I've also had two Intel NUC machines x86_64 hit what seems like the arbitrary total lockup--machines not pingable, no logs or kernel oops' retreivable. I look forward to trying 5.14.8.
Hmmm... after initially reporting that it works on my DELL XPS 9700 I've experienced multiple hangs as well.
IO scheduler is 'none', as I've got an NVME drive. And yes, it's a BTRFS filesystem.
Also, just experienced kernel hang with lockup on my testing Intel NUC machine (i7-10710U).
@jforbes there are multiple issues reported related to this kernel update.
IMO, makes sense not to proceed with having 5.14.7-200.fc34 in testing, since many people can get issues with this update, and kernel-5.14.8-200.fc34 with a potential fix is already available.
I think it's also clear that the scheduler issue does not solve all hangs. That issue is related to the BFQ scheduler and I at least have hangs while using the no IO scheduler ('none').
@dfateyev I am not sure what leads you to believe that kernel-5.14.8-200.fc34 has a fix. I held off on filing 5.14.8 as an update because it did not contain the fix for the most common issue.
@spockfish did you test the scratch build? It had that one fix, but also a number of other fixes as it is 5.14.8 instead of 5.14.7
I have been running this kernel on my Ryzen 5950X box for 5 days and 20 minutes according to top. I've had no hangups nor other such problems that I can attribute to the kernel. I use this box for over 10 hours most days for a wide variety of tasks from compiling to browsing the web -- Fedora 34.
And using Fedora 35, I have been running on an Intel i7-3770 CPU for 6 days and 20 hours non stop without problems, but the box doesn't get much use. My laptop with an Intel i5-2520M CPU (had to be rebooted for an unrelated reason) has been used on & off for about 7 days -- also Fedora 35.
@jforbes I thought that the build from #2225593 was a part of the next kernel-5.14.8-200.fc34 update built earlier. Now I see that they are different. I will test packages from the scratch build provided.
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.
This update has been submitted for testing by jforbes.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
works fine on Processors: 8 × Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000 no regressions.
Default & performance tests pass (KVM)
Works for me: desktop 16GB Intel i7-3770 CPU & laptop 8GB Intel i5-2520M CPU Lenovo T420 (the desktop ran the performance test in 10m9s -- but the laptop took 9m33s, about 10 times longer) - all using the Mate Desktop Environment.
[[[ In kernel-5.14.6-300.fc35 the laptop was 10 times slower than the desktop! ]]]
wrong fedora version
This update's test gating status has been changed to 'passed'.
i7-9700K(UHD Graphics 630): kernel regression test passed. Works fine for daily use.
Works for me.. I have been running the 5.14.x kernel's for a while now..
The enabled Default and Performance tests pass OK. AMD 965, x86_64 work station, SSD's > RAID1. Plasma DE from Zawertun's COPR, X-org, nVidia GTX 650 (GK107) nVidia RPM's from RPMFusion (470.74)
This update has been pushed to testing.
This update can be pushed to stable now if the maintainer wishes
Works.
using correct kernel & version of Fedora! AMD Ryzen 9 5950X 16-Core Processor 64 GB of RAM Mate Desktop Environment
Got error when executing: semanage boolean -m --on selinuxuser_execheap libsepol.context_from_record: type cloud_what_var_cache_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:cloud_what_var_cache_t:s0 to sid invalid context system_u:object_r:cloud_what_var_cache_t:s0 libsemanage.semanage_validate_and_compile_fcontexts: setfiles returned error code 255. OSError: [Errno 0] Error
Got errors in performance test, which claimed to have passed! /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/11/../../../libtirpc.so when searching for -ltirpc /usr/bin/ld: skipping incompatible /lib/libtirpc.so when searching for -ltirpc /usr/bin/ld: skipping incompatible /usr/lib/libtirpc.so when searching for -ltirpc /usr/bin/ld: cannot find -ltirpc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/11/../../../libtirpc.so when searching for -ltirpc /usr/bin/ld: skipping incompatible /lib/libtirpc.so when searching for -ltirpc /usr/bin/ld: skipping incompatible /usr/lib/libtirpc.so when searching for -ltirpc collect2: error: ld returned 1 exit status gmake[2]: [Makefile:293: ../bin/x86_64-linux-gnu/bw_file_rd] Error 1 make[1]: [Makefile:114: lmbench] Error 2 make: *** [Makefile:23: results] Error 2 ./performance/lmbench3 PASS
Test suite complete PASS
PASS
works fine on my system.
HP Laptop with Dual Core AMD E-300 APU with Radeon HD Graphics (-MCP-) 8gb ram.
although I did get a warn on kernel regression dealing with sysfs perfom. Running regression test with Performance flag was a pass though.
works on intel 1135g7, nuc11
Looks ok for me. Works on baremetal (non UEFI mode) AMD Ryzen5 3600, Mainboard MSI B450M Mortar Max with prop. nvidia driver from rpmfusion.org (GTX980 card). Works with Gnome-Desktop (Xorg). Regression test passed (paxtest, selinux-dac-controls and libhugetlbfs skipped). VirtualBox 6.1.26 from Oracle seems to works too.
Works for me on Dell XPS 9700.
After updating to this kernel I got three system freezes within two hours - and a corruption that broke a git folder (this is on BTRFS). On a Thinkpad 460p. After downgrading to 5.13.19 (no other changes) things seem to be stable again.
Fails to boot on VMWare guests. Rolling back to the last booting kernel (5.13.14).
I haven't found any problems yet.
No regressions found
Something is wrong with this update. I upgraded from the 3.14.5 kernel and the system froze after some time. I had to reboot via reset. This has not happened for a long time. The system worked stably with the kernel 5.13.*, 5.14.4 and 5.14.5
System freezes after few hours. No problem with the kernel-5.13.19-200.fc34.x86_64 and previous versions.
I also see freezes after a few hours on several servers with heavy load that used to work stably with the 5.13 series.
For what it's worth - here are two traces:
------------[ cut here ]------------ WARNING: CPU: 1 PID: 2520 at kernel/ucount.c:280 dec_rlimit_ucounts+0x50/0x60 Modules linked in: binfmt_misc rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache netfs rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf> CPU: 1 PID: 2520 Comm: agent_control Tainted: G I 5.14.7-200.fc34.x86_64 #1 Hardware name: HP ProLiant DL380 G7, BIOS P67 05/21/2018 RIP: 0010:dec_rlimit_ucounts+0x50/0x60 Code: c8 f0 48 0f c1 04 31 48 29 d0 78 1e 48 39 cf 4c 0f 44 c0 48 8b 41 10 48 8b 88 e8 01 00 00 48 85 c9 75 db 4d 85 c0 0f 94 c0 c3 <0f> 0b eb de 31 c0 c3 66 0f 1f 84 00 00 00 00 00 0f 1f> RSP: 0018:ffffb53690527db8 EFLAGS: 00010296 RAX: ffffffffa963d36f RBX: ffffb53690527eb8 RCX: ffff977268261b00 RDX: 0000000000000001 RSI: 0000000000000080 RDI: ffff977268261b00 RBP: ffff977268261b00 R08: ffffffffffffffff R09: ffffffffffffffff R10: 00000000fb6cd72d R11: 0000000000000000 R12: 0000000000000b3f R13: 0000000000000010 R14: dead000000000122 R15: ffff976649b10000 FS: 00007f51cac6e740(0000) GS:ffff977c37a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8293daeb00 CR3: 0000000d2ea8e005 CR4: 00000000000206e0 Call Trace: release_task+0x45/0x4d0 ? thread_group_cputime_adjusted+0x3b/0x50 wait_consider_task+0x494/0xa90 do_wait+0x1e8/0x2e0 kernel_wait4+0x96/0x120 ? thread_group_exited+0x50/0x50 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f51cad3faca Code: ff e9 0a 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 3d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 5e c3 0f 1f 44 00 00 48 83 ec 28> RSP: 002b:00007ffe7b2fe338 EFLAGS: 00000246 ORIG_RAX: 000000000000003d RAX: ffffffffffffffda RBX: ffffffffffffff60 RCX: 00007f51cad3faca RDX: 0000000000000003 RSI: 00007ffe7b2fe34c RDI: 00000000ffffffff RBP: 0000000000000000 R08: 0000000000000000 R09: 00007ffe7b2fe700 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f51cac6e6a0 R13: 0000000000000000 R14: 0000000000000001 R15: 00000000018206d0 ------------[ cut here ]------------
------------[ cut here ]------------ kernel BUG at mm/slub.c:321! invalid opcode: 0000 [#1] SMP PTI CPU: 21 PID: 1205930 Comm: python3 Not tainted 5.14.7-200.fc34.x86_64 #1 Hardware name: IBM BladeCenter HS22 -[7870TKN]-/68Y8161, BIOS -[P9E164CUS-1.28]- 04/17/2018 RIP: 0010:__slab_free+0x245/0x4a0 Code: 0f b6 5c 24 1b 44 8b 44 24 1c 48 89 44 24 08 48 8b 54 24 20 4c 8b 4c 24 28 e9 8a fe ff ff 41 f7 45 08 00 0d 21 00 75 98 eb 8d <0f> 0b 49 3b 54 24 28 0f 85 53 ff ff ff 49 8b 44 24 08 4> RSP: 0018:ffffb6934db7fda0 EFLAGS: 00010246 RAX: ffff9ec506bf81e0 RBX: ffff9ec506bf8180 RCX: ffff9ec506bf8180 RDX: 00000000802a0029 RSI: ffffe444841afe00 RDI: ffff9ec500042800 RBP: ffffb6934db7fe50 R08: 0000000000000001 R09: ffffffffb710b505 R10: ffff9ed6f338d000 R11: 0000000062667658 R12: ffffe444841afe00 R13: ffff9ec500042800 R14: ffff9ec506bf8180 R15: ffff9ec506bf8180 FS: 00007fb9deb00740(0000) GS:ffff9ee21fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9d15315f0 CR3: 000000010b450001 CR4: 00000000000206e0 Call Trace: ? filename_lookup+0x135/0x1b0 ? put_ucounts+0x65/0x70 kfree+0x369/0x3c0 put_ucounts+0x65/0x70 put_cred_rcu+0x70/0xd0 do_faccessat+0x113/0x240 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fb9ded6744b Code: 77 05 c3 0f 1f 40 00 48 8b 15 29 1a 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 f3 0f 1e fa b8 15 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 f9 19 0> RSP: 002b:00007fff21cd8e98 EFLAGS: 00000202 ORIG_RAX: 0000000000000015 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9ded6744b RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00007fb8fc07f390 RBP: 0000000000000001 R08: 0000000000000000 R09: 00007fb9d1596930 R10: 00007fb8fc07f000 R11: 0000000000000202 R12: 00007fff21cd8eb0 R13: 0000000000000001 R14: 000055b9f23d2bd0 R15: 00000000ffffff9c Modules linked in: binfmt_misc rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache netfs xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_nat_tftp nft_objref n> scsi_transport_sas mptscsih bnx2 mptbase crc32c_intel i2c_algo_bit target_core_mod fuse ---[ end trace 2615b3389f7a01df ]--- RIP: 0010:__slab_free+0x245/0x4a0 Code: 0f b6 5c 24 1b 44 8b 44 24 1c 48 89 44 24 08 48 8b 54 24 20 4c 8b 4c 24 28 e9 8a fe ff ff 41 f7 45 08 00 0d 21 00 75 98 eb 8d <0f> 0b 49 3b 54 24 28 0f 85 53 ff ff ff 49 8b 44 24 08 4> RSP: 0018:ffffb6934db7fda0 EFLAGS: 00010246 RAX: ffff9ec506bf81e0 RBX: ffff9ec506bf8180 RCX: ffff9ec506bf8180 RDX: 00000000802a0029 RSI: ffffe444841afe00 RDI: ffff9ec500042800 RBP: ffffb6934db7fe50 R08: 0000000000000001 R09: ffffffffb710b505 R10: ffff9ed6f338d000 R11: 0000000062667658 R12: ffffe444841afe00 R13: ffff9ec500042800 R14: ffff9ec506bf8180 R15: ffff9ec506bf8180 FS: 00007fb9deb00740(0000) GS:ffff9ee21fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9d15315f0 CR3: 000000010b450001 CR4: 00000000000206e0 ------------[ cut here ]------------
Doesn't work on 2 machines - one router restarts every 5 minutes now (presumably panics and reboots), another started panicink in console repeatedly, killed ipv4 (but was still responding to ipv6 pings).
Had a few full system freezes since using this kernel. Thinkpad T580, i5-7300U CPU, Intel(R) HD Graphics 620
jforbes edited this update.
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.
Just out of curiosity? Are all of the people with random lockups using btrfs? Just seeing if these are all the same issue, or different. Sadly very few people have opened bugs or given data.
Hi! Just XFS and Ext4 on the servers affected at my end. I have totally 8 different servers crashing consistently with this update. HP ProLiant DL380 G7 and IBM BladeCenter HS22. It took an hour till a day for them to crash.
I can look for more traces in the logs if it's of interest.
The system is on btrfs. Xeon E5-2650 v2 processor. An old processor. There were freezes on Fedora 32 under ext4. But a long time ago. There was a partially broken file system due to the user's fault. Therefore, the Fedora 34 was re-installed on a clean ssd.
From what I can tell -- these issues occur on systems that do not support AVX/AVX2, like my Celeron 3965Y. That is probably relevant.
Anyone experiencing the lock ups want to try https://koji.fedoraproject.org/koji/taskinfo?taskID=76424019 and let me know how it goes? It is a scratch build, so not secure-boot signed, but it has a revert I think might help.
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.
https://git.kernel.dk/cgit/linux-block/commit/?h=block-5.15&id=ebc69e897e17373fbe1daaff1debaa77583a5284 is the revert I added, though I might recommend waiting for verification that it does solve the problem before spending too much time on it.
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.
I wish I was unable to provide additional detail, but after a day or so of running I've also had two Intel NUC machines x86_64 hit what seems like the arbitrary total lockup--machines not pingable, no logs or kernel oops' retreivable. I look forward to trying 5.14.8.
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.
Hmmm... after initially reporting that it works on my DELL XPS 9700 I've experienced multiple hangs as well. IO scheduler is 'none', as I've got an NVME drive. And yes, it's a BTRFS filesystem.
one silent guess: all affected systems here have Intel CPUs, correct? I have an AMD Ryzen 3600 and i did not have a single hang noticed. I use ext4.
Try to change scheduler, works fine for me with F35 https://bodhi.fedoraproject.org/updates/FEDORA-2021-ab2ecc91bd#comment-2226481
getting random freeze and lockup on cpu and memory pressure, running intel 1135g7
Also, just experienced kernel hang with lockup on my testing Intel NUC machine (i7-10710U).
@jforbes there are multiple issues reported related to this kernel update. IMO, makes sense not to proceed with having 5.14.7-200.fc34 in testing, since many people can get issues with this update, and kernel-5.14.8-200.fc34 with a potential fix is already available.
I think it's also clear that the scheduler issue does not solve all hangs. That issue is related to the BFQ scheduler and I at least have hangs while using the no IO scheduler ('none').
Unlucky for this build version. Hopefully next build will be better at least for regression test.
@dfateyev I am not sure what leads you to believe that kernel-5.14.8-200.fc34 has a fix. I held off on filing 5.14.8 as an update because it did not contain the fix for the most common issue.
@spockfish did you test the scratch build? It had that one fix, but also a number of other fixes as it is 5.14.8 instead of 5.14.7
Sorry it’s my fault, I confused the -200 and -300 versions of kernel 5.14.8 when I downloaded the packages.
It seems to be fine with special 5.14.8-200.fc34.x86_64 from jforbes. Scheduler is [bfq]. 5 hours uptime without freeze.
@jforbes I'm now; keep you posted.
I have been running this kernel on my Ryzen 5950X box for 5 days and 20 minutes according to top. I've had no hangups nor other such problems that I can attribute to the kernel. I use this box for over 10 hours most days for a wide variety of tasks from compiling to browsing the web -- Fedora 34.
And using Fedora 35, I have been running on an Intel i7-3770 CPU for 6 days and 20 hours non stop without problems, but the box doesn't get much use. My laptop with an Intel i5-2520M CPU (had to be rebooted for an unrelated reason) has been used on & off for about 7 days -- also Fedora 35.
@jforbes I thought that the build from #2225593 was a part of the next kernel-5.14.8-200.fc34 update built earlier. Now I see that they are different. I will test packages from the scratch build provided.
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.
Random system freezes. Should be unpushed.
works for me for several days now
This update has been obsoleted by kernel-5.14.9-200.fc34.