Hello,
I have this problem daily too, this is bothersome. Using Ubuntu 24.04 with kernel 6.14 right now.
Same, FW13 HX370, on Windows 11 with updated BIOS, drivers, etc.
I am also having this problem. Happens with my two USB-A cards on Framework 13 intel 11th gen, Linux Mint. I have to unplug and plug them again to get them to work. I have tried all the previous steps except for the RTC one, and none have fixed the problem. I even have TLP installed, and I messed with some of the settings, and nothing changed. Even verified all my BIOS settings made sense. Even updated my bios and nothing changed.
I have the same problem with Fedora.
Why is this thread marked [Solved]? What is the solution?
Thank you!
1 Like
I’ve a FW13 AI 370, Windows 11, batch 3, current BIOS and drivers. I’m used to having to unplug the USB-A expansion card to reconnect memory cards and the printer. And I’ve gotten used to occasionally unplugging and reconnecting the USB-C monitor and USB-C memory cards.
Roughly the same problem here with some variations:
Ryzen™ AI 5 340
Dual boot Debian 13 and Windows 11
- When a mouse plugged into the USB-A Extension Card is working under Windows, function appears to persist through any number of reboots into Windows.
- When the mouse is working under Debian, function persists through an unpredictable number of reboots into Windows or Debian, but sooner or later…
- Stops working upon an eventual reboot into Debian and does not work on either OS until…
- Unplugging and moving the USB-A extension card restores function on reboot.
An oddity that may mean nothing: in Debian with mouse in USB port working, output of “lshw” and “sudo lshw” differ with respect to the mouse:
lshw:
[…]
*-input:8
product: PixArt USB Optical Mouse
physical id: a
logical name: input8
logical name: /dev/input/event6
logical name: /dev/input/mouse2
capabilities: usb
*-input:9
product: Lid Switch
physical id: b
logical name: input9
logical name: /dev/input/event7
capabilities: platform
[…]
sudo lshw:
[…]
*-input:8
product: Lid Switch
physical id: b
logical name: input9
logical name: /dev/input/event7
capabilities: platform
[…]
For clarity: “sudo lshw” does not display the Optical Mouse input item that “lshw” does (though it displays all other input items identically), and it assigns logical name “input9” to the item under the heading of “input:8”.
Does anyone know if this dichotomy is meaningful, or if it has anything to do with the disappearing USB-A function?
Usually something is marked as solved when the mod says “we can’t replicate that problem on our end” and then ignores the issue until the end of time.
Thanks for bringing this up. Looking back at this thread, the original poster didn’t reply afterward, and the secondary OP found success with a replaced key—so when it was recently bumped, we initially marked it solved. However, we’re reverting this back to a tracking thread.
That said, we can’t effectively triage these issues within a forum thread. If you’re experiencing USB-A expansion card problems, please open a support ticket, link to this thread, and ask to have it sent directly to the Linux support team for this specific issue.
We have a triage flow in place to determine whether the issue is hardware failure, firmware-related, or user-specific configuration. From there, we can direct each individual to the appropriate next steps.
We’re actively working with engineering on USB-related concerns, and we have specific GitHub issues for tracking firmware challenges that need to be filed in the firmware tracker.
Being clear, please use tickets for support with this issue - thanks.
But what happens when support’s response is “tough luck, here’s a link to our store”?
What are the next steps then to have a working computer that cost 30-40% more than anyone else?
1 Like
I’m having the same issue on AI 300 / Bios 3.05 / Fedora. Support told me to buy a new expansion card … yeah, not great for such an expensive laptop.
After 30 e-mails with support over 8 months, they concluded that my mainboard is faulty and will send me a replacement board.
Note that support is always quick to reply, mostly on the same day. It’s just that the tasks they asked me to do required reboots, testing with Live USB distributions and 2x laptop disassembly, which are time consuming and were done by me when I had the time - once 2.5 months later.
After reviewing all of the testing you’ve completed, including reproducing the issue on a supported Fedora Live environment, testing multiple USB-A Expansion Card slots, performing a BIOS reset, mainboard reset, and power drain, as well as confirming that the USB hub functions normally on other laptops, the results point toward a hardware issue rather than a software or operating system issue.
Since the behavior is consistently reproducible on the Framework Laptop and appears to be isolated to USB-A Expansion Card functionality in ports 3 and 4, it seems likely that the mainboard is at fault.
The replacement mainboard did not help and exposes the same problem.
I can reliably reproduce the issue with my USB-A hub (i-tech “USB 3.0 HUB 3 Port + Gigabit ethernet adapter”, P/N: U3GL3SLIM):
- USB hub is connected to the laptop, power is disconnected
- put laptop to sleep, wait 10 seconds, wake it up
- disconnect the USB hub
- reconnect the USB hub (correctly detected)
- disconnect the USB hub
- reconnect the USB hub
dmesg now shows the “usb over-current condition”, and the hub is not detected anymore. Devices on the hub don’t work.
Unplugging the USB-A extension card from the laptop and replugging it makes everything work again.
# 5. disconnect USB hub the second time
[ 174.545403] usb 6-1: USB disconnect, device number 2
[ 174.545416] usb 6-1.1: USB disconnect, device number 3
[ 174.545700] ax88179_178a 6-1.1:1.0 enp195s0f3u1u1: unregister 'ax88179_178a' usb-0000:c3:00.3-1.1, ASIX AX88179 USB 3.0 Gigabit Ethernet
[ 174.570698] usb 6-1.4: USB disconnect, device number 4
[ 174.657145] usb 5-1: USB disconnect, device number 5
# 6. reconnect USB hub the second time
[ 180.038723] usb usb7-port1: over-current condition
[ 180.039288] usb usb5-port1: over-current condition
[ 180.121219] usb usb2-port1: over-current condition
[ 180.128179] usb usb1-port1: over-current condition
[ 180.128187] usb 1-1: USB disconnect, device number 2
[ 180.137186] usb usb4-port1: over-current condition
[ 180.137187] usb usb8-port1: over-current condition
[ 180.138184] usb usb6-port1: over-current condition
[ 180.142227] usb usb3-port1: over-current condition
[ 180.142239] usb 3-1: USB disconnect, device number 2
[ 180.295220] usb usb3-port2: over-current condition
[ 180.346185] usb usb4-port2: over-current condition
[ 180.423215] usb usb3-port3: over-current condition
[ 180.423226] usb 3-3: USB disconnect, device number 3
[ 180.550189] usb usb3-port4: over-current condition
[ 180.679233] usb usb3-port5: over-current condition
[ 180.679246] usb 3-5: USB disconnect, device number 4
[ 182.278700] usb 1-1: new full-speed USB device number 3 using xhci_hcd
[ 182.398701] usb 3-3: new high-speed USB device number 5 using xhci_hcd
Yeah, my experience with Framework support is the same. Long series of hoops followed by hardware replacement which may or may not resolve the problem and/or introduce new problems.
I think this issue is a design flaw (no idea if affecting all models, or some models, or what), where voltage fluctuations in the outside environment can impact the mainboard’s “ground” voltage and knock some peripherals offline.
- Running always plugged into a grounded circuit, on a grounded charger, wearing a wrist strap, and not connecting to any peripherals that are powered but not grounded, seems to cause this issue not to happen for me. Basically as long as the “ground” inside the machine is the same as any potential it encounters on the outside of the case, I don’t see this happen.
- Running from battery, or doing things that introduce stray voltages to the case (walking somewhere and coming back to the machine, carrying it somewhere new and putting it down and un-suspending it, things like that) will make it more frequent.
It’s obviously absurd for a machine this expensive to have these types of issues and support not to give substantive solutions to them, but that’s what’s up. You can mitigate it to some extent by being super-careful about the grounding situation of the machine though, it seems like. Or at least that’s what works for me.