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:
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.
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.
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.
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.
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…
@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.
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)
If the port is on and device is detected, disconnect the device
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
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.
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.
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.
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.
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:
Unplug the laptop from the AC
Go to the BIOS and select “Disconnect battery”
Save & quit
Wait a few seconds after power down and double check that it doesn’t power up with the power button
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.
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.
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.
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.
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.