Dead USB ports, problems shutting down

Community Support
,
1

Hi everyone,

I’m using an Intel 12th gen FW 13 with Windows 11 Version 23H2.

A couple of days ago, I ran into multiple issues at the same time:

  • My screen froze, and I could not make any inputs with my trackpad or keyboard
  • After shutting down, all of the USB ports could not transfer any data. I could not use my external mouse, keyboard, or monitor. I could only charge my laptop.
  • If the expansion cards or my charging cable were plugged in, it would take longer than usual to boot. I could also not use Bluetooth nor my camera.
  • If nothing is plugged in, it would take much less time to boot, and I could use Bluetooth and my camera.
  • Restarting or shutting down through Windows does not completely shut down my laptop. The screen would be black, but the fan still runs and the power button LED is still on. Holding down the power button is the only way to shut it down.

I’ve disconnected the battery/RAM/storage, reset the mainboard, and updated my software, but nothing has changed. Support has recommended me that I reinstall Windows. However, I’m not sure that I can even do a clean installation given that I can’t transfer any data through the ports.

I would greatly appreciate any help on this!

2

Welcome to the community @Inter!

Working with support is the best avenue as there are more than one issue going on here.

Create a Linux USB (Ubuntu, Fedora, etc.) and boot to a Live session. It the same issues persist then something is going on at a hardware or BIOS level and support is likely the only ones who can help here.

If it does not have the same issues, then Windows is corrupt and should be wiped/reinstalled.

Regardless of the situation. Ensure there is a current backup of important files.

3

Weird that I have encountered similar issue just today. Must be something with Windows update since that was the recent thing I just did yesterday. I tried BIOS update through internal drive and it didn’t work since the laptop won’t shut down without being forced to so the update never really finished. Also tried bootable USB BIOS update but the laptop won’t recognize the USB drive. :face_with_spiral_eyes:

I’d be interested in the solution as well.

4

Update: All of the problems seemed to fix themselves at once.

When I used a bluetooth mouse and keyboard to play League of Legends for the first time since the laptop had problems, my screen froze like before. I could not make any inputs with the trackpad or keyboard, so I shut down my computer. After turning it on, all of the problems were resolved, and I could use my USB accessories again. I’m pretty curious to know what happened

5

This happened to me, if nothing was plugged in then it would boot fine. If there was anything plugged into any of the sockets then it would power cycle over and over again until it timed out and then it would finally boot. None of my USB devices would do anything other than charge. I tried absolutely everything, I have included the summary I sent to Framework support below. Unfortunately it ended up being a mainboard failure and I had to replace it. Support were super helpful throughout.

Summary

My Framework Laptop 13 (13th Gen Intel Core, BIOS 3.16) has stopped exposing its USB-C Type-C subsystem to the operating system. Expansion cards no longer enumerate USB devices reliably, and /sys/class/typec/ is empty on every Linux distribution and kernel version I have tested. The Embedded Controller is otherwise alive and responsive (charging, keyboard, fans, sensors all work), but no cros-ec-typec platform device is created, so the kernel has no driver managing the Type-C ports.

I have reproduced the same fault on two different Linux distributions and two different kernel versions, ruling out an OS-specific bug.

System information

Model
Framework Laptop 13 (13th Gen Intel Core)
Mainboard
FRANMCCPA631
CPU
Intel Core i7-1360P
BIOS version
03.16 (current stable, released March 2026)
EC firmware
As shipped with BIOS 3.16
Battery
61Wh (FRANGWATA, FRANGWATO1, serial 1311105R0)
Wi-Fi
Intel AX210
NVMe
WD Black SN850X 2TB
Expansion cards
1x USB-A, 3x USB-C (all genuine Framework cards)

Observed symptoms

