[RESPONDED] Fedora 39 12th gen i7 Docking issues

Hey guys! I hope you all are well. I recently purchased a used Framework 13 off a friend (he was too bothered with his faulty hinged but I’m gonna fix them). However, I’ve noticed that there are issues with using it connected to a dock. It’s disconnected and reconnected about a dozen times today while working, and it’s enraging every time it happens. If I could get some guidance that would be great!
The specific symptoms are: I use it normally, and when it gets under “heavy use” (like a few tabs open and VSCode), it it likely to disconnect from the dock and quickly reconnect.
I’ve tried it using all 4 ports, and also plugging directly into the top right part of the motherboard, but it still keeps happening. One time, it was really slow and I saw a few interesting parts:

  1. The screen blanks, and everything readjusts to the external monitor (throwing all my windows out of wack)
  2. The keyboard and touchpad become unresponsive. My external Bluetooth mouse, however, works fine.
  3. Everything will reconnect, throwing my windows around one final time (as if to spite me).

Here are the specs of the device:

  • 12th Gen 17-1260P
  • 16gb Ram
  • 512 WD Black hard drive
  • Endeavour OS
  • Anker 575 USB-C Docking Station
  • 3.05 BIOS

Let me know of any questions. I have incredible faith in this company and hope to get this resolved!

Try using it without the dock, go some USB-C charger in one port and HDMI/DP/USB-C video out to your monitor for a bit.

On and off both my Framework 13 AMD and my ThinkPad X1 would drop my USB-C Dell monitors connection and exibit similar behaviour (although I only lose video and any USB devices on the monitor). Sometimes once an hour, sometimes once a day.

In my case, I was using the passthrough function of my monitors to connect two screens via one USB-C (using MST on the first monitor). I gave up and plugged the second monitor in via HDMI and they have not missed a beat in a week.

That’s a nice looking docking station by the way!

Hey, thanks for helping me out man. Just wanted to give you an update.
For the past few days, I have been using a direct DP connection to the monitor, and it works just fine.
However, the dock does seem to still be disconnecting (i can tell it is because I lose ethernet connection). Any ideas as to why?

1 Like

New update: it just happened again. Specificallly the monitor. It’s tiring to be honest. Has anybody else has an issue like this?

Here is what journalctl says:

Mar 08 16:03:07 framevirgin gnome-shell[1410]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Mar 08 16:04:06 framevirgin gnome-shell[1410]: Window manager warning: Ping serial 2311026 was reused for window W29, previous use was for window W28.
Mar 08 16:04:13 framevirgin systemd-logind[682]: Lid closed.
Mar 08 16:04:13 framevirgin gnome-shell[1410]: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
Mar 08 16:04:13 framevirgin gnome-shell[1410]: drawCorners
Mar 08 16:04:13 framevirgin gnome-shell[1410]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Mar 08 16:04:13 framevirgin gnome-shell[1410]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Mar 08 16:04:13 framevirgin gnome-shell[1410]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Mar 08 16:04:13 framevirgin gnome-shell[1410]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Mar 08 16:04:13 framevirgin gnome-shell[1410]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Mar 08 16:04:13 framevirgin gnome-shell[1410]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Mar 08 16:04:13 framevirgin gnome-shell[1410]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Mar 08 16:04:13 framevirgin gnome-shell[1410]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Mar 08 16:04:13 framevirgin rtkit-daemon[1152]: Successfully made thread 1450 of process 1410 owned by '1000' high priority at nice level 0.
Mar 08 16:04:13 framevirgin rtkit-daemon[1152]: Supervising 1 threads of 1 processes of 1 users.
Mar 08 16:04:14 framevirgin gsd-media-keys[1574]: Unable to get default sink
Mar 08 16:04:14 framevirgin gsd-media-keys[1574]: Unable to get default source
Mar 08 16:04:14 framevirgin gsd-media-keys[1574]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
Mar 08 16:04:14 framevirgin rtkit-daemon[1152]: Supervising 0 threads of 0 processes of 1 users.
Mar 08 16:04:14 framevirgin rtkit-daemon[1152]: Supervising 0 threads of 0 processes of 1 users.
Mar 08 16:04:14 framevirgin rtkit-daemon[1152]: Successfully made thread 1450 of process 1410 owned by '1000' RT at priority 20.
Mar 08 16:04:14 framevirgin rtkit-daemon[1152]: Supervising 1 threads of 1 processes of 1 users.
Mar 08 16:04:14 framevirgin gsd-media-keys[1574]: Unable to get default sink
Mar 08 16:04:14 framevirgin gsd-media-keys[1574]: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
Mar 08 16:04:17 framevirgin gnome-shell[1410]: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct.
Mar 08 16:04:17 framevirgin gnome-shell[1410]: JS ERROR: TypeError: record is undefined
                                               _syncStacking@resource:///org/gnome/shell/ui/workspaceAnimation.js:85:13
                                               @resource:///org/gnome/shell/ui/init.js:21:20
