I have been using Fedora for a long time now on my Framework 13 12th gen for a long time now.
I have it connected to a Lenovo Thunderbolt 3 Gen 2 dock connected to an external 49" Samsung display via DisplayPort. Occasionally the monitor will go completely black. The dock is connected, keyboard / mouse still respond, but the external monitor is black.
Disconnecting and reconnecting the Thunderbolt cable will resolve it, and switching the DisplayPort cable to the other port will fix it one time. I have checked kernel logs and full journal logs, and the OS doesn’t appear to be aware of the drop.
For now, I have connected the DisplayPort directly to the Framework, and it seems to resolve the issue, but I wanted to see if anyone else is experiencing these issues.
So, update here. I thought the direct connection to the DisplayPort resolved it. It did not.
I went down the path of thinking it was hardware acceleration as well, and turned that off in the applications that allow me to, no luck there either.
Revered to kernel 5.15 and went to a vanilla 5.5 kernel build as well to make sure Fedora wasn’t doing something funky, but that didn’t make a difference. I am on a new dock, and an even newer kernel, and today I have run with the machine being able to recover, but the screen randomly goes dark for about 10 seconds.
Thanks for following up @Matt_Hartley , to answer your questions.
Is TLP being used? This can contribute to issues with some devices.
No, I actually removed it as part of my test, and booted a clean OS from a thumbdrive as well to test.
Is this a powered dock?
Yes, I was using a Lenovo Thunder Gen 2 dock. I now have the CalDigit TB4 dock, but again I removed the dock from the equation and just hooked up DisplayPort and HDMI (both had the same issue) to the monitor via the Framework dongle directly
Does it go off during inactivity or when actively using the laptop?
While I am actively using it
Since it got better today, I may try connecting directly again later and seeing if an update is helping, or if the new dock is helping. It’s just strange, because the OS doesn’t indicate any kind of failure that I can see.
So, I am back today from taking some needed “away from tech” time. I am starting to wonder, “I hope not” that this may be hardware related.
With the new dock, everything connected to the thunderbolt port loses power briefly, and everything disconnects, power drops and a few seconds later comes back.
I still don’t see anything in journal, devices just start to disconnect and then reconnect fully about a second later.
Aug 14 06:37:43 framework01 gnome-shell[4471]: JS ERROR: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.Failed: error occurred in AboutToShow
_promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:453:45
### Promise created here: ###
sendAboutToShow@/home/chrisb/.local/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com/dbusMenu.js:501:48
sendAboutToShow@/home/chrisb/.local/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com/dbusMenu.js:197:22
_onMenuOpened@/home/chrisb/.local/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com/dbusMenu.js:935:28
_callHandlers@resource:///org/gnome/gjs/modules/core/_signals.js:130:42
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:119:10
open@resource:///org/gnome/shell/ui/popupMenu.js:932:14
toggle@resource:///org/gnome/shell/ui/popupMenu.js:805:18
vfunc_button_press_event@/home/chrisb/.local/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com/indicatorStatusIcon.js:425:27
Aug 14 06:37:53 framework01 com.bitwarden.desktop.desktop[5259]: 06:37:53.224 › Error: No password found
Aug 14 06:37:57 framework01 kernel: thunderbolt 0-0:3.1: retimer disconnected
Aug 14 06:37:57 framework01 kernel: usb 3-3: USB disconnect, device number 2
Aug 14 06:37:57 framework01 kernel: usb 3-3.1: USB disconnect, device number 4
Aug 14 06:37:57 framework01 kernel: usb 3-3.1.1: USB disconnect, device number 6
Aug 14 06:37:57 framework01 kernel: usb 3-3.1.1.2: USB disconnect, device number 9
Aug 14 06:37:57 framework01 kernel: usb 3-3.1.1.2.3: USB disconnect, device number 12
Aug 14 06:37:57 framework01 kernel: usb 2-2: USB disconnect, device number 2
Aug 14 06:37:57 framework01 kernel: usb 2-2.4: USB disconnect, device number 3
Aug 14 06:37:57 framework01 kernel: usb 2-2.4.1: USB disconnect, device number 4
Aug 14 06:37:57 framework01 kernel: usb 2-2.4.1.2: USB disconnect, device number 6
Aug 14 06:37:57 framework01 kernel: usb 2-2.4.1.2.4: USB disconnect, device number 9
Aug 14 06:37:57 framework01 kernel: usb 2-2.4.2: USB disconnect, device number 5
Aug 14 06:37:57 framework01 kernel: usb 2-2.4.2.1: USB disconnect, device number 7
Aug 14 06:37:57 framework01 kernel: usb 2-2.4.2.2: USB disconnect, device number 8
Aug 14 06:37:57 framework01 kernel: usb 2-2.4.2.2.1: USB disconnect, device number 10
Aug 14 06:37:57 framework01 kernel: thunderbolt 0-3: device disconnected
Aug 14 06:37:57 framework01 gsd-media-keys[4921]: Unable to get default source
Aug 14 06:37:57 framework01 boltd[1495]: [6bfd8780-00c9-TS4 ] disconnected (/sys/devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-3)
Aug 14 06:37:57 framework01 kernel: pcieport 0000:00:07.1: pciehp: Slot(4): Link Down
Aug 14 06:37:57 framework01 kernel: pcieport 0000:00:07.1: pciehp: Slot(4): Card not present
Aug 14 06:37:57 framework01 kernel: igc 0000:53:00.0 enp83s0: PHC removed
Thank you, @Matt_Hartley , I got a good first response from support and sent them the link to this, additional data about my configuration, and a log of the event happening.
Unfortunately, it doesn’t appear to be heat related. I was able to peel that back, and have reasonable temperatures on the CPU, but the disconnect still happened after the changes.
I did find another thread that seems to indicate the same thing happening with my exact new dock, on Arch Linux.
After looking at the noted here, it looks like lowering the charge current for batteries that have charged above 60% capacity may help.
I completely understand @Matt_Hartley , it looks like the service that @real_or_random created is working to resolve this. Slowly backing off the current and moving to 60W before cutting the charging completely seems to resolve this.
I am not 100% familiar with the app used “ectool”, but it looks like it actually sets the charge current to 100, then drops to 60 in the default script, and it does this in the BIOS. Maybe something that should be addressed in a future BIOS update?
If @real_or_random is still around, maybe he can elaborate. It would be good to get this fixed in a BIOS release to avoid having to create the service on new installations.
One last note on this, as it just occurred to me. It probably wasn’t the Linux kernel version, but I recently set the battery charge limit in the BIOS to 80%. That’s about the time this started happening thinking back.
I did this, because for the most part this laptop is at home, and rarely do I need it to last longer than a few hours. I figure it would be better for battery health to not fully charge it.
So, seems like it may be a bug with BIOS battery limiting.
Well, I hit a wall with support at this point. They are asking for details I have already provided and logs / files that I had previously provided. I guess I will keep the service / script tucked in my back pocket in case I need to change distros, or reinstall until I see something from Framework addressing this.