Expansion card enumeration

  • USB-A expansion card with USB drive plugged directly: drive does not appear in lsblk or lsusb.

  • USB-C expansion card with USB drive via a USB-A-to-USB-C adapter: drive does not enumerate, kernel reports repeated power-cycle attempts on the affected port.

  • Asymmetric per-slot behaviour: the top-right slot accepts charging input but produces no kernel events when an expansion card is inserted; the bottom-right slot produces enumeration attempts but never succeeds; other slots tested behave similarly.

Kernel-side observations

  • /sys/class/typec/ is empty (zero ports registered) on every distribution tested.

  • /sys/bus/typec/devices/ is also empty.

  • The cros_ec_typec kernel module loads successfully when manually invoked, but binds to zero devices (refcount 0). No matching platform device exists for it to bind to.

  • The list of cros-ec child platform devices includes charge-control, chardev, debugfs, dev, gpio, hwmon, led, sysfs, keyboard-leds, usbpd-charger, and usbpd-logger. There is no cros-ec-typec.X.auto device.

Specific kernel error messages

The Embedded Controller is reporting a USB-PD port count that the kernel rejects, causing the cros-usbpd-charger driver to fail probing:

cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000006

cros_ec_lpcs cros_ec_lpcs.0: got AML mutex ‘ECMT’

cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered

cros-charge-control: Framework charge control detected, preventing load

cros-usbpd-charger: No USB PD charging ports found

cros-usbpd-charger: Unexpected number of charge port count

cros-usbpd-charger: Failing probe (err:0xffffffb9)

cros-usbpd-charger: probe with driver cros-usbpd-charger failed with error -71

Error -71 is EPROTO (protocol error), indicating that the kernel and EC are not agreeing on the USB-PD port topology. This message persists across both distributions tested.

USB enumeration loop in dmesg

With a USB drive plugged in via expansion card, the kernel logs a continuous power-cycle loop:

usb usb3-port3: attempt power cycle

usb usb3-port3: unable to enumerate USB device

usb usb3-port3: attempt power cycle

usb usb3-port3: unable to enumerate USB device

[repeating every approximately 8 seconds indefinitely]

Reproduction across distributions

I reproduced the same failure on two completely different Linux distributions with different kernel versions, which strongly suggests this is a hardware or firmware issue rather than a Linux distribution bug.
Distribution
Kernel
/sys/class/typec/
cros-ec-typec device
Ubuntu 26.04 LTS
7.0.0-14-generic
Empty
Not created
Fedora 44 KDE Live
6.19.10-300.fc44
Empty
Not created

Both distributions show identical symptoms: empty /sys/class/typec/, no cros-ec-typec platform device, identical cros-usbpd-charger probe failure with the same error message, identical USB power-cycle enumeration loop on expansion card slots.

Diagnostic steps performed

Steps taken to isolate the problem

  • Tested USB-A expansion card with USB drive plugged directly: failed to enumerate.

  • Tested USB-C expansion card with USB drive via adapter: failed to enumerate.

  • Tested multiple expansion card slots, including top-right, bottom-right, with the same USB-A card and drive.

  • Confirmed top-right slot accepts charging input correctly (so PD power negotiation works on at least one slot).

  • Verified BIOS is on current stable version 3.16.

  • Manually loaded cros_ec_typec kernel module: loads successfully, binds to zero devices.

  • Inspected /sys/bus/platform/devices/ to confirm cros-ec-typec.X.auto is not created by the cros-ec MFD driver.

  • Booted Fedora 44 Live (different distro, different kernel) to rule out Ubuntu-specific issue: identical failure.

  • Inspected /sys/class/typec/ on both distributions: empty in both.

Conclusion and request

Based on the diagnostic data above, my hypothesis is one of the following:

  • EC firmware on this specific board is no longer advertising its USB-C Type-C subsystem capability through the cros-ec MFD interface, despite the rest of the EC functioning normally.

  • Hardware fault in the Type-C controller circuitry on the mainboard, with the EC detecting and disabling the Type-C subsystem.

Either way, the issue is not fixable from the OS side. The same symptoms reproduce identically across two distinct kernel versions and two distinct distributions.