So on rawhide I don’t get the stuttering; but I do get a lot of these familar messages (I see these on my rdna3 5950x quite often with various combinations of kernel/mesa/firefox/chrome)
MediaPD~oder #3[29662]: segfault at 60 ip 00007ff578b4901f sp 00007ff59f9fcd40 error 4 in libLLVM-17.so[7ff576949000+384c000] likely on CPU 9 (core 4, socket 0)
It’s something to do with the Mediapipeline decoder bits and it’s interaction with the rest of the system. I’ve never been able to root cause it (I thought it was my 5950x being PBO2 clocked/RAM/Mobo - but it’s definately software related rather than hardware after bisecting a heap of those things previously on my workstation.
Also the ec_cros patches that were added sometime back to mainline for the Intel FW do not work for the AMD EC controller and there needs patches/documentaiton for the ec controller to be made available and added to a patchset. There is nothing in any of the various kernel trees i’ve diff’d that deal with the EC controller for the AMD. This includes the various ec_tool efi and userspace libs throwing invalid checksums when querying the AMD ec.
Can someone running the OEM Kernel that people mention for ubuntu let me know if ec_cros_lpc loads ; and if so where the source tree is so I can see what if any patches were made for the amd ec controller in that kernel.
And you should then get errors from the PD.auto probe (which needs a fixup which doesn’t currently exist). Am not sure what needs to happen in the auto probe ; there seems to be some discussion/patches which may be related to how auto probing happens. But this likely needs flagging up the poll to people more familar than I. Perhaps @DHowett ? I see a thread for the Intel Framework which mentions similar output - so this may just be overly verbose output that shouldn’t appear in dmesg.
[ 8.984471] cros-usbpd-charger cros-usbpd-charger.3.auto: No USB PD charging ports found
[ 8.985733] cros-usbpd-charger cros-usbpd-charger.3.auto: Unexpected number of charge port count
[ 8.985737] cros-usbpd-charger cros-usbpd-charger.3.auto: Failing probe (err:0xffffffb9)
[ 8.985739] cros-usbpd-charger: probe of cros-usbpd-charger.3.auto failed with error -71
The persistent probe and ACK failures around ucsi_acpi
and the ambient light sensor, and some designware i2c errors (which appear mostly benign and related to state saving where the last touch position was during resum/cold boot). Are the last remaining bits that appear broken on the amd framework.
In the thread about the RTC advancing/doubling while in s2idle, I read between the lines that addressing this EC driver issue would also address this problem by removing a race condition when reading the RTC on resume. Am I assuming this correctly?
I still get the warningwith the ec patch applied. But I didn’t see bad behaviour with 6.7 rawhide kernels prior to addingit, sohave it added as a precaution.
After updating with dnf which installed a new kernel, I would expect the new kernel to be the default in grub, however, 6.5.6 remains the default. Reading the docs, it looks like it should automatically be updated. On further investigation, the /etc/sysconfig/kernel is missing from my system. Is this a bug in F39? Would adding the file solve the issue or is there something else going on?
Fedora retains the last 2 kernels by default; but the scripts should place the most recent version found in /boot as the highest priority. Although you can tweak this in various ways.
Thanks for your response. The first command just gave me
Nothing to do.
Complete!
Regenerating the grub config also doesn’t do anything. When checking out the grub menu on boot it does display (as it did before) the 3 currently installed kernels, but by default the oldest one is still selected. How can I make grub to automatically set the latest kernel as default?
GRUB_DEFAULT=saved is indeed in /etc/default/grub. The line GRUB_SAVEDEFAULT=true is not. As far as I understand, this does not automatically change the default kernel to the newest version after installation, correct? That is the behaviour I would expect, based on earlier experience with distros as openSUSE and Debian. Are you saying that this is not the expected behavior on Fedora?
SAVEFEAULT is the value that will retain the last used. It is indeed not set by default so you will need to add if if you want that behaviour.
OOTB behaviour should be to select the most recently installed kernel based on the kernel package script trigger when installed from dnf. My guess is this failed or didn’t run or you downgraded a kernel at somepoint.
Right, that confirms that my FW is not showing expected behaviour. It’s a fresh F39 install on a new AMD Framework, so I don’t know why it doesn’t work. I’ll pay more attention to the log on the next kernel update to see if there’s anything going wrong. For now I’ll just set it manually.
Thanks for the help!
This being my first clean Fedora install in ~ 2 years, I can’t remember if there’s some other step I need to take to bring back the “default to newly installed kernel” behavior.