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).

@Peetz0r Hello!! This was refreshing because I’ve been pounding my head on my keyboard for a week trying to figure this out. I’m seeing the exact same thing, and I seemingly can’t use my DisplayPort expansion card because of it?

I never made the connection on my own but I have used an Arduino Nano as a ICSP and that’s right about when everything started to act really weird.

Crossing my fingers you found a fix because this is driving me nuts.

as a BTW - every now and then my DP stuff will be entirely fine for like 15-30 mins? but eventually goes right back

I’m happy to help however I can. If it happens again, lose the other board and test a live USB to make sure the hardware is unaffected.

@Matt_Hartley I’ve been seeing much of the same - even hopped from Debian to Fedora hoping that would fix the issue.

I’ve tried just about everything, even like you said removing my ICSP when the issues presented themselves but no luck. My DP expansion card (when nothing is plugged into it) will show up in “lsusb” but the moment I plug my single monitor into it it disappears with no acknowledgment from the OS that a monitor existed. At the start of the week I had ~1 hour where I could use the monitor w/ the framework (and it worked great!) but it didn’t last long

I’ve had a pretty frustrating experience with the USB side of my framework in general, as it also seems to continuously fail to even properly eject a USB drive in which I had just copied files to, often leaving the files corrupt.

As mentioned before I’m on Fedora, but had previously had Ubuntu installed and saw the same issues. Thanks for your help.

Edit: Will also add that my dmesg mirrors that of @Peetz0r when the DP doesn’t work, suggesting I should power cycle.

Looking at my DP connected to a monitor right now. Not having any luck duplicating this. This could be a specific issue with your modules or motherboard.

Please provide the these details so I can work to replicate this as much as possible:

Distros: Which exact distros/versions and kernels were tested? Fedora specifically, was this Fedora 37 and which kernel was in use?

DP connection: Is this DP cable without hubs and adapters? This is how I connect as it is always going to be the best bet.

Thanks

Distro: Fedora 37 w/ Kernal 6.0.12-300. Saw the same behavior on Ubuntu 22.04.1, I dont remember the kernal specifics there, though.

Connection: Straight display port to monitor. I’m using a Samsung S22E450 monitor which is nothing crazy, 1920x1080 I believe.

Let me know if theres anytjing else I cam provide, i really appreciate the help!

Once the monitor is plugged in, does it no longer show in lsusb?

That’s correct - if it does show up in lsusb, 90% of the time I plug in the DisplayPort cable from my monitor it disappears from lsusb and tosses the dmesg messages. The other 10% is when the DP works fine. But if the machine idles or reboots, I’m right back to the same behavior.

HDMI seems to be iffy too. I have an HDMI-to-DP and even trying on multiple monitors that doesn’t seem to do much. Sometimes it looks like both the monitor and framework are trying (ie monitor comes out of idle, framework starts to re-size screen like normal when a new monitor is plugged in) but nothing really comes of that either. I think the HDMI disappears significantly less though. I can retest and report back tomorrow.

I’ve had a bad DP card recently, so that matches. I would definitely pursue a replacement DP card if it’s ever disappearing from lsusb. Just open a ticket and reference this post as a need for the replacement - it’s definitely a bad DP if this is failing and disappearing from lsusb.

For HDMI, I have had no issues simply using two HDMI expansion cards. They’ve performed well for me.