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?