[TRACKING] FW13 AMD USB-A expanson card powers down (?) and does not wake up

I’m almost sure I came across a post or topic about this from somebody but I didn’t manage to find it (sorry!).

I have a FW 13 with Ryzen 7840U which has been experiencing a weird behaviour with the USB-A expansion card in the front-left port where plugging in a device (incl. flash drives and peripherals) will not register at all with the OS. This happens both on Linux (Gentoo, Debian) and Windows 11.

I have not found a reliable way, in the sense of ‘every time’, of reproducing this but it may happen when:

  • explicitly “ejecting” a device such as a flash drive
  • port is empty and unused for an extended period of time

But it can be reproduced reliably given enough time. It could be as little as a few minutes after boot or ejecting a device.

My initial assumption was that this is a side effect of OS power saving features where unused ports are powered down. While this may still be relevant, a power cycle such as a reboot or even cold boot after full system shut down does not wake up the port. The only thing that gets the port going again is re-insertion of the expansion card.

The same port works fine with a USB-C expansion card. I was also unable to reproduce this with the USB-A card in another port such as the front-right suggesting that the expansion card itself might not be the issue, or it might just be a matter of time.

Has anyone come across this behaviour with the USB-A card?

Edit: On Linux (Gentoo, kernel 6.6.13) I notice the following kernel messages when re-inserting the expansion card after the issue has been observed:

kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-5)
kernel: ucsi_acpi USBC000:00: possible UCSI driver bug 1
kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-22)
kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)

I don’t really use Windows so I have no idea how to obtain any logs there.

2 Likes

I have the same. More over my slot 2 with usb A card some times completely lose power on it same like in your described scenarios after some time or ejecting device. i tried with usb power meter and no power on port at all…
Also for some related reason i have one usb pen drive usb 3 gen 3.2 which completly dont work in any usb a slots 2 and 4… But it works if plugged via old cheap usb 2 hub.

2 Likes

Reseating the card can help. IIRC it has something to do with retimers not working properly.

1 Like

I’m happy I’m not going completely crazy and that somebody else is experiencing the same issue. I’m surprised, however, that this hasn’t been flagged as a problem in a way that is easily found.

Can confirm, just tried a simple test to check for power. When the issue presents itself, the USB-A card appears to be completely powered off, which would explain why any device being plugged in that has an LED doesn’t even light up.

Have you emailed support about this issue? Given that slot 2 (front left) is the obvious choice for a USB-A card given the overall constraints on the AMD board, I would have expected this to be tested enough so that it doesn’t happen as often as it does. I get this literally every time I need to use the port, which is extremely inconvenient and makes the whole point of having a type-A card a bit pointless.

It does, as I mentioned in the original post. But, unfortunately, that’s a workaround - a rather terrible and extremely inconvenient one.

As for it being a retimer issue - I hope this is fixable with firmware update because, at present, this port is completely unusable as USB-A.

I might email FW support re this issue if it doesn’t get picked up sooner by a FW rep, but I thought I’d post here first to shed some light and see if it might be an isolated or limited problem.

1 Like

I was able to reproduce the exact same behaviour but with a USB-C expansion card and a cheap C-to-A adapter, again in slot 2 (front left).

When the adapter is left plugged into the type C port, but empty, it will eventually power down and not wake up to any USB-A device being plugged in. However, reconnecting the adapter (with out without the USB-A device attached) will “wake up” the port. Since this scenario simulates an USB-A expansion card being re-seated it’s not surprising that the behaviour is exactly the same as with the USB-A expansion card. This rules out issues with the USB-A expansion card itself.

I was also able to reproduce this behaviour in slot 1 (back left). I’ve yet to experience this in either of the right ports.

1 Like

if u have a quite tiny usb c to a adapter try to check it directly without expansion card

1 Like

It’s not quite as slick, unfortunately. It shouldn’t really matter though as the USB-C expansion card is essentially a pass-through gadget and doesn’t have any additional components on the PCB other than the two end connectors and the traces between them.

1 Like

seems i found solution to wake up this slot with plugging in some old usb 2 (better with led for control) pen drive. for me it seems the bug some how related to current off protection idk… weird…

1 Like

@0xc0ffee based on the image found here, can you tell me exactly which port number this is? Need to make sure we are on the same exact page as to which ports you’re revering to.

