The 6.3.3 stable kernel rebase contains a several new features, additional hardware support, and a number of important fixes across the tree.
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2023-514965dd8aPlease login to add feedback.
| 0 | 9 | Test Case kernel regression |
This update has been submitted for testing by jforbes.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
Works for me, I have been testing the 6.3.x kernels for the test week with no issues. The enabled Default and Performance tests pass OK.
Work Station > Ryzen5 5600g/AMDGPU 400 Series Chipset. (UEFI + Secure Boot). SSD's > RAID1 (ext4) , running Plasma DE from Zawertun's COPR.
This update has been pushed to testing.
Works.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This update can be pushed to stable now if the maintainer wishes
disabled CONFIG_FB_EFI results in a black screen in tty with prop. nvidia driver
Works great on Lenovo T480! LGTM! =)
Default and performance pass. HP Prodesk 400 G6 Mini, i5-10400T, CometLake-S GT2 [UHD 630].
No issues found
works
Works OK for daily use and Xonotic CTF. Ryzen 3700x, Rog Strix B550-F board, nvidia from rpmfusion. Am getting this in dmesg: simple-framebuffer.0: swiotlb buffer is full... If I fall back to 6.2.15, that message now showing up but was not earlier. Likely the nividia drivers are broken, probably from flatpak updates. My suspicion, anyway.
./runtests.sh PASS with 6.3.3-200.fc38.x86_64 within a kvm/qemu VM (KDE spin, up to date with all testing repos of F38 enabled) on a AMD Ryzen 6000 mobile series host. No third party modules (tainted = 0).
I tested the VM some minutes with average activities, works fine so far. No errors/issues when using it.
2x vulnerability status:
.../spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl
.../spectre_v1: Mitigation: usercopy/swapgs barriers and __user pointer sanitization
BZ#2187931 and BZ#2187935 not verified
Seems to be working here, but I am not using special nvidia drivers on this box (using default nouveau).
Dell Precision T5610 2 x Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz (8 cores total) NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1)
no regressions noted
Seems to work fine and fixes #2191739 for me.
Runs for a few days now. Works on baremetal (non UEFI mode) AMD Ryzen5 3600, Mainboard MSI B450M Mortar Max with prop. nvidia driver (530.41.03) from rpmfusion.org (GTX980 card). Works with Gnome-Desktop (Xorg).
Works with Ryzen 5 7600X + Radeon RX6600 XT
Intel NUC6i5SYK, Intel Core i5-6260U × 4, Mesa Intel Iris Graphics 540 (SKL GT3)
working fine. Passed both default and performance test suites.
Seems to work fine on bare-metal HP Z440, AMD RX570 with UEFI. No issues to report so far and kernel regression tests both PASS.
The bootsplash is now missing but it works for me.
Still unstable. Multiple daily system lockups for no particular reason when either doing nothing but opening a folder / gnome overview. Can be forcibly be triggered opening this 3D Model in Firefox and spinning it around / moving around in Google Maps / running 3D accelerated applications.
Related bugs:
https://gitlab.freedesktop.org/drm/amd/-/issues/2548#note_1918409 https://gitlab.freedesktop.org/drm/amd/-/issues/2447#note_1918408
System
Crashlog
Sorry for duplicate message, negative Karma because unstable. Reasoning above.
While booting Kernel 6.3.3 I get this error and the whole windowmanager and applications get choppy Mai 21 22:40:50 el-ryzerino kernel: amdgpu 0000:0d:00.0: amdgpu: GPU fault detected: 147 0x0a124802 for process skypeforlinux pid 7723 thread skypeforli:cs0 pid 7741 Mai 21 22:40:50 el-ryzerino kernel: amdgpu 0000:0d:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00106D91 Mai 21 22:40:50 el-ryzerino kernel: amdgpu 0000:0d:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F090002 Mai 21 22:40:50 el-ryzerino kernel: amdgpu 0000:0d:00.0: amdgpu: VM fault (0x02, vmid 7, pasid 32776) at page 1076625, write from 'CB5' (0x43423500) (144)
sorry for wrong karma:
Works well on Ryzen 5900X + 7900 XTX
Hi
It seems this kernel corrupts XFS file systems quite frequently. It has happened three times for me on different servers. Repairing the file system didn't make the system boot.
My advice: Stay away from this if you use XFS!
@benthaase @generalprobe -> please check if this bug maybe applies to you and provide some complementary data and reports if so: https://bugzilla.redhat.com/show_bug.cgi?id=2193110 (have you had such issues already before? In earlier kernels? What are the circumstances/behaviors?)
@generalprobe Do you have also AMD Ryzen 7 ?
@runekl -> I have several XFS deployed without issues. The changelog of the kernel does not contain changes to xfs except some relations to xfstests, but not sure that this can have such impacts (?). Do you have maybe introduced some other updates along with the kernel? If not, you might file a bug, just to ensure it can be investigated
Honestly, the issue with firefox should be investigated, but it is not my primary concern, the XFS issue is the reason that I haven't pushed this to stable. If you can add anything regarding the XFS issues to https://bugzilla.redhat.com/show_bug.cgi?id=2208553 it would be appreciated. I run almost exclusively XFS with a bit of ext4 here, and I have not seen the issue locally on any machine.
For those reliably hitting the xfs problem, mind giving https://koji.fedoraproject.org/koji/taskinfo?taskID=101466330 a try when it finishes? Should be an hour or so.
Hi!
This happened on two HPE DL360gen8 and HPE DL580 gen8. All use hardware raid and Intel CPUs. Two happened after a reboot, one of them was a hard reboot. On DL580 it happened during normal operation and the machine died.
I haven't seen any issues like this before for several years with 100 fedora servers. So it seems something bad happened.
@runeki it could be entirely my fault, there was an XFS CVE, I backported a patch for it, and may have missed a dependency somewhere. Upstream stable hasn't picked it up yet. That is what the kernel I posted above is testing, I reverted that patch. Seems if this were in the upstream kernel, others would have noticed and complained as well.
That makes a lot of sense. Since it happened to me on more than half of the servers with this kernel, it's not likely it's out there. I will test again when it's pushed to testing.
I just want to point out that kernel-6.3+ affects ghc-9.2 badly causing frequent mmap segfaults.
See https://bugzilla.redhat.com/show_bug.cgi?id=2209162 (bug 2209162) and further for more details (I understand this is already fixed in ghc-9.4, but currently the default ghc in F38 is 9.2.)
(I am not going to set minus karma since I am also a Proven Tester.)
@runekl I was hoping to not push this to testing until I can get confirmation that it seems to be the cause of the issue. It is a scratch build at the moment.
@jforbes is it a bad or non-good idea to push 6.2.16 as a last „good“ release?
@jforbes I have put the scratch build on four servers just now. Will let you know how they behave.
@jforbes The issue seems to still be there. I got data corruption soon after reboot and service start on two of three servers. This post refers to xfs changes in 6.3: https://www.spinics.net/lists/linux-xfs/msg71098.html.
Thanks for letting me know. I was hoping it was my backport of the CVE fix, just because it would mean I could probably track it down easily. I am guessing this is limited to certain XFS filesystems as I run mostly XFS here, and have not seen it. Perhaps some defaults that xfsprogs used at a specific time, or filesystems created with certain kernels... We can try to track it down in bz 2208553. I will not push this rebase to stable.
@jforbes I should mention that the corrupted file systems were created with Fedora31, while ths server surviving was created with Fedora36.
@jforbes For what it is worth, my 3 depmod warnings when using dracut have vanished with your scratch kernel that I had a hunch to try although I am not using XFS.
@runekl and anyone else hitting the xfs issue, please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=2208553
@jforbes The crash is easily reproducible. We just needed to start the server, we didn't even have to start any services to make it happen. We are working on providing information based on the guidelines from the XFS maintainer. Hope it's ready in a couple of hours.
@ibims 6.2.16 should be better than 6.2.15
We have 6.3.4 as well now, not sure if it's worth giving that a go or has any relevant changes in.
6.3.4 for F37 and F38 are building now, I can't tell from the Changelog whether any XFS changes are included.
Works fine. Finally I can use amd_pstate=active with a kernel from default repo.
The XFS issue is still present in kernel 6.3.4. But it seems to be gone in the 6.4 series.
works fine on my Thinkpad P1 gen3
Hopefully fixed version of 6.3.4 building now in koji.
Cool, seems it's build
jforbes edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by jforbes.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
Boots here on a couple of machines (no xfs).
Working fine, but I'm not using xfs.
Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
Default and performance pass. HP Prodesk 400 G6 Mini, i5-10400T, CometLake-S GT2 [UHD 630]
Doesn't corrupt my XFS files systems the way 6.3.3 did.
./runtests.sh PASS with kernel-6.3.4-201.fc38.x86_64, kernel-headers-6.3.3-200.fc38.x86_64, kernel-tools-6.3.3-200.fc38.x86_64 builds within a KVM/QEMU VM (KDE spin, up to date) running on a AMD Ryzen 6850 PRO host. No third party modules (tainted = 0).
I tested the VM some minutes with average activities, works fine so far. No errors/issues when using it.
I have NOT yet tested if it works on my host (with "work" I mean if it can solve BZ#2193110; the freeze can appear on the host when any VM is running but has not yet occurred within VMs, including with cpu host-passthrough).
I will now test on the host and report in BZ#2193110 if 6.3.4 creates any changes in the behavior.
I have xfs file systems but they have not been affected by the 6.3.3 issue.
BZ#2193110 persists with 6.3.4 (tested natively on AMD Ryzen 6850 PRO host). I experienced it already twice.
Major log entries from the first freeze:
-> the desktop clock has frozen at 13:20:24
Full logs at https://bugzilla.redhat.com/show_bug.cgi?id=2193110
My host XFS file systems work fine (but I didn't experience the XFS issue on 6.3.3 as well).
With regards to my previous comment, I had to return to 6.2.15 because 6.3.4 creates too many kernel errors/freezes so that the system is not usable with this kernel.
However, it causes a new phenomenon: Firefox *¹ freezes and crashes, it cannot be re-started, and
pidof firefoxdoes no longer work then (it just idles without any return until I do CTRL+C). However, the system does not freeze, although the kernel errors are logged in the same way, but it seems to not "spread" from one core/thread to others.Again, there are massive amounts of kernel errors logged (see BZ#2193110 for the full logs). But some more indicative are maybe:
...
...
However, once I tried to shutdown, it became obvious that the running system was already in a corrupted state, and the shutdown culminated in ...
*¹ I had freezes also without Firefox running, so it is not Firefox-specific; see BZ#2193110
This update has been pushed to testing.
This update can be pushed to stable now if the maintainer wishes
petersen edited this update.
The bootsplash is still missing but it works for me.
Works on baremetal (non UEFI mode) AMD Ryzen5 3600, Mainboard MSI B450M Mortar Max with prop. nvidia driver (530.41.03) from rpmfusion.org (GTX980 card). Works with Gnome-Desktop (Xorg). But no XFS in use here.
Seems fine on a bunch of arm devices.
Works, perf and normal tests pass (BTRFS, no XFS system tested). Could not reproduce ghci bug, even on ghci-9.2.6
Tested with CPU Ryzen 7 3700 on F38 Server
[boris@ServerFedora38 ~]$ hostnamectl Static hostname: ServerFedora38 Icon name: computer-desktop Chassis: desktop 🖥️ Machine ID: b1655271bd574ee3a113398c69010646 Boot ID: 2e6ad1741cf744f88ab669ab731d8c8b Operating System: Fedora Linux 38 (Server Edition)
CPE OS Name: cpe:/o:fedoraproject:fedora:38 OS Support End: Tue 2024-05-14 OS Support Remaining: 11month 2w 1d Kernel: Linux 6.3.4-201.fc38.x86_64 Architecture: x86-64 Hardware Vendor: Micro-Star International Co., Ltd. Hardware Model: MS-7C37 Firmware Version: H.60 Firmware Date: Wed 2019-11-06 [boris@ServerFedora38 ~]$ df -Th Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev tmpfs tmpfs 7.8G 0 7.8G 0% /dev/shm tmpfs tmpfs 3.2G 2.0M 3.2G 1% /run /dev/mapper/fedora-root xfs 464G 28G 437G 6% / /dev/loop0 squashfs 128K 128K 0 100% /var/lib/snapd/snap/bare/5 /dev/loop2 squashfs 92M 92M 0 100% /var/lib/snapd/snap/gtk-common-themes/1535 /dev/loop6 squashfs 141M 141M 0 100% /var/lib/snapd/snap/skype/277 /dev/loop4 squashfs 56M 56M 0 100% /var/lib/snapd/snap/core18/2745 /dev/loop5 squashfs 54M 54M 0 100% /var/lib/snapd/snap/snapd/19122 /dev/loop3 squashfs 141M 141M 0 100% /var/lib/snapd/snap/skype/274 /dev/loop1 squashfs 165M 165M 0 100% /var/lib/snapd/snap/gnome-3-28-1804/198 tmpfs tmpfs 7.8G 16K 7.8G 1% /tmp /dev/sda2 xfs 960M 394M 567M 41% /boot /dev/sda1 vfat 599M 7.1M 592M 2% /boot/efi tmpfs tmpfs 1.6G 124K 1.6G 1% /run/user/1000
[boris@ServerFedora38 ~]$ journalctl | grep xfs Mar 26 17:37:21 ServerFedora38 systemd-fsck[654]: /usr/sbin/fsck.xfs: XFS file system. Mar 26 17:38:30 ServerFedora38 systemd-fsck[663]: /usr/sbin/fsck.xfs: XFS file system. Mar 26 17:45:08 ServerFedora38 root[2662]: 05efi: debug: /dev/sda2 is xfs partition: exiting Mar 26 17:45:10 ServerFedora38 root[3425]: 40grub2: debug: parsing: insmod xfs Mar 26 17:45:10 ServerFedora38 root[3425]: 40grub2: debug: parsing: insmod xfs Mar 26 17:45:45 ServerFedora38 dracut[4454]: drwxr-xr-x 2 root root 0 Mar 14 03:00 usr/lib/modules/6.2.8-300.fc38.x86_64/kernel/fs/xfs Mar 26 17:45:45 ServerFedora38 dracut[4454]: -rw-r--r-- 1 root root 720148 Mar 14 03:00 usr/lib/modules/6.2.8-300.fc38.x86_64/kernel/fs/xfs/xfs.ko.xz Mar 26 17:45:45 ServerFedora38 dracut[4454]: -rwxr-xr-x 1 root root 2598 Feb 8 03:00 usr/sbin/fsck.xfs Mar 26 17:45:45 ServerFedora38 dracut[4454]: -rwxr-xr-x 1 root root 715368 Feb 8 03:00 usr/sbin/xfs_db Mar 26 17:45:45 ServerFedora38 dracut[4454]: -rwxr-xr-x 1 root root 786 Feb 8 03:00 usr/sbin/xfs_metadump Mar 26 17:45:45 ServerFedora38 dracut[4454]: -rwxr-xr-x 1 root root 701648 Feb 8 03:00 usr/sbin/xfs_repair Mar 26 17:47:24 ServerFedora38 root[15044]: 05efi: debug: /dev/sda2 is xfs partition: exiting Mar 26 17:47:26 ServerFedora38 root[15804]: 40grub2: debug: parsing: insmod xfs Mar 26 17:47:26 ServerFedora38 root[15804]: 40grub2: debug: parsing: insmod xfs Mar 26 17:50:42 ServerFedora38 systemd-fsck[657]: /usr/sbin/fsck.xfs: XFS file system. Mar 26 18:14:53 ServerFedora38 systemd-fsck[663]: /usr/sbin/fsck.xfs: XFS file system. Apr 08 18:18:33 ServerFedora38 systemd-fsck[664]: /usr/sbin/fsck.xfs: XFS file system. Apr 08 18:39:37 ServerFedora38 root[6806]: 05efi: debug: /dev/sda2 is xfs partition: exiting Apr 08 18:39:39 ServerFedora38 root[7565]: 40grub2: debug: parsing: insmod xfs Apr 08 18:39:39 ServerFedora38 root[7565]: 40grub2: debug: parsing: insmod xfs Apr 08 18:39:39 ServerFedora38 root[7565]: 40grub2: debug: parsing: insmod xfs Apr 08 18:40:17 ServerFedora38 dracut[8610]: drwxr-xr-x 2 root root 0 Mar 14 03:00 usr/lib/modules/6.2.10-300.fc38.x86_64/kernel/fs/xfs Apr 08 18:40:17 ServerFedora38 dracut[8610]: -rw-r--r-- 1 root root 723396 Mar 14 03:00 usr/lib/modules/6.2.10-300.fc38.x86_64/kernel/fs/xfs/xfs.ko.xz Apr 08 18:40:18 ServerFedora38 dracut[8610]: -rwxr-xr-x 1 root root 2598 Feb 8 03:00 usr/sbin/fsck.xfs Apr 08 18:40:18 ServerFedora38 dracut[8610]: -rwxr-xr-x 1 root root 715368 Feb 8 03:00 usr/sbin/xfs_db Apr 08 18:40:18 ServerFedora38 dracut[8610]: -rwxr-xr-x 1 root root 786 Feb 8 03:00 usr/sbin/xfs_metadump Apr 08 18:40:18 ServerFedora38 dracut[8610]: -rwxr-xr-x 1 root root 701648 Feb 8 03:00 usr/sbin/xfs_repair Apr 08 18:42:41 ServerFedora38 root[20386]: 05efi: debug: /dev/sda2 is xfs partition: exiting Apr 08 18:42:42 ServerFedora38 root[21146]: 40grub2: debug: parsing: insmod xfs Apr 08 18:42:42 ServerFedora38 root[21146]: 40grub2: debug: parsing: insmod xfs Apr 08 18:42:42 ServerFedora38 root[21146]: 40grub2: debug: parsing: insmod xfs Apr 08 18:47:14 ServerFedora38 systemd-fsck[662]: /usr/sbin/fsck.xfs: XFS file system. May 09 18:29:03 ServerFedora38 systemd-fsck[665]: /usr/sbin/fsck.xfs: XFS file system. May 09 18:41:30 ServerFedora38 root[7285]: 05efi: debug: /dev/sda2 is xfs partition: exiting May 09 18:41:31 ServerFedora38 root[8044]: 40grub2: debug: parsing: insmod xfs May 09 18:41:31 ServerFedora38 root[8044]: 40grub2: debug: parsing: insmod xfs May 09 18:41:31 ServerFedora38 root[8044]: 40grub2: debug: parsing: insmod xfs May 09 18:41:31 ServerFedora38 root[8044]: 40grub2: debug: parsing: insmod xfs May 09 18:42:06 ServerFedora38 dracut[9104]: drwxr-xr-x 2 root root 0 Apr 27 03:00 usr/lib/modules/6.2.14-300.fc38.x86_64/kernel/fs/xfs May 09 18:42:06 ServerFedora38 dracut[9104]: -rw-r--r-- 1 root root 719884 Apr 27 03:00 usr/lib/modules/6.2.14-300.fc38.x86_64/kernel/fs/xfs/xfs.ko.xz . . . . . [boris@ServerFedora38 ~]$ dmesg| grep "XFS" [ 5.222382] SGI XFS with ACLs, security attributes, realtime, scrub, quota, no debug enabled [ 5.224106] XFS (dm-0): Mounting V5 Filesystem 70c56ddb-b881-4296-a73b-0e385cbe364e [ 5.383157] XFS (dm-0): Ending clean mount [ 16.201900] XFS (sda2): Mounting V5 Filesystem bed3367d-4aa0-4afc-99d0-50edc440fbbe [ 18.136884] XFS (sda2): Ending clean mount
Works with my 3 x86_64 machines (ext4 only). Default and Performance regression tests passed.
I apologize for posting hardly readable testing results, but preview option didn't work for me. Possibly it happened due to bunch of rows in post.
works for me, no issues noted
6.3.4 seems to work fine on bare-metal HP EliteBook 840 G6 with UEFI and SecureBoot. No issues to report so far and kernel regression tests both PASS.
This update has been submitted for stable by jforbes.
Intel NUC6i5SYK, Intel Core i5-6260U × 4, Mesa Intel Iris Graphics 540 (SKL GT3)
Passed both default and performance test suites.
This update's test gating status has been changed to 'failed'.
FEDORA-2023-514965dd8a ejected from the push because 'Required tests did not pass on this update'
This update's test gating status has been changed to 'passed'.
If 6.3.5 gets into testing, what happens to 6.3.4, now that it's not going to stable? Is it kicked out of the repo?
Seems like testing failed and might need a manual push.
This update has been submitted for stable by kevin.
This update has been pushed to stable.
This kernel will not boot. After updating today, I selected the new kernel in Grub, and it stuck at "Loading Linux 6.3.4-201.fc38.x86_64" for over 30 minutes, necessitating a hard restart. It never reached the ramdisk. I used grub to rollback to the previous update, and it worked fine. I will try to update again after a backup, but I am worried this might brick someone if they don't have backups. I am running a Framework Laptop (intel 12th-gen i5), and I am dual-booted with Windows 11.
Something comparable to what @adonnen posted was also posted by another user on Ask.Fedora:
https://discussion.fedoraproject.org/t/fedora-hangs-on-boot-after-upgrading-to-kernel-6-3-4/83605
It may be worth mentioning that it appears kernel-6.3.x brings IBT Protection to Fedora, in that it is now turned on by default. For me this killed VirtualBox as a host, but I think some custom drivers can cause problems also. For me the symptom was complete freeze when I tried to launch a VM. Solution was to add "ibt=off" to the kernel boot line. This impacts Intel 11th gen (Tigerlake) and later CPUs I believe. If you guys experiencing boot hangs are running special drivers, may be worth giving "ibt=off" a try.
Please, check with https://forums.virtualbox.org/viewtopic.php?t=108948 . Quoting mentioned thread "This has been the default config as of kernel 6.2.x."
@boris2023 that is referring to vanilla kernels from kernel.org. IBT wasn't on in Fedora during 6.2.
getting error "CIFS: VFS: cifs_mount failed w/return code = -5" since the last two kernel updates. older kernels still work with this v1 share...