I’m having trouble identifying the source of a repeating crash-ish issue, and hoping I can collab with other Bluefin users having the same problem (or determine that it’s just me).
Here’s the symptoms:
Every 6 to 12 days, my mouse and keyboard will slow waaaaaay down, to like 1% speed. This does not go away on its own, and only a power-cycle reboot seems to fix it.
This problem could be happening on almost any layer of the stack: graphics card, usb bus, memory, linux kernel, Gnome, even flatpak. At this point I have no idea.
regular memory saturation by a desktop app; killing all of my desktop apps didn’t restore functionality
dock; while I do use a dock sometimes, this issue has also happened while unplugged, on the laptop’s built-in keyboard and mouse
Some things I do that might be unusual:
lots of video calls, using three different tools
plugging/unplugging from a dock daily
not rebooting until one of these lockups happens
I haven’t been able to do a lot of diagnositics because that’s difficult without a working mouse/keyboard, and a lot vanishes after a cold reboot. And since the lockups are so far apart, I can’t leave any resource-intensive monitoring SW running in hopes of capturing them.
Let’s keep the dock out of the equation as docks always add a layer of troubleshooting. Best to figure this out on the main unit itself. Could be ticket worthy.
On the hardware front, RAM purchased from Framework or elsewhere?
These are USB-A devices, USB-A dongle devices or Bluetooth? Wait, this happens with built in touchpad and keyboard as well? Okay, continue below.
Using Framework provided power adapter or something else? Happens when disconnected from power, when attached or both?
Can you grab logs. If you remember the time periods: journalctl --since "2024-05-16 08:00:00" --until "2024-05-16 10:00:00"
(Adjusting times and days, above is an example)
or after it happens and you reboot. journalctl -b -1 -p err -xe
and if nothing useful appears, get more verbose logs from previous boot: journalctl -b -1
when I’m using the dock, it’s Port 1, with a USB-C in it, connected to a no-name USB hub, which then connects to the mouse and keyboard using USB-A. However, when this happens it also affects the built-in touchpad and keyboard, and disconnecting from the dock doesn’t affect the problem. I have also had the lockup happen when I wasn’t using the dock at all (while on a trip).
RAM came from Framework (32GB, in case it matters)
Power adapter is usually non-framework (65W or 85W generic USB-C power). Has also happened when not connected to power, and when connected to it. I DO have some voltage fluctuation problems in my house, but this lockup has also happened when I was in a hotel.
I’ll collect journal next time it happens (after the reboot). One of the troubleshooting problems is that, of course, it generally happens at really inconvenient times when I can’t stop to collect a bunch of diagnostics, like 15 minutes before I’m giving a talk.
So, update, just had another lockup and … it’s looking like a hardware problem, given the total lack of any journal messages around the failure. BUT, there are suspicious other things, so it’s worth checking.
First, my journal is chock-full of this error repeating endlessly:
Jun 12 13:09:54 fedora systemd[1]: displaylink.service: Control process exited, code=exited, stat>
Jun 12 13:09:54 fedora systemd[1]: displaylink.service: Failed with result 'exit-code'.
Jun 12 13:09:54 fedora systemd[1]: Failed to start displaylink.service - DisplayLink Manager Serv>
Jun 12 13:09:54 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=sy>
Jun 12 13:10:00 fedora systemd[1]: displaylink.service: Scheduled restart job, restart counter is>
Jun 12 13:10:00 fedora systemd[1]: Starting displaylink.service - DisplayLink Manager Service...
Jun 12 13:10:00 fedora modprobe[644883]: modprobe: ERROR: could not insert 'evdi': Key was reject>
Jun 12 13:10:00 fedora systemd[1]: displaylink.service: Control process exited, code=exited, stat>
Jun 12 13:10:00 fedora systemd[1]: displaylink.service: Failed with result 'exit-code'.
Jun 12 13:10:00 fedora kernel: Loading of module with unavailable key is rejected
░░ Subject: A start job for unit displaylink.service has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit displaylink.service has finished with a failure.
░░
░░ The job identifier is 14411868 and the job result is failed.
The above error sequence happens all the time, 24/7, when my laptop is working fine. I’m sharing it here because maybe it’s related?
There are no error messages (or messages of any kind) associated with the timing of lockup of the keyboard and mouse. I see no errors from the time when the inputs locked up; as far as Linux was concerned, it seems like everything was fine.
Note that during this whole process I had music playing over USB speakers, which continued to play while I was unable to use keyboard or mouse.
Unplugging the USBC dock and using the built-in keyboard.
Unplugging the USBA hub from the dock.
No combination of unplugging things helped; a reboot was required. However, when I unplugged and plugged devices back in, the journal shows the normal set of messages. So Linux could definitely detect the usb devices and was connecting to them.
This suggests that maybe it’s a problem with the video output; like, maybe the mouse/keyboard are working normally and I just can’t see them because the screen is frozen/very slow?
Talked to kyle in chat, looks like those errors are due to secure boot. Do you recall if you enrolled our key during installation? If not, it’s a ujust command:
That should at a minimum remove that set of errors.
Finally have a moment to review this. The standout here is the dock. I have seen docks doing well until they do not.
My own FW16 config:
I use an Anker USB-C dock on port 1 myself. I run a USB-A mouse dongle, Brio webcam and a mechnical keyboard from it.
External displays are using one DP expansion card, and the other one is a HDMI expansion card.
32GB of RAM (Framework branding).
What I’d like to try, on a hunch:
Plug in the keyboard directly into an expansion card (USB-A or C, whatever card you have) - no dock. If the keyboard is USB-A, do you have access to a USB-A expansion card in place of the dock for the external keyboard?
We’ve seen some docks do really poorly with Framework laptops, I want to eliminate this from the equation.
If you are piping out video to external displays in addition to USB duties from a dock, this is going to likely be a bad time.
Let me know how the direct connection goes.
If it does the same thing even without the dock, then at this that point let’s get you into a ticket - have the agents send it to me directly.
Oh, and important note: in my case, while using the dock, my external monitor is through the dock, not directly connected.
I will have an upcoming opportunity to be without a dock for 5 days due to work travel. However, this problem only occurs once every 6-12 days, so I can’t verify anything by it not happening during the trip – only if it does happen.
Okay, understood. If you find it happens, please make a written note of the time and day it occurs according to the time settings on your laptop (if traveling times zones can be a thing).
With this, we can then dig into the journal for this selected time stamp and see if we can root out what is happening. I suspect this is going to be a ticket (just link this and ask to have it escalated to me, Matt).
I like this approach as it’s helpful to capture what is happening when we know the time it happened, but less about ‘what’ is happening.
Update: Was on my laptop without a dock for 5 days of travel. The freeze did not occur. Unfortunately, that doesn’t prove anything at this stage; I’m still within the 6-14 day window. It would only have been useful if a freeze did occur.
This is happening to me as well, new Framework 16 using integrated GPU, twice over the past couple of days, seems to happen when the system is under heavy load (compiling or just now playing a game). Mouse and keyboard become extremely slow and jumpy, only a reboot appears to clear it. Nothing plugged in at all other than power.