Also, while I can see the error in the logs you provided, can we test this against an officially supported (and tested) distro by chance? Live USB of Fedora would be fine. I ask this as I have not personally run into this on my FW 13 laptop and if there is a bug, I need to make sure we know if this is a retimer thing or something else.

Thanks for the reply @Matt_Hartley, it’s much appreciated!

Ports 1 and 2 as per the image (back left and back front respectively). I used this as a reference in my earlier posts, so they should hopefully match unless I messed up.

Of course, no worries. Can confirm issue occurs on Fedora 39 (kernel 6.5.6-300.fc39.x86_64), freshly made Live USB drive through the official MediaWriter tool.

Port 2, which initially had the USB-A expansion card had already powered down after booting into Fedora and was unresponsive to devices being plugged in. As usual, re-seating the expansion card brought it back up. Can also confirm this happens (as before) with a basic C-to-A adapter plugged into a USB-C expansion card. As previously observed, re-seating the adapter makes the port work again.

If it’s of any help, I think I’ve found a way to somewhat reliably reproduce the issue.

  1. Plug a device in port 1 or 2 - my experiments included an ADATA (USB 3.0) and Kingston (USB 3.1 gen 1) flash drives, and a YubiKey 5 (USB 2.0)
  2. If the port is on and device is detected, disconnect the device
  3. Wait a few seconds, go back to 1
    • If that doesn’t work immediately, gradually keep increasing the waiting time by a few seconds up to a minute
  4. Repeat the process until plugging the device in no longer registers.

It might take a few tries but it will eventually happen, sometimes doing nothing for a random period of time also triggers this, but it’s more difficult to predict how long. Reproducing the issue in Port 1 is a bit harder, perhaps due to the existing “power draw” issue with USB-A which might keep it powered on for longer than necessary (I’m speculating) but will eventually happen.

It helps having “tail -f” to keep an eye on any kernel log messages, notably around whether a new device has been detected. Once the port powers down there won’t be any “new device” messages. As for the logs themselves the same thing as reported before so nothing new or different.

However, I’ve also noticed - not exclusive to the Fedora test - that kernel: ucsi_acpi USBC000:00 related messages, particularly those mentioning ucsi_handle_connector_change: ACK failed (-110) also seem to appear when plugging out and in the power adapter cable, which I usually keep in port 3 (back right). This doesn’t seem to otherwise affect the functionality of the port or the laptop overall. So the ucsi_acpi messages may actually be a symptom of something else which also happens to be related to this issue.

2 Likes

I am also experiencing this issue with the Ryzen 5 version.

1 Like

Totally confirm everything said above by @0xc0ffee. I can only add that it also does not depend on OS. I tried different live distros, as well as installed ones (Debian, Ubuntu, Arch, Fedora), even in W11 there is a similar behavior of these ports.

1 Like

Appreciate everyone providing great details, let’s get this into a template so I can get this duplicated on my end, then in front of engineering as needed.

  • Distro and kernel used?

  • You are not using a dock or extension cable, you are using an USB-A expansion card in the affected slot? If you are, please try again without these and report here in this section:

  • Using the number scheme indicated on this page, please let me know which slot number?

  • List the brands/models of affected USB-A devices in this ported tested to experience the power down issue?

  • Run sudo dmesg -w in a terminal. Plug in the USB-A device, what is displayed as a result?

With this, I can replicate this in our supported distros for comparison and if it happens there as well (perhaps a bug), I can then escalate this.

2 Likes
  • [Daily driver] Gentoo Linux, kernel 6.6.13-gentoo-x86_64
  • [Reproduced on] Fedora 39 Live, kernel 6.5.6-300.fc39.x86_64
  • [Reproduced on] Debian 12 ‘Bookworm’, kernel 6.1.76-1-amd64
  • [Reproduced on] Windows 11

