With a post 5.8 kernel Fedora doesn’t work anymore on certain Ryzen CPUs, apparently. What is sad about it is that apparently no developers seem to have any interest in it: 1899805 – [5.8.9 -> 5.9 REGRESSION] Constant hard freezes with "BUG: Bad page state in process swapper/8", works fine with previous kernel Given the high impact of this, I just wanted to express my sadness about this. I know this is a volunteers project, but I did previously think kernel regressions and getting it to boot at all when it did before would be a considerably high priority. Now I’m no longer so sure.
So why not just stick with the 5.8 kernel that works? I’m not aware of anything that would be “forcing” you to run the newer kernels. I’m sure they’ll get the problem fixed eventually, but you cannot really expect/demand immediate service for something that you are getting for free.
I mean if that is sort of the official attitude towards looking into any regressions I’ll gladly switch to Debian stable or something. I’m not sure if I even should answer why that is a horrible idea. Even running Windows is legit a way better idea than doing what you are suggesting for so many reasons, so I’m not sure why you would even be suggesting that.
That doesn’t change of course that I am not entitled to a solution, but really, a regular standard x64 desktop PC with normal hardware is expected to just drop out of support and there’s not the slightest interest? That seems a bit wild to be considered “normal” even if it doesn’t concern a larger user group, but maybe that’s just me. Think about it, next time, it could be your desktop PC.
There are a lot of bugs, and a lot of different hardware out there. The kernel team isn’t disinterested, it’s just… a lot. Just triaging the number of kernel bugs that come in is a full-time job, and often a thankless one. If this is something that has wide impact, and it sounds like it might, it might be a candidate for a Prioritized Bugs nomination.
That said, your latest update in that bug says that you’ve tried “5.11.0-0.rc4.129.vanilla.1.fc33.x86_64”. That’s a pre-release for the 5.11 kernel, while the latest available update is 5.11.11-200.fc33 — the eleventh patch release after 5.11. And I notice that 5.11.12 is in testing. If you’ve tried these as well and they still are causing problems, the prioritized bug approach might be a good one.
All curently supported Fedora versions which are getting updates including security updates and bug fixes, Fedora 32, Fedora 33, Fedora 34. Are currently on 5.11.11 and 5.11.12 is in testing as @mattdm stated before.
Its always recommended to use fedora release which is supported. Some people do stay 1 release back to the current stable release which is fine as 1 release comes after roughly 6 months as is supported for 13 months.
Kernel hasn’t abandoned any ryzen CPU’s I have a ryzen 3600x. In case there is a bug in a particular kernel version on a certain hardware. By default you can choose 2 older kernels as they don’t get removed when doing a dnf update.
linux-lts kernels are designed for long term support and latest stable releases that comes with fedora after testing by fedora project and the community on bodhi do bring newer hardware support. And Red Hat kernels backports changes from newer kernel releases. This just brings me to the first point, your kernel/ Fedora version is not getting tested upstream by kernel devs and also is not actively being tested on Fedora bodhi.
This just brings me to the first point, your kernel/ Fedora version is not getting tested upstream by kernel devs and also is not actively being tested on Fedora bodhi.
Maybe this policy needs to be changed then?
It does worry me that Fedora 33 just randomly out of the blue upgraded to a kernel that made a bunch of machines completely unusable, and then basically nothing happens when the bug is reported (until I mentioned it here/it is magically fixed in a next major release of the kernel only months down the line).
It does however work now @mattdm it seems like it was fixed. I only tested 5.11.0-0.rc4 (broken) because it was the newest at the time, and I tested regularly the 5.9+ releases Fedora had up to then (all broken), but just gave up since apparently nobody seemed to really care anyway. But if regressions aren’t dealt with until the next major release, why even jump kernel versions before that in such a risky way? I don’t get it.
Well, like I said, there are a lot of bugs, and a lot of different hardware out there. It’s usually the case that updates fix a lot of problems, fix security issues, and enable or improve hardware support. It’s certainly unfortunate when there are regressions. But the process isn’t “out of the blue” – kernels do go through quite a bit of testing before release. I’m sorry this update affected you in a negative way.
The problem isn’t when regressions exist but when they are left aside. Which I understand due to time constraints, but then why is the update process like it is? I just don’t understand how this is supposed to work out on a production machine. Isn’t Fedora one of the only non-rolling distro that just jumps major kernel versions mid cycle like that? Should it really? If the regressions aren’t really handled timely, maybe it shouldn’t.
But if it didn’t, then it would be more difficult for people who want to test/use/develop on the newer kernels. I think providing them automatically is part of being leading edge. As Matt said, they do go through quite a bit of testing and they are supposed to be stable enough for the vast majority of people that they shouldn’t feel like they are on the bleeding edge. That said, Fedora Linux has always tried to make it easy for users to revert the new changes on their system and file a bug report if there are problems. Use dnf downgrade <package name> if their is a problem with a package or select a previous kernel from the boot menu in the case of a problem with the kernel. You can even rollback the entire OS if you are using Btrfs (the default since Fedora Linux 33).
This is just how Fedora Linux works – by using Fedora Linux, you can become part of the process of advancing Linux.