Mar 08 16:04:17 framevirgin gnome-shell[1410]: Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct.
Mar 08 16:04:17 framevirgin gnome-shell[1410]: JS ERROR: TypeError: record is undefined
                                               _syncStacking@resource:///org/gnome/shell/ui/workspaceAnimation.js:85:13
                                               @resource:///org/gnome/shell/ui/init.js:21:20
Mar 08 16:04:25 framevirgin systemd-logind[682]: Lid opened.
Mar 08 16:04:25 framevirgin gnome-shell[1410]: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
Mar 08 16:04:25 framevirgin gnome-shell[1410]: drawCorners

interestingly, it states that the lid was closed. What determines that?

some extra info: i know that these hinges are unusually weka, to the point where it would’ve been replaced under warranty (i don’t know why he didnt lol). i actually just received the new 3.5kg hinges in today, i don’t know if that has anything to do with detecting the lid is closed

Just had the dock disconnect (not the monitor, that’s plugged in seperate). This is the output of journalctl:

Mar 10 15:58:11 framevirgin kernel: usb 3-2: USB disconnect, device number 21
Mar 10 15:58:11 framevirgin kernel: usb 3-2.3: USB disconnect, device number 22
Mar 10 15:58:11 framevirgin kernel: usb 3-2.3.3: USB disconnect, device number 24
Mar 10 15:58:11 framevirgin kernel: usb 2-1: USB disconnect, device number 14
Mar 10 15:58:11 framevirgin kernel: usb 2-1.2: USB disconnect, device number 15
Mar 10 15:58:11 framevirgin kernel: cdc_ncm 2-1.2:2.0 enp0s13f0u1u2c2: unregister 'cdc_ncm' usb-0000:00:0d.0-1.2, CDC NCM (NO ZLP)
Mar 10 15:58:11 framevirgin kernel: usb 3-2.4: USB disconnect, device number 23
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Interface enp0s13f0u1u2c2.IPv6 no longer relevant for mDNS.
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Leaving mDNS multicast group on interface enp0s13f0u1u2c2.IPv6 with address 2603:6080:4ef0:6ea0:7dee:b7b2:810e:a602.
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Interface enp0s13f0u1u2c2.IPv4 no longer relevant for mDNS.
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Leaving mDNS multicast group on interface enp0s13f0u1u2c2.IPv4 with address 192.168.1.240.
Mar 10 15:58:11 framevirgin NetworkManager[726]: <info>  [1710100691.8485] device (enp0s13f0u1u2c2): state change: activated -> unmanaged (reason 'removed', sys-iface-state: 'removed')
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Withdrawing address record for 2603:6080:4ef0:6ea0::1f45 on enp0s13f0u1u2c2.
Mar 10 15:58:11 framevirgin NetworkManager[726]: <info>  [1710100691.8487] dhcp4 (enp0s13f0u1u2c2): canceled DHCP transaction
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Withdrawing address record for fd00:5cfa:25df:2993::1f45 on enp0s13f0u1u2c2.
Mar 10 15:58:11 framevirgin NetworkManager[726]: <info>  [1710100691.8487] dhcp4 (enp0s13f0u1u2c2): activation: beginning transaction (timeout in 45 seconds)
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Withdrawing address record for fd00:5cfa:25df:2993:7f67:97e1:3c8f:5f38 on enp0s13f0u1u2c2.
Mar 10 15:58:11 framevirgin NetworkManager[726]: <info>  [1710100691.8487] dhcp4 (enp0s13f0u1u2c2): state changed no lease
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Withdrawing address record for 2603:6080:4ef0:6ea0:7dee:b7b2:810e:a602 on enp0s13f0u1u2c2.
Mar 10 15:58:11 framevirgin NetworkManager[726]: <info>  [1710100691.8489] dhcp6 (enp0s13f0u1u2c2): canceled DHCP transaction
Mar 10 15:58:11 framevirgin avahi-daemon[661]: Withdrawing address record for 192.168.1.240 on enp0s13f0u1u2c2.
Mar 10 15:58:11 framevirgin NetworkManager[726]: <info>  [1710100691.8489] dhcp6 (enp0s13f0u1u2c2): activation: beginning transaction (timeout in 45 seconds)
Mar 10 15:58:11 framevirgin NetworkManager[726]: <info>  [1710100691.8489] dhcp6 (enp0s13f0u1u2c2): state changed no lease
Mar 10 15:58:11 framevirgin systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar 10 15:58:11 framevirgin kernel: usb 2-1.3: USB disconnect, device number 16
Mar 10 15:58:11 framevirgin kernel: usb 2-1.3.2: USB disconnect, device number 17
Mar 10 15:58:11 framevirgin systemd[1]: Started Network Manager Script Dispatcher Service.
Mar 10 15:58:12 framevirgin kernel: usb 2-1.3.3: USB disconnect, device number 18
Mar 10 15:58:12 framevirgin kernel: usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 19 using xhci_hcd
Mar 10 15:58:12 framevirgin kernel: usb 3-2: new high-speed USB device number 25 using xhci_hcd
Mar 10 15:58:12 framevirgin kernel: usb 2-1: New USB device found, idVendor=291a, idProduct=8392, bcdDevice= 7.73
Mar 10 15:58:12 framevirgin kernel: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 10 15:58:12 framevirgin kernel: usb 2-1: Product: Anker USB-C Docking Device
Mar 10 15:58:12 framevirgin kernel: usb 2-1: Manufacturer: Anker                  
Mar 10 15:58:12 framevirgin kernel: usb 2-1: SerialNumber: 000000001
Mar 10 15:58:12 framevirgin kernel: hub 2-1:1.0: USB hub found
Mar 10 15:58:12 framevirgin kernel: hub 2-1:1.0: 4 ports detected
Mar 10 15:58:13 framevirgin kernel: usb 3-2: New USB device found, idVendor=291a, idProduct=8392, bcdDevice= 7.73
Mar 10 15:58:13 framevirgin kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 10 15:58:13 framevirgin kernel: usb 3-2: Product: Anker USB-C Docking Device
Mar 10 15:58:13 framevirgin kernel: usb 3-2: Manufacturer: Anker                  
Mar 10 15:58:13 framevirgin kernel: usb 3-2: SerialNumber: 000000001
Mar 10 15:58:13 framevirgin kernel: hub 3-2:1.0: USB hub found
Mar 10 15:58:13 framevirgin kernel: hub 3-2:1.0: 4 ports detected
Mar 10 15:58:13 framevirgin kernel: usb 2-1.3: new SuperSpeed USB device number 20 using xhci_hcd
Mar 10 15:58:13 framevirgin kernel: usb 2-1.3: New USB device found, idVendor=2109, idProduct=0817, bcdDevice=90.23
Mar 10 15:58:13 framevirgin kernel: usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 10 15:58:13 framevirgin kernel: usb 2-1.3: Product: USB3.0 Hub             
Mar 10 15:58:13 framevirgin kernel: usb 2-1.3: Manufacturer: VIA Labs, Inc.         
Mar 10 15:58:13 framevirgin kernel: usb 2-1.3: SerialNumber: 000000000
Mar 10 15:58:13 framevirgin kernel: hub 2-1.3:1.0: USB hub found
Mar 10 15:58:13 framevirgin kernel: hub 2-1.3:1.0: 4 ports detected
Mar 10 15:58:13 framevirgin kernel: usb 3-2: USB disconnect, device number 25
Mar 10 15:58:13 framevirgin kernel: usb 3-2-port2: attempt power cycle
Mar 10 15:58:14 framevirgin kernel: hub 2-1.3:1.0: hub_ext_port_status failed (err = -71)
Mar 10 15:58:14 framevirgin kernel: usb 2-1.3: Failed to suspend device, error -71
Mar 10 15:58:14 framevirgin kernel: usb 2-1: USB disconnect, device number 19
Mar 10 15:58:14 framevirgin kernel: usb 2-1.3: USB disconnect, device number 20
Mar 10 15:58:14 framevirgin kernel: xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
Mar 10 15:58:14 framevirgin gnome-shell[1424]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Mar 10 15:58:14 framevirgin gnome-shell[1424]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Mar 10 15:58:14 framevirgin gnome-shell[1424]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Mar 10 15:58:15 framevirgin kernel: usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 21 using xhci_hcd
Mar 10 15:58:15 framevirgin kernel: usb 2-1: New USB device found, idVendor=291a, idProduct=8392, bcdDevice= 7.73
Mar 10 15:58:15 framevirgin kernel: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 10 15:58:15 framevirgin kernel: usb 2-1: Product: Anker USB-C Docking Device
Mar 10 15:58:15 framevirgin kernel: usb 2-1: Manufacturer: Anker                  
Mar 10 15:58:15 framevirgin kernel: usb 2-1: SerialNumber: 000000001
Mar 10 15:58:15 framevirgin kernel: hub 2-1:1.0: USB hub found
Mar 10 15:58:15 framevirgin kernel: hub 2-1:1.0: 4 ports detected
Mar 10 15:58:15 framevirgin kernel: usb 3-2: new high-speed USB device number 30 using xhci_hcd
Mar 10 15:58:15 framevirgin kernel: usb 3-2: New USB device found, idVendor=291a, idProduct=8392, bcdDevice= 7.73
Mar 10 15:58:15 framevirgin kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 10 15:58:15 framevirgin kernel: usb 3-2: Product: Anker USB-C Docking Device
Mar 10 15:58:15 framevirgin kernel: usb 3-2: Manufacturer: Anker                  
Mar 10 15:58:15 framevirgin kernel: usb 3-2: SerialNumber: 000000001
Mar 10 15:58:15 framevirgin kernel: hub 3-2:1.0: USB hub found
Mar 10 15:58:15 framevirgin kernel: hub 3-2:1.0: 4 ports detected
Mar 10 15:58:15 framevirgin kernel: usb 2-1.2: new SuperSpeed USB device number 22 using xhci_hcd
Mar 10 15:58:16 framevirgin kernel: usb 2-1.2: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00
Mar 10 15:58:16 framevirgin kernel: usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 10 15:58:16 framevirgin kernel: usb 2-1.2: Product: AX88179A
Mar 10 15:58:16 framevirgin kernel: usb 2-1.2: Manufacturer: ASIX
Mar 10 15:58:16 framevirgin kernel: usb 2-1.2: SerialNumber: 00000000000001