USB-A expansion card

  • But also reproducible with C-to-A dongle into USB-C expansion card
  • Slot 1
  • Slot 2
  • ADATA S102 flash drive, USB 3.0
  • Kingston HyperX flash drive, USB 3.1
  • YubiKey 5 NFC
  • Logitech G502 wireless dongle
  • ADATA S102
    usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd
    usb 2-2: New USB device found, idVendor=125f, idProduct=312b, bcdDevice=11.00
    usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    usb 2-2: Product: ADATA USB Flash Drive
    usb 2-2: Manufacturer: ADATA
    usb 2-2: SerialNumber: <redacted>
    usb-storage 2-2:1.0: USB Mass Storage device detected
    scsi host0: usb-storage 2-2:1.0
    scsi 0:0:0:0: Direct-Access     ADATA    USB Flash Drive  1100 PQ: 0 ANSI: 6
    sd 0:0:0:0: Attached scsi generic sg0 type 0
    sd 0:0:0:0: [sda] 60620800 512-byte logical blocks: (31.0 GB/28.9 GiB)
    sd 0:0:0:0: [sda] Write Protect is off
    sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
    sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    sda: sda1 sda2 sda3
    sd 0:0:0:0: [sda] Attached SCSI removable disk
    
  • Kingston HyperX
    usb 2-2: new SuperSpeed USB device number 7 using xhci_hcd
    usb 2-2: New USB device found, idVendor=0951, idProduct=16b3, bcdDevice= 1.00
    usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    usb 2-2: Product: HyperX Savage
    usb 2-2: Manufacturer: Kingston
    usb 2-2: SerialNumber: <redacted>
    usb-storage 2-2:1.0: USB Mass Storage device detected
    scsi host0: usb-storage 2-2:1.0
    scsi 0:0:0:0: Direct-Access     Kingston HyperX Savage    PMAP PQ: 0 ANSI: 6
    sd 0:0:0:0: Attached scsi generic sg0 type 0
    sd 0:0:0:0: [sda] 122945536 512-byte logical blocks: (62.9 GB/58.6 GiB)
    sd 0:0:0:0: [sda] Write Protect is off
    sd 0:0:0:0: [sda] Mode Sense: 2b 00 00 08
    sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
    sda: sda1 sda2
    sd 0:0:0:0: [sda] Attached SCSI removable disk
    
  • YubiKey 5 NFC
    usb 2-2: USB disconnect, device number 7
    usb 1-2: new full-speed USB device number 5 using xhci_hcd
    usb 1-2: New USB device found, idVendor=1050, idProduct=0407, bcdDevice= 5.43
    usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 1-2: Product: YubiKey OTP+FIDO+CCID
    usb 1-2: Manufacturer: Yubico
    input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2:1.0/0003:1050:0407.0005/input/input15
    hid-generic 0003:1050:0407.0005: input,hidraw4: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:c1:00.3-2/input0
    hid-generic 0003:1050:0407.0006: hiddev1,hidraw5: USB HID v1.10 Device [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:c1:00.3-2/input1
    
  • Logitech G502 wireless dongle
    usb 1-2: new full-speed USB device number 5 using xhci_hcd
    usb 1-2: New USB device found, idVendor=046d, idProduct=c539, bcdDevice=39.06
    usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 1-2: Product: USB Receiver
    usb 1-2: Manufacturer: Logitech
    input: Logitech USB Receiver as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2:1.0/0003:046D:C539.0005/input/input15
    hid-generic 0003:046D:C539.0005: input,hidraw4: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:c1:00.3-2/input0
    input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2:1.1/0003:046D:C539.0006/input/input16
    input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2:1.1/0003:046D:C539.0006/input/input17
    input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2:1.1/0003:046D:C539.0006/input/input18
    hid-generic 0003:046D:C539.0006: input,hiddev97,hidraw5: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:c1:00.3-2/input1
    hid-generic 0003:046D:C539.0007: hiddev98,hidraw6: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:c1:00.3-2/input2
    logitech-djreceiver 0003:046D:C539.0005: hidraw4: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:c1:00.3-2/input0
    logitech-djreceiver 0003:046D:C539.0006: hiddev97,hidraw5: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:c1:00.3-2/input1
    logitech-djreceiver 0003:046D:C539.0007: hiddev98,hidraw6: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:c1:00.3-2/input2
    logitech-djreceiver 0003:046D:C539.0007: device of type eQUAD Lightspeed 1 (0x0c) connected on slot 1
    input: Logitech Wireless Mouse PID:407f Keyboard as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2:1.2/0003:046D:C539.0007/0003:046D:407F.0008/input/input20
    input: Logitech Wireless Mouse PID:407f Mouse as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2:1.2/0003:046D:C539.0007/0003:046D:407F.0008/input/input21
    hid-generic 0003:046D:407F.0008: input,hidraw7: USB HID v1.11 Keyboard [Logitech Wireless Mouse PID:407f] on usb-0000:c1:00.3-2/input2:1
    input: Logitech G502 as /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-2/1-2:1.2/0003:046D:C539.0007/0003:046D:407F.0008/input/input25
    logitech-hidpp-device 0003:046D:407F.0008: input,hidraw7: USB HID v1.11 Keyboard [Logitech G502] on usb-0000:c1:00.3-2/input2:1
    logitech-hidpp-device 0003:046D:407F.0008: Disconnected
    ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
    logitech-hidpp-device 0003:046D:407F.0008: HID++ 4.2 device connected.
    

Edit: Updated wrong dmesg output for mouse dongle

2 Likes

I also experienced something even weirded. I had my Logitech G502 wireless dongle plugged into Slot 1 (USB-C expansion card) with a C-to-A adapter. The dongle simply disconnected, then reconnected. This was repeated a few times before eventually disconnecting permanently and the port was ‘powered off’. I managed to catch the final bit with dmesg:

[  163.853064] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[  167.821183] usb 7-1: new full-speed USB device number 2 using xhci_hcd
[  167.992981] usb 7-1: New USB device found, idVendor=046d, idProduct=c539, bcdDevice=39.06
[  167.992995] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  167.993000] usb 7-1: Product: USB Receiver
[  167.993005] usb 7-1: Manufacturer: Logitech
[  168.013813] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1:1.0/0003:046D:C539.0005/input/input14
[  168.074007] hid-generic 0003:046D:C539.0005: input,hidraw4: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:c3:00.4-1/input0
[  168.080665] input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1:1.1/0003:046D:C539.0006/input/input15
[  168.080863] input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1:1.1/0003:046D:C539.0006/input/input16
[  168.140877] input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1:1.1/0003:046D:C539.0006/input/input17
[  168.141299] hid-generic 0003:046D:C539.0006: input,hiddev1,hidraw5: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:c3:00.4-1/input1
[  168.145751] hid-generic 0003:046D:C539.0007: hiddev2,hidraw6: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:c3:00.4-1/input2
[  168.401630] logitech-djreceiver 0003:046D:C539.0005: hidraw4: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:c3:00.4-1/input0
[  168.602272] logitech-djreceiver 0003:046D:C539.0006: hiddev1,hidraw5: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:c3:00.4-1/input1
[  168.661731] logitech-djreceiver 0003:046D:C539.0007: hiddev2,hidraw6: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:c3:00.4-1/input2
[  168.724418] logitech-djreceiver 0003:046D:C539.0007: device of type eQUAD Lightspeed 1 (0x0c) connected on slot 1
[  168.724957] input: Logitech Wireless Mouse PID:407f Keyboard as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1:1.2/0003:046D:C539.0007/0003:046D:407F.0008/input/input19
[  168.725379] input: Logitech Wireless Mouse PID:407f Mouse as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1:1.2/0003:046D:C539.0007/0003:046D:407F.0008/input/input20
[  168.725553] hid-generic 0003:046D:407F.0008: input,hidraw7: USB HID v1.11 Keyboard [Logitech Wireless Mouse PID:407f] on usb-0000:c3:00.4-1/input2:1
[  168.976643] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[  169.125824] input: Logitech G502 as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1:1.2/0003:046D:C539.0007/0003:046D:407F.0008/input/input24
[  169.126787] logitech-hidpp-device 0003:046D:407F.0008: input,hidraw7: USB HID v1.11 Keyboard [Logitech G502] on usb-0000:c3:00.4-1/input2:1
[  169.369860] elogind-daemon[4446]: Watching system buttons on /dev/input/event12 (Logitech G502)
[  174.223808] logitech-hidpp-device 0003:046D:407F.0008: HID++ 4.2 device connected.
[  174.348609] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[  252.355774] usb 7-1: USB disconnect, device number 2
[  253.105036] usb 7-1: new full-speed USB device number 3 using xhci_hcd
[  253.276660] usb 7-1: New USB device found, idVendor=046d, idProduct=c539, bcdDevice=39.06
[  253.276675] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  253.276681] usb 7-1: Product: USB Receiver
[  253.276685] usb 7-1: Manufacturer: Logitech
[  253.294992] logitech-djreceiver 0003:046D:C539.0009: hidraw4: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:c3:00.4-1/input0
[  253.359581] logitech-djreceiver 0003:046D:C539.000A: hiddev1,hidraw5: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:c3:00.4-1/input1
[  253.423956] logitech-djreceiver 0003:046D:C539.000B: hiddev2,hidraw6: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:c3:00.4-1/input2
[  253.488058] logitech-djreceiver 0003:046D:C539.000B: device of type eQUAD Lightspeed 1 (0x0c) connected on slot 1
[  254.055128] logitech-hidpp-device 0003:046D:407F.000C: HID++ 4.2 device connected.
[  254.213858] input: Logitech G502 as /devices/pci0000:00/0000:00:08.3/0000:c3:00.4/usb7/7-1/7-1:1.2/0003:046D:C539.000B/0003:046D:407F.000C/input/input25
[  254.214301] logitech-hidpp-device 0003:046D:407F.000C: input,hidraw7: USB HID v1.11 Keyboard [Logitech G502] on usb-0000:c3:00.4-1/input2:1
[  254.321877] elogind-daemon[4446]: Watching system buttons on /dev/input/event12 (Logitech G502)
[  259.085459] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[  267.277083] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)

