Comments

152 Comments

This update has been unpushed.

This update has been unpushed.

It turns out there are some btrfs issues with this one, pulling it back 6.0.5 should be building soon.

This update has been unpushed.

It turns out there are some btrfs issues with this one, pulling it back 6.0.5 should be building soon.

@markec because the release was too late to count on for Fedora 37 with freezes and such. Fedora 37 will ship with 5.19, and 6.0 will be available as an update after Fedora 37 ships.

@nivag can you explain how this fails to boot? Does 5.19.12 boot on that system? The only difference between the 2 kernels is a revert of some i915 patches which can potentially damage laptop hardware. If you are seeing any issue not related to i915, it is likely systemd or firmware related. We need to figure it out though because the longer it takes for this update to make stable, the more exposure users have to potential damage.

@fschwarz Thanks for the clarification. I should have a fix for that in 5.19.9 when it ships. I was just making sure it wasn't something else, and thanks again for the workaround explanation here.

@fschwarz I do appreciate adding clarity about the issue to this update where people can see it. I am curious though, why after you make an entire post explaining how it is not a kernel issue at all, you add to that negative karma, and failed test case on kernel regression. Was there a different issue?

Cachedrop is racey, particularly on lower end hardware. I am not concerned with cachedrop failures.

@gtwilliams you just explained how it is not a kernel problem. I am guessing if you recreated your initramfs for 5.19.2 it would fail in the same way. Might be worth tracking down what changed there though, dracut or systemd are likely culprits. Updates on those packages often appear as kernel issues because an initramfs doesn't get regenerated when those packages are updated, so any problems they cause with the initramfs don't appear until your next kernel update unless you happen to regenerate the initramfs for other reasons.

Fedora did not build the 5.18.14 kernel because every single patch (other than the version bump itself) was included in the Fedora 5.18.13 build and there were only 2 or 3 of those patches which were not included in our 5.18.12 build. We shipped retbleed mitigations with 5.18.12, the day it went public. Upstream stable waited a bit to work out some of the issues, but yes, from a code standpoint, we did ship 5.18.14, we just called it 5.18.13, so it is not a new regression in this kernel. And I am still waiting for the f35 build of 5.18.16 to finish.

So you are saying that this AMD issue is new with our 5.18.15 kernel and did not appear before then? I was under the impression that it came in with the 5.18.14 stable kernel (retbleed mitigation), and Fedora specifically has been shipping those patches since 5.18.12. Also, it is not exactly a large number of users, but enough to form a simple pattern. My reasoning was this, there are a number of valid fixes in 5.18.15, and as far as I am aware, no actual regressions compared to the Fedora 5.18.13 kernel we are currently shipping.

@drfvd this update does not break it, it was broken in 5.17.15 (and 5.18.4). Follow https://bugzilla.redhat.com/show_bug.cgi?id=2097526 for fixes. I am guessing short term, the bad patch will be reverted, but it is broken upstream still so a proper fix needs to appear at some point.

Semantics in wording, hard coded into bodhi and not something that is controlled per update. But think of it this way, there are literally hundreds of open kernel bugs at all times. Yes, I look at all of them, no I do not comment on them unless I have a specific question that needs answering. But if everyone with a bug gave negative karma whenever an update did not fix their particular issue, no one would ever get a kernel update again. However bodhi may word it, the question is directed towards new regressions compared to what is in stable at the time.

The bug was not ignored, and there were several updates to it, with the last being a report that it magically started working again. Either way, it is a known issue, not a new regression. By giving negative karma, you are saying that every bug fixed for other users or new hardware support should not be made available because your microphone is more important than anything that might be fixed for the next release. Negative karma is for new regressions, bugzilla is where existing issues are handled.

@uservikol if it is not working since 5.17.7, then it is not a regression in this update.

javierm said the only issue keeping it from being usable on F34/F35 was the nvidia issue, and the fix put into this kernel worked around the nvidia issue keeping VTs functional.

The 5.17.4 kernel will be the first official 5.17 update for F35 and F34. I expect it will come out early next week. There were a few issues which popped up during test week, and I believe they are worked out with the 5.17.3 build I pushed to F36, but I want to be sure. This should be the last 5.16 build unless a critical security issue is found in the next couple of days (I don't like to force a rebase as the only fix to those)