Weird USB and Power Management issues

Since a day or two I have the weirdest USB issues.

The main issue is that USB 1.x or 2.0 devices don’t work on usb ports on the left side of my laptop. Both ports have the same issue, and it doesn’t seem to matter if they’re USB-A or USB-C, or full speed or high speed. USB 3.x Superspeed devices work perfectly fine on all ports. PD and DP Alt Mode also still work fine.

Note, I’m running Linux. Specifically Fedora 36, kernel 5.19.8. So there won’t be Device Manager screenshots, but there will be dmesg output.

“doesn’t work” means that the device doesn’t enumerate at all. Complete silence in dmesg.

Power still works. Power indicator leds on devices turn on as usual. In some cases, these appear in dmesg:

[ 1149.445113] usb usb2-port4: attempt power cycle
[ 1157.902143] usb usb2-port4: unable to enumerate USB device

This suggests something weird related to power management is happening. Which brings me to the next related issue. When I try to suspend my laptop, it fails to do so. This happens in dmesg:

[  622.030899] PM: suspend entry (s2idle)
[  622.043061] Filesystems sync: 0.012 seconds
[  622.187256] Freezing user space processes ... (elapsed 0.002 seconds) done.
[  622.190002] OOM killer disabled.
[  622.190004] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  622.191474] printk: Suspending console(s) (use no_console_suspend to debug)
[  622.200345] usb usb3: PM: dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
[  622.200352] usb usb3: PM: failed to suspend async: error -16
[  622.362417] PM: Some devices failed to suspend, or early wake event detected
[  623.304117] PM: resume devices took 0.942 seconds
[  623.304128] OOM killer enabled.
[  623.304130] Restarting tasks ... done.
[  623.317238] PM: suspend exit
[  623.317321] PM: suspend entry (s2idle)
[  623.325823] Filesystems sync: 0.008 seconds
[  623.329271] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  623.330903] OOM killer disabled.
[  623.330903] Freezing remaining freezable tasks ... (elapsed 0.106 seconds) done.
[  623.437644] printk: Suspending console(s) (use no_console_suspend to debug)
[  623.448166] usb usb3: PM: dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
[  623.448181] usb usb3: PM: failed to suspend async: error -16
[  623.610414] PM: Some devices failed to suspend, or early wake event detected
[  623.889863] PM: resume devices took 0.280 seconds
[  623.889872] OOM killer enabled.
[  623.889874] Restarting tasks ... done.
[  623.902241] PM: suspend exit

Yes, always twice. I guess the kernel hopes it’s just a random glitch and tries again? Not in this case.

Then there’s the third issue. I have a MicroSD expansion card. When it’s plugged in (without a card in it), the system refuses to shut down. All processes quit, filesystems unmount, etc. Then it just waits for something. But when I unplug the card during this wait, the poweroff continues successfully. This also feels like usb power management weirdness. But the extra weird thing is that this happened with a USB 3.x device which works fine on any port, and it was plugged in on the right side, while the weirdness was happening on the left side.

Now there is something that might be part of the cause. All of this started happening after I tried plugging in an esp32 devboard. Which might be broken. It’s a cheap noname thing from a random seller on AliExpress so who knows. But even if it’s broken, that shouldn’t take down the usb controller inside my laptop. The led on that esp32 board still turns on, so it’s not a dead short or anything like that. But even if it was, I expect a laptop to just temporarily shut down that port and not suffer any permanent damage.

So, what the heck happened here? I guess I should contact Framework Support, but I wanted to share this here first to maybe get some ideas of what might possibly be happening here. Because even if something is broken, the way the issues show up is just very weird and I don’t understand what I am even looking at.

It is now one day later and because of reasons nobody will ever understand everything is now working perfectly fine again.

…for now.

Nope, I can reproduce this issue. Other devboards with CP210x usb-serial adapters cause the same issue.
I’ve seen it with both cp2102 and cp2104. The exact same boards work perfectly fine on every other non-framework laptop I tried it with. I’ll try testing it on other frameworks, maybe sometime next week (if my friends let me temporarily bung up their usb ports that is).