The mouse was in use so it can’t have been due to inactivity. This also happened in Windows 11.

If I manage to catch the same issue again in either slot directly through the USB-A expansion card I will report back with the log. But what is peculiar about the above is that if you look at the log it doesn’t seem to register anything unusual - it’s as if I disconnected the device myself.


Some more insight in the hopes it would be useful. I decided to reset the bios to its factory defaults - it did not help. Then I tried to:

  1. Unplug the laptop from the AC
  2. Go to the BIOS and select “Disconnect battery”
  3. Save & quit
  4. Wait a few seconds after power down and double check that it doesn’t power up with the power button
  5. Plug in the AC and update BIOS settings as they were lost

This temporarily stabilised the situation and for a while I wasn’t getting any issues with the USB-A port. But then it started doing it again some hours later after a cold boot.

3 Likes

Outstanding work.

This is exactly the format I needed. Please open a ticket.

Please make sure to include this thread in the ticket and because we have done all the standard triage in your work here, please ask to have it escalated to Matt directly.

Normally I don’t do this, however, we just did the triage needed in this thread and we can escalate this directly to me based on this testing.

3 Likes

Thanks, Matt! Just filed a support ticket as per your instructions.

2 Likes

Another observation while trying to track down the source of the issue.

For some reason, having something connected, e.g. flash drive, in slot 1 makes it harder to reproduce the issue in slot 2 and it becomes a waiting game with less predictability, and vice versa. But if slot 1 is left empty, the behaviour can be relatively easily reproduced with the steps I already outlined above in slot 2.

