Looks to resolve the "stack smashing detected" crash on start.

@sunwire, that was a quick hack to get around a change in opensc, it'll be reverted in the next build now that a proper fix is in place. Sorry for the inconvenience.

This update has been unpushed.

It looks like option is for security updates only, although the CLI docs aren't exactly clear. dnf upgrade --enablerepo=updates-testing kernel should work.

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.

Thanks for the tests and feedback, a fix for bug 1708717 and bug 1718414 should both be in kernel-5.1.8-200.fc29 which obsoletes this update.

The fstrim patch is queued up for 5.1.5 so unless that gets delayed it'll be available in updates-testing in the next day or two.

This update has been unpushed.

This update has been unpushed.

Unit tests pass with the Python stuff I work on and it seems to be generally functional.

Thanks for the testing and feedback, taur. I've rebuilt it with the fixed dependency pinning in matrix-synapse-0.34.0.1-2.fc28.

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.

Hi @mjg,

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.

Does this contain the fix for the block layer data corruption bug described in https://lwn.net/Articles/774440/ and https://bugzilla.kernel.org/show_bug.cgi?id=201685 ?

Yes

Also, when you file the bug report, it would be helpful to know if the kernel at https://koji.fedoraproject.org/koji/taskinfo?taskID=31411873 resolves your issue or not. Thanks!

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).

nucleo,

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.

Thanks!

@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.

This update has been unpushed.