for some reason it seems to have disconnected?

further update: i have switched to fedora 39, and it’s still happenening. journalctl gives me this. i’m completely lost and not sure what to do

it just happened two times in a row, this is honestly become unusable. at this point i’m desperate for help.

update: tried it with a different docking station, and i got this. it’s related to the laptop, i think i’m going to try windows off a USB next.

Docks are tricky as they’re great until they’re not. Generally issues range from I/O to power. Our recommendation is to stick with the expansion card system as we can control how those interactions take place. Baring this, you could file a bug report.

I suspect your stuff is autosuspennding. Use TLP instead of Power Profiles. Add the usb and ethernet connections to the USB_DENYLIST= configuration. You can find the required identification fo your items by running lsusb. Essentially parts of your dock are falling asleep when they are not being actively used, or the use drops temporarily below a certain level.

Also update the BIOS. I had a lot of dock issues until updating to 3.06 beta, or 3.08 beta. In fact update the BIOS first. You are unlikely to resolve anything as long as you are on 3.05.

id love to do that, however when im doing something like music production, i have upwards of 6 items plugged in at the same time. im also very mobile, so a docking station is best for my use case. instead of ignoring, id like to find out what the problem is (: ill use the expansion cards when i can though!

tlp is interesting, i tried that but got off because there was no way i could see to switch profiles in the gnome quick settings.

ive been running windows (begrudgingly) all day today, and it seems to be stable on my dock. should i still try the bios update first?

There is no way to switch profiles with tlp. It has two. On AC and on Battery. You could probably script it to change profiles and tie it to a shortcut key combo. The ony other way to take care of the autosuspend issue is to use UDEV rules to do so. Tlp is probably the easiest way to take care of the dock issues that may not be BIOS specific. Also there is TLPUI floating around.

As to updating your BIOS…I would never recommend that someone update to a beta BIOS, but since Framework has yet to release a stable BIOS and that is what actually fixes all of the Thunderbolt oddities, all I can say is do your due diligence, check out the thread 12th Gen Intel Core BIOS 3.08 Beta Release and come to your own determination. I have had great success with both the update process and with running the device on said BIOS.

1 Like

i went ahead and did a 3.08 update, and it went smoothly! i’m now testing the dock. if there are no issues in the next 3 days i’ll mark this as resolved (:

after a little bit of use, the issue has came back. obligatory pastebin, but i don’t see much different. i’ll try disabling the autosuspend first in power-profiles-daemon udev rules, and then tlp if that doesn’t work: i’ve done this:

NEW FILE: 90-usb-dock-autosuspend-off.rules:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="291a", ATTRS{idProduct}=="8392", TEST=="power/control", ATTR{power/control}="on"

and restarted the udev rules. i’ll give further updates.

You may need to add the actual nic on the dock as well. Generally speaking I add any item from the dock that shows in lsusb, just to avoid any potential strange behaviors.

1 Like

After a few days of seemingly no issue (i use my laptop for over 7 hours yesterday connected to a dock), I was about to call it. And then it happened while I was playing my Switch.
another obligatory pastebin

what do you mean “nic”? how do i go about doing that?

nic = network interface card

One problem is you have set up a UDEV rule left, power profiles daemon in place and installed TLP but did not enable it. So now you have that conflict spamming your journal.

Once again I recommend ditching power-profiles-daemon and using tlp. Remove your UDEV rule they are easy to screw up. So with that in mind,

sudo systemctl stop power-profiles-daemon
sudo systemctl disable power-profiles-daemon
sudo dnf remove power-profiles-daemon
sudo dnf install tlp tlp-rdw
sudo systemctl start tlp
sudo systemctl status tlp
sudo systemctl enable tlp

Now we want to configure TLP. It will automatically switch between battery and AC profiles when appropriate, i.e. when your are plugged in it is on AC when you unplug it switches to battery and whatever power saving items you have specified in /etc/tlp.conf/insert-your-mods-here (read the main /etc/tlp.conf it will explain what to put in that file and the naming convention for it).

My tlp.d configuration file looks like this:

CPU_BOOST_ON_AC=1
CPU_BOOST_ON_BAT=0

CPU_HWP_DYN_BOOST_ON_AC=1
CPU_HWP_DYN_BOOST_ON_BAT=0

USB_DENYLIST="1e91:de4a 1e91:de5c 1e91:de4b 1e91:de4c 0bda:5411 0bda:8153"

USB_EXCLUDE_AUDIO=1

USB_EXCLUDE_BTUSB=1

DEVICES_TO_ENABLE_ON_AC="bluetooth"

DEVICES_TO_DISABLE_ON_BAT="bluetooth"

DEVICES_TO_ENABLE_ON_DOCK="bluetooth"
DEVICES_TO_DISABLE_ON_DOCK="wifi"

DEVICES_TO_ENABLE_ON_UNDOCK="wifi"
DEVICES_TO_DISABLE_ON_UNDOCK="bluetooth"

The important part for the dock is this:

USB_DENYLIST="1e91:de4a 1e91:de5c 1e91:de4b 1e91:de4c 0bda:5411 0bda:8153"

By running lsusb with nothing connected and running it again with my dock connected, I get this list of items:

Bus 002 Device 003: ID 1e91:de4c Other World Computing USB 3.2 Hub
Bus 002 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 003 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 003 Device 005: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 003 Device 006: ID 1e91:de4b Other World Computing USB 2.0 Hub
Bus 003 Device 010: ID 1e91:de5c Other World Computing Thunderbolt Dock 96W Audio Device
Bus 003 Device 011: ID 1e91:de4a Other World Computing Thunderbolt Dock 96W

Hence I add all of these items to the the USB_DENYLIST= in the configuration. I find this much easier than writing out 7 UDEV rules to start, particularly when I take into account that in the past I have used different docks depending on location. If you choose to continue with power-profiles-daemon then ignore the first bit of my response and just add UDEV rules. Also remove tlp at that point so the packages existence on your system stops the spamming on your journal.

Also while digging through your journal I noticed the Gnome Blur My Shell Extension spamming it with errors…turn it off. If you go to the github for the extension you can see it is a work in progress and has problems … particularly with multi monitor situations which could easily be triggered by being docked. This could be a contributing factor to your woes.

Anyway hope this helps.