Yes, 5.1.15 is building, but kernel builds take the better part of a day and repo pushes only happen about once a day so there's quite a lag between the tagging of a new release and it being available in Fedora. I'd rather get people testing the v5.1.13 and v5.1.14 changes now, and if it doesn't get enough positive karma before v5.1.15 is ready I'll just override the update.
Fedora 4.19 kernels before 4.19.5 and after show an acpi crash for me on an old HP/compaq 6715b laptop with an AMD Turion. Same crash with 4.19.8, whereas 4.19.5 did work. Low and behold: the koji build https://koji.fedoraproject.org/koji/taskinfo?taskID=31411873 ("atomacpi") works, the kernel boots as usual.
Thanks for testing that. Please file a bug in Bugzilla and include kernel logs from a crashed boot (journalctl --no-hostname -k -b <bootnumber>) so we can track this. Hopefully the anonymous commenter will also comment on that bug and verify if that kernel works for them.
Hi anonymous user,
And I'm not here to irritate people, so if you think this is an upstream issue please point me towards the correct upstream bug tracker.
To start with, please file a bug report on https://bugzilla.redhat.com/. It's almost certainly an upstream issue, but we can narrow down who to contact on the bug report.
The ACPI (?) issue that re-appeared with 4.19.6 is still here on an Atom server. Getting really used to this recovery mode console the hoster has at this point :)
Please file a bug report with kernel logs and include the last known working kernel version (based on other anonymous comments in previous updates I'm guessing this appeared in the v4.19 rebase).
Can you file a bugzilla with the dmesg attached? Also, can you reliably reproduce this? Is it reproducible in v4.19.5? The patch you linked is actually one of the patches Fedora is carrying - it's been in v4.19.5 and is also included in this kernel. Upstream stable has it queued for v4.19.7.
@hreindl, yes, there's a performance regression from STIBP, but upstream is aware of it and things will get better in future releases. It sounds like the ext4 corruption bug is due to CONFIG_SCSI_MQ_DEFAULT=y which is not set in current builds.