Fedora 39 on the Framework Laptop 13

Believe it’s here somewhere.

lsmod

lsmod | grep cros_ec_lpcs
cros_ec_lpcs           16384  0
cros_ec                20480  1 cros_ec_lpcs

dmesg

sudo dmesg | grep cros_ec_lpcs

[    1.041101] cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected

Modinfo

filename:       /lib/modules/6.1.0-1025-oem/kernel/drivers/platform/chrome/cros_ec_lpcs.ko
description:    ChromeOS EC LPC driver
license:        GPL
srcversion:     907D9237F5875F0305F0B2C
alias:          dmi*:svn*Framework*:pn*Laptop*:
alias:          dmi*:svn*GOOGLE*:pn*Glimmer*:
alias:          dmi*:svn*Acer*:pn*Peppy*:
alias:          dmi*:svn*GOOGLE*:pn*Samus*:
alias:          dmi*:svn*GOOGLE*:pn*Link*:
alias:          dmi*:bvn*coreboot*:svn*GOOGLE*:
alias:          dmi*:bvn*coreboot*:bvr*Google_*:
alias:          acpi*:GOOG0004:*
depends:        cros_ec
retpoline:      Y
intree:         Y
name:           cros_ec_lpcs
vermagic:       6.1.0-1025-oem SMP preempt mod_unload modversions 
sig_id:         PKCS#7
signer:         Build time autogenerated kernel key
sig_key:        3B:2B:98:A0:E5:73:1E:49:D6:FF:BA:80:A0:EE:55:23:4D:E6:D7:C7
sig_hashalgo:   sha512
signature:      1B:F5:3B:BF:53:C7:17:6B:23:7A:A6:CA:89:99:E9:6A:76:EE:BA:82:
		BD:6E:94:B3:7C:60:39:41:88:FF:46:54:24:16:35:0C:B4:73:EF:5B:
		74:88:94:9B:97:FA:26:03:8C:EF:30:74:F0:94:E5:4C:75:4D:1B:BC:
		12:EF:39:A0:C7:6D:E8:97:64:4E:37:3B:9C:BD:FE:5F:ED:E4:7C:FC:
		9F:C6:53:EE:96:7B:7C:33:66:CE:2F:AC:D9:4E:C6:82:8B:48:C8:43:
		CD:36:BC:AA:4B:4D:7B:A1:8C:B2:5A:4F:FD:5C:8D:B3:76:41:3C:13:
		1F:34:A7:E1:EE:27:22:CE:BB:37:37:AD:3C:B1:09:B9:78:F4:EF:E5:
		71:C3:C4:DE:EA:D2:E7:CD:CD:B9:C2:4B:75:A4:5F:24:FA:12:34:21:
		4A:AA:30:7F:21:23:AA:D7:EB:7E:A0:F9:04:8C:E4:F8:F7:DB:0D:E9:
		C8:2C:5E:AF:D6:E3:75:38:C3:E5:FB:86:61:F5:AF:87:D6:93:E5:EF:
		0A:88:10:FC:A1:37:14:38:06:4B:0A:73:8D:53:C5:0D:10:44:C4:E6:
		03:57:A8:4F:7B:C5:8C:5C:A2:02:07:5C:40:E7:5E:B0:48:17:0C:A0:
		92:E2:55:BA:23:71:66:77:40:C5:3B:D0:FF:F8:D9:38:B2:34:AC:12:
		B5:45:30:F1:31:B5:40:8D:74:20:4C:0F:EA:AA:81:33:35:08:83:10:
		FE:28:B1:57:09:EF:98:93:3A:0A:D3:DE:60:F6:66:2D:8A:8B:9B:7F:
		66:54:16:B1:00:1F:DB:16:0C:C1:D3:FD:1C:54:FF:ED:61:85:93:26:
		C0:7E:AD:68:42:42:33:90:C3:7A:AA:95:07:30:1A:D3:A7:7C:72:0C:
		E8:8F:3D:C9:87:B5:BF:ED:3C:22:EF:20:8C:C2:73:15:99:9F:4F:12:
		41:E7:56:AD:86:66:4E:0E:BE:C4:E8:95:33:D6:97:7F:2E:83:B3:1D:
		E1:0E:D2:E1:62:63:24:C0:B0:3E:34:AA:FF:F8:BC:5E:92:E6:16:5D:
		04:EC:65:8A:71:92:4E:F5:0C:71:00:19:7B:0B:36:7D:9A:D6:71:6A:
		48:7B:CF:E3:BE:3B:66:D2:2F:D9:EC:6B:05:C2:B6:5E:3D:73:6A:4F:
		FE:52:C7:1D:26:7E:6E:D9:F1:A7:79:46:3C:60:21:A2:88:31:84:EB:
		17:38:7E:42:04:AE:6A:DC:4E:E7:D3:24:62:F4:1C:4D:B8:70:4A:E8:
		F7:4C:0A:B5:17:E2:04:52:29:8D:73:B9:A0:0A:A5:CF:4D:8C:A8:9F:
		3C:3D:5D:33:C8:72:A0:C1:8D:94:8F:35