I can only speculate, but this might have to do with the topology of the ports in the underlying electronic circuit. If both of them connect to the same controller/hub/re-timer/etc, it may be that one being “active” keeps the other alive too.

Anyway, I don’t want to throw in too many potential red herrings with my reasoning, but it’s a fairly consistent observation.

4 Likes

Just thought I’d post an update for everyone’s benefit.

After opening a support ticket, as Matt kindly requested, Framework made the decision that my particular case could be a mainboard fault and qualified for a replacement under warranty. Once the new board arrived it only took 15 mins to swap it out, while reading the guide, and that could easily have been done in less time once familiar with the process - good job FW on how easy this was.

It’s now been roughly a week with the new board and I’ve not had any issues with any of the ports or the USB-A expansion card.

I’m still seeing the

ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)

message in dmesg once in a while, so that’s mostly likely unrelated as everything is fine.

I will continue to monitor the situation but it seems the mainboard swap has resolved the problem in full.

Matt is perhaps best qualified to recommend a course of action to anyone else experiencing the same problem, but looks like it’s not a wide spread issue as I would have expected a lot more responses here. If anyone is coming to this at a later point, it might be worth reading through the thread, going through the steps to reproduce, and, if you suspect it might be the same issue, consider opening a ticket with support and they’ll help you out.

5 Likes

So to be clear, the error

ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)

is not a problem? Do you know how to fix it?