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.
- 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.
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:
- 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.
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.
6 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?
I didn’t say it wasn’t a problem, just that it doesn’t appear to be related to the main issue discussed in this thread, which was confirmed by a mainboard swap which resolved the main issue.
I don’t know how to fix the error message, but it I also don’t see any side effects or issues caused by it. It might be a bug/quirk in the EC or the UCSI kernel module. Since the error message is easily reproducible on “supported” distros such as Fedora by simply unplugging and plugging the power cable, I’m sure the Framework team will have seen this at some point.
@Matt_Hartley as per my previous update, it looks like this was a mobo issue. Nearly 2 months later now with the new mobo and it all works perfectly with no issues. Do you think it’s worth marking this as resolved?
As for the ucsi_acpi error messages, just to give a final answer to @Nimrod_Hajaj as well, they appear to have been unrelated and have been resolved with the BIOS 3.05 update (also included in the ChangeLog). I’ve not seen them since I updated. In fact, my dmesg output is devoid of any errors, unlike my old ThinkPad which the FW13 replaced 
Finally someone who is (was) experiencing the exact same issue and even provides confirmation on the solution. @0xc0ffee thank you! I thought it was a software problem under Linux. Have opened up a support ticket with a link to this discussion.
2 Likes
I also have issues with the supplied 2.5g FW NIC adapter ; would be interested to see someone else who has it replicate
@Markus12 Glad this has helped, hope your issue gets resolved soon.
@jwp Could you provide a bit more detail on your issue and what makes the behaviour similar to what has been outlined in this thread?
So after almost a month of providing info, logs, photos, and videos of this issue occurring and answering some questions multiple times, Framework support was finally convinced that I was suffering from the same hardware issue as @0xc0ffee . They sent a replacement board which I installed and finally this issue appears to be gone.
P.S.: After doing a mainboard change, if the internal screen turns off shortly after showing the Framework logo during boot but can otherwise display the BIOS screens just fine, double-check the screen connector is properly seated on the board. Apparently I didn’t connect it fully and the screen was only able to display low resolution content. This really scared me at first into thinking the new board was broken as I would have expected the screen to fully work or not at all.
5 Likes
TL;DR: I had the exact same issue and it is now also resolved after I got a new mainboard. Support also requested some videos, photos and logs, but that’s all reasonable. I had a replacement mainboard in about two weeks and most of the delays were caused by myself being busy with other things and not have time to do the requested steps. So overall I’m pretty happy with the support process and how quick the responses were. During the tests the support was asking for, I noticed some new details, which aren’t mentioned in this thread yet, so I’ll write my new learnings down.
I already noticed this problem when I installed the Laptop for the first time, but back then it still had the old BIOS and I didn’t pay too much attention to it. And it then kinda “disappeared” and I forgot. It sometimes happened again, but I never found out what was triggering it. I thought it might have something to do with powersaving stuff, but couldn’t find anything and it was hard to test as it still usually didn’t happen when I was looking for it, and then it wasn’t important enough again and I kinda forgot again.
Skip forward to a few weeks ago, where I needed the USB-A port more often than usual, and suddenly it also happened every single time I wanted to connect something, and sometimes it even stopped working while a USB-stick was still plugged in. I was so confused, why it was suddenly so much worse than usual (usually when I re-connected the USB-A card it kept working for the rest or the day (or at least long enough, that I never noticed when exactly it stopped working). So it became very clear that it can’t continue like this anymore, I can’t use a laptop where the USB-A port stops working while I use it. But at least it was suddenly very reproducible.
I then also did some testing with a friend who owns a FW16, and we exchanged the USB-A card, to check if just my card is broken. But my card worked on his Laptop but his card showed the same broken behavior on mine, so it wasn’t related to the card. That’s when I also when I did some more searching in the Forum again and found this thread (which I somehow didn’t find the last time I searched). And I learned here, that apparently it’s only happening on the left side, so I tried connecting the USB-A card on the right, and indeed, it worked without breaking there. I never had the idea to try the other side, because the front-left port seems like the perfect port for an USB-A card, since it’s the only port that doesn’t support display-output (I have USB-C in both back ports, so I can charge from both sides, and had a HDMI card in the front-right … so permanently switching the sides of both front cards wasn’t an option).
I also tested with a live-Fedora and live-Ubuntu to check if the problem is reproducible there, or if it’s something in my system. And while it was reproducible on Fedora/Ubuntu (so not related to my installation), I noticed (while rebooting a lot of times) that the USB-A card doesn’t stop working if I was sitting in the BIOS, or on the bootloader-menu … it only broke as soon as I booted an actual operating system (I didn’t need to fully boot and login, loading the kernel/initrd was enough). I can only test with Linux, I don’t know about Windows? I don’t have a Windows-copy available, so I can’t test that. It’s possible that it only breaks when booting a Linux-OS and windows works (the same as the BIOS and bootloader don’t break it)? But it doesn’t matter which Linux-OS you boot, and since Fedora/Ubuntu are officially supported, and it’s broken there, it’s still broken. But this was my first new learning about this issue.
By the new learning that I can reproduce the problem on both left ports, but the card works perfectly on both right ports, I was convinced that I have the exact same problem, and opened a support request (mentioning this thread here) and asking for help for what steps are required to get a replacement board. They first asked, if the problem also happens if the charger is connected. I did the tests with the friend with the FW16 on battery, but in the week before, where I had the problem very often, I was connected to the power most of the time, so I knew it also happens with power connected. But I still did some more testing and that’s when I found the first new thing: At home, I usually have power connected on the left, and when I tested that, the problem disappeared again (that explains why I only had the problem “sometimes”, because it doesn’t happen when power is connected on the left). But in the other week, I was at a different place, and I connected power on the right (that’s the whole point of having two USB-C ports, so you can connect on whichever side is closer), and then the problem does happen (that’s why I suddenly had the problem so often). Connecting power on the left doesn’t bring the port back to life if it’s already dead, but it keeps it alive after the USB-A card was re-plugged.
So the second new learning was:
- USB-A cards stop working on the left side, if either working on battery or if power is connected on the right.
- USB-A cards keep working (if it already is in working state) on the left side, while power stays connected on the left side. It doesn’t matter if power is back or front, so even when the USB-A card is in the back-left slot, and power is front-left port, it keeps working, and breaks shortly after disconnecting power.
So it matters on which side power is connected if it breaks or if it keeps working.
The support then also asked, if I also have a similar issue with the HDMI-card, which so far I never used on the left side (where the problematic USB-Ports are). Since the front-left port doesn’t support display output, I tested the HDMI card on the back-left port, to see if it also stops working after some time. It didn’t … but what I noticed when testing that was, that the USB-A port (which was still in the front-left port and I re-plugged in the process of switching ports around) also didn’t stop working anymore. So for some reason, having the HDMI card plugged in into the other left-port, also keeps the USB-A card working, the same as if power is connected. So I also started testing other cards on the left, combined with an USB-A card.
And this is what I found out:
- USB-C doesn’t do anything (which is what I had all the time anyway), as it is just a dumb pass-through
- HDMI card, Network card and the Micro-SD card on the back-left port kept the USB-A card working on the front-left port
- A second USB-A card on the left (so both of them on the left) also keeps them working, so they somehow keep each other working … but as soon as you remove one of them, the other one stops working after a short time.
- The new big SD-Card expansion-card was special. If only the card-reader was plugged in, the USB-A card still stopped working, but if there was also a card sitting in the card reader, the USB-A port kept working. But it looks like the big SD-card reader is completely passive when nothing is in it (to save power?), it also only shows up in the USB-devices list, if an SD-card gets inserted and disappears again when the SD-card gets removed.
So the third learning was: It depends on if another active device is connected on the other left port. The empty USB-C card and the empty big SD-Card reader are both passive, so the USB-A card stops working … but the HDMI, Network, Mirco-SD, or even just a charger, are active, and if connected also on the left side, the USB-A card keeps working in the other left port.
All these new learnings looked more like a software problem (powersaving?) to me than a hardware problem that can be solved by a new board … but I already had the latest BIOS, and the support then suggested to send me a replacement board, so I thought lets just try that (as the problem also got fixed for others in this thread by a new board, there was at least a chance). And indeed, the problem is completely gone with the new board 
So maybe these new findings help somebody else when debugging this, or it might help finding the root cause why this even happens at all. And if you can’t get a new board, it shows some possible workarounds to prevent the problem from happening.