Yup it’s not loading there; so isn’t in that kernel either

I’ve got a 6.7-rc1 with patch applied you should see:

[    8.837614] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000003
[    8.846694] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered

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


This is correct. Framework does not use the embedded controller to mediate USB PD directly. Those messages are spurious.

1 Like

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.

1 Like

That and scatter gather being broken in amdgpu for Phoenix

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.

1 Like

I have a question regarding kernel updates. Currently, I have 3 kernels installed:

kernel.x86_64                                        6.5.6-300.fc39                      @anaconda              
kernel.x86_64                                        6.5.11-300.fc39                     @updates               
kernel.x86_64                                        6.5.12-300.fc39                     @updates   

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?

run:

sudo dnf distro-sync

followed by

sudo grub2-mkconfig -o "$(readlink -e /etc/grub2.conf)"

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.

1 Like

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
GRUB_SAVEDEFAULT=true

Should be present in your /etc/default/grub; which will mean the last selected entry is chosen.

2 Likes

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!

1 Like

Same here; I just updated kernel to 6.6.2-201.fc39 which just hit testing, so now I have these installed:

6.5.11-300.fc39
6.5.12-300.fc39
6.6.2-201.fc39

grub was still defaulting to 6.5.12-300.fc39 on reboot (and when that was installed to 6.5.11-300.fc39 and so on).

$ cat /etc/default/grub 
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_SAVEDEFAULT=true
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.luks.uuid=... rhgb quiet amdgpu.sg_display=0"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

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.

1 Like

What is the output of grubby --default-index ?

and what is the output of : sudo ls /boot | grep vmlinuz

?

Reference: Working with the GRUB 2 Boot Loader :: Fedora Docs

IIRC scripts just enumerate based on the numerical versioning of vmlinuz entiries.

Grubby is the supported tool in Fedora for manipulating things (although I kinda give it a wide berth because I’ve had issues with it in the past).

The config for wether new kernel-pkgs should become the default is at /etc/sysconfig/kernel

Hmm, that file didn’t exist. I created it with contents as shown in the doc you linked:

# UPDATEDEFAULT specifies if new-kernel-pkg should make
# new kernels the default
UPDATEDEFAULT=yes

# DEFAULTKERNEL specifies the default kernel package type
DEFAULTKERNEL=kernel-core

I can’t say I remember having to manually create that config file before in the 10 or so years I’ve used Fedora, is it a known recent change?

2 Likes

That’s the same I noticed in my first posts in this topic: /etc/sysconfig/kernel is completely missing. Have also manually created it now; let’s see if that resolves the issue.

Can confirm that restoring the /etc/sysconfig/kernel file as above resolves the issue of the default kernel not updating after upgrade. :slight_smile:

1 Like

Odd this happened, delighted it’s resolved.