This has been happening to my 11th Gen (Gen 1, batch 1) for months. I’m a fairly low-speed, high-drag user running pop!OS, and I see it only in between sleeps. The only way I clear the error is with a reboot. I have not been bothered enough to do any real troubleshooting, but the more days between reboots, the more likely I will see it.
FWIW…
I’ve had the issue yesterday, maybe I should’ve posted here instead in the other thread. Now I’ve rebooted, so it’s gone away, but the dmesg should still be of interest:
I’ve also been seeing this issue recently, on an 11th gen running Ubuntu 22.10.
I’m pretty sure this never happened when I first got the laptop a year ago. I believe I’ve first seen this happen about a month ago, maybe a bit more. Looking back, it could have been a BIOS update (I updated to 3.17 in january, though I think I first saw the issue one or two months after that), of maybe an Ubuntu upgrade (I upgraded from 21.something to 22.10 one or two months ago).
As for ectool - I have a version compiled and installed that I have been using to manually check the ec console every now and then, but I’m not using ectool periodically for anything, so that cannot be the cause for me.
I’m also seeing the packet too long errors (and saw bad checksum once) in dmesg.
As for when this happens - I have the feeling it is related to suspending or usb-c docking/undocking, but I also realize there is a bias there - when I’m docked, I use a different keyboard, so it might very well be broken already when I dock, but I won’t notice until I undock, suspend my laptop and then notice when I unsuspend again when I’m on the road.
There is definitely something going on regarding uptime. I recently rebooted after ~70 days. Before doing that, I reinstated my ectool polling, and the problem easily re-occurred in under 10 mins. However, after rebooting, with the same setup, I’m unable to make the problem re-occur, even after running the same polling for several hours.
The main difference that I’m aware of (apart from how long since the system had been rebooted) is a slightly more recent Ubuntu 22.04 kernel: I’m now on 6.0.0-1014-oem, whereas before it was 6.0.0-1010-oem. I guess another difference is that the system is generally more lightly loaded than before (less processes, cpu, and memory currently in use). Over time I’ll see if the problem eventually reoccurs on this slightly more recent kernel version.
This also started happened to me on Ubuntu 22.10 shortly after updating firmware from 0.0.3.4 to 0.0.3.17. I’ve downgraded to 0.0.3.10 and will report back if this seems to resolve the issue.
Everything seemed to be going well with the firmware downgrade to 0.0.3.10, but a few days ago the fn key died again and I had to reboot to bring it back 
I’m back on 0.0.3.17 again and seeing the same behavior occasionally.
As this is happening on Ubuntu as well, anything interesting happen before this took place? Suspend, repeated lid opening and closing? I’ve been actively tracking an 11th gen issue that I have not been able to replicate, however if related, I have a workaround that may stop the behavior.
Let me know if suspend was done previous to this happening.
Yes, for me on Ubuntu, this is always correlated with a resume from a suspend. It doesn’t happen every time, but it will generally happen at least once every 5-7 days (and then I reboot to fix it). Prior to this starting (potentially with the Ubuntu 22.10 upgrade?), I had gone a year without any problems whatsoever.
For me, I can confirm that it exclusively happens after resuming from suspend.
If I boot normally it doesn’t happen. Only after having put the machines I sleep and waking it up again it’ll happen soon after.
I don’t believe it’s an immediate effect, but I haven’t actually looked into it
I also see this problem sporadically after resuming from a suspend. Suspending again, and re-resuming often fixes it. This is on Ubuntu 22.04.2 LTS.
For Ubuntu 22.04 and up, please try this:
echo "blacklist cros_ec_lpcs" | sudo tee -a /etc/modprobe.d/no_cros_ec.conf
Reboot.
Then report back. It blacklists this: LKML: "Dustin L. Howett": [PATCH 0/2] platform/chrome: Add support for the Framework Laptop Won’t affect anything in a negative way, but it going to likely solve the issue for you on 11th gen.
By the way, I just want to precise that this happens on 12th gen.
I didn’t know that this thread was 11th gen only:
I switched from 11th-gen to 12th-gen some time last year, and the issue still happens from time to time.
Looks to be different. 11th gen users were seeing this happen with some suspend/resume activity and it looks like your seeing this with Fn lock after unplugging a TB dock.
@Matt_Hartley thanks for the tip about blacklisting the cros_ec_lpcs module, I’m trying that now. It still seems to get loaded even with the modprobe.d file:
chris@vega:~ ☸ home in 112ms @ 20:34:32 $ cat /etc/modprobe.d/no_cros_ec.conf
# Blacklists a kernel module that causes the Fn key to stop working
# https://community.frame.work/t/tracking-fn-key-stops-working-on-popos-after-a-while/21208/32
blacklist cros_ec_lpcs
chris@vega:~ ☸ home in 109ms @ 20:35:42 $ lsmod | grep cros_
cros_usbpd_charger 20480 0
cros_usbpd_logger 20480 0
cros_usbpd_notify 20480 1 cros_usbpd_charger
cros_ec_debugfs 16384 0
cros_ec_chardev 16384 0
cros_ec_sysfs 16384 0
cros_ec_dev 16384 0
cros_ec_lpcs 16384 0
cros_ec 20480 1 cros_ec_lpcs
Do you have any advice on a stronger way to blacklist it?
No not always, I had it the last week-end, and it was not after touching the docks nor the ports (I think… 90% sure…).
Next time it happens, I’ll make sure to memo it and report back here.
Ah update on the modprobe.d solution: after adding a modprobe configuration file, you also have to run sudo update-initramfs -u to make it take effect on the next boot. I’m now running without those cros_ modules and will report back after a week or so.
I’m experiencing this error on 11th and 12th gen. I created this topic when I was already at 12th as far as I remember.
So far I didn’t find a solution as well, however the error happens not as often as before within the last few weeks.
Was suspend involved and which distro/desktop? I have to date, only seen this on 11th gen and even at that have not reproduced the issue.
Ok so now I just had the problem (on the 12-th gen). It was not after manipulating the TB dock.
The good news: I discovered that I just had to do a s2ram and then when waking it back up the problem was gone! So, no more need to do a full reboot! (and no need to loose the state of the laptop, no more need to re-open all the files etc.)
I’m having the same problem with my 12th gen on Ubuntu 23.04.
It only happens to me after waking from sleep, and only every 5th time or so. Putting it back to sleep does not fix it for me, only a reboot fixes it.
The Fn functions stop working, only F1-F12 works, no matter if a hold down the Fn key or not. Fn lock also doesn’t work. Fn+space bar for the keyboard backlight also stops working. The keyboard backlight stays on the level it was before going to sleep.
I usually have nothing connected to the laptop except for the charger when putting it to sleep by closing the lid. I have two USB-C modules, one USB-A and one HDMI, if that makes any difference.
I got my Framework in March '23 and it’s been running Ubuntu from the start. I don’t think I’ve noticed this problem in the beginning. It seems to me it only started recently.