Power limit for thunderbolt devices leads to external SSD reset loop

[shadowcpy]

Device Information

System Model or SKU

Please select one of the following

• Framework Laptop 13 (11th Gen Intel® Core™)
• Framework Laptop 13 (12th Gen Intel® Core™)
• Framework Laptop 13 (13th Gen Intel® Core™)
• Framework Laptop 13 (AMD Ryzen™ 7040 Series)
• Framework Laptop 13 (Intel® Core™ Ultra Series 1)
• Framework Laptop 16 (AMD Ryzen™ 7040 Series)

BIOS VERSION

UEFI: 03.18
Retimers: 0x136
PD Controllers: 0.1.2E
EC: a7cf293

DIY Edition information

Memory: 2x Crucial CT32G4SFD832A
Storage:

• Internal (M.2): Samsung 980 PRO 1TB MZ-V8P1T0
• External: 2x ADATA SE920 2TB

Port/Peripheral information

1. No expansion card -> Power Supply: Anker GaNPrime 727 120W A2148311 + Cable Anker 765 USB-C 140W A88660A1
2. LAN Network -> Framework LAN Adapter 2.5G
3. No expansion card -> USB-C Storage: ADATA SE920 2TB
4. No expansion card -> USB-C Storage: ADATA SE920 2TB

Standalone Operation

• Yes
• No

Describe the bug

Either of two attached TB4 SSDs (ADATA SE920) disconnects under heavy load (most probable due to a power limit being exceeded), and resets. While the read/write load is present, reconnecting the device does not lead to a functional operating state, only after the system is idle again, it is possible to reconnect the device.

This behaviour can be observed across all four ports of the mainboard, adding or removing USB-C expansion cards in between does not fix the issue.

Changing the power supply to multiple different variations of cable and charger does not fix the issue.

Rebooting the EC by holding the power button for 30 seconds (red/blue flash) and completely disconnecting power does not fix the issue.

Steps To Reproduce

1. Use FW mainboard in standalone mode
2. Attach 2 or more power-hungry Thunderbolt 4 SSD enclosures
3. Carry out a read/write benchmark on the SSDs at the same time (for example with dd)
4. One of the SSDs will disconnect and reset

See https://community.frame.work/t/amd-framework-and-nvme-ssd-enclosure-compatibility-investigation/41775/ for more examples

Expected behavior

Due to the specifications of Thunderbolt 4, the mainboard should be able to provide the mandatory 15W power output to support any number of devices, or negotiate a lower acceptable power limit through firmware to avoid resets.

Screenshots

See logs below

Operating System (please complete the following information):

• OS/Distribution: Proxmox VE (Debian Trixie)
• Version: 9.0.6
• Linux Kernel Version: Linux myserver 6.14.11-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.11-1 (2025-08-26T16:06Z) x86_64 GNU/Linux

Additional context

Log of the disconnects:

Sep 07 02:25:58 basalt pvedaemon[2542]: <root@pam> starting task UPID:basalt:00001BEC:0000C8CF:68BCD116:qmrestore:201:root@pam:
Sep 07 02:27:06 basalt kernel: pcieport 0000:00:07.1: pciehp: Slot(4): Link Down
Sep 07 02:27:06 basalt kernel: pcieport 0000:00:07.1: pciehp: Slot(4): Card not present
Sep 07 02:27:06 basalt kernel: thunderbolt 0-0:3.1: retimer disconnected
Sep 07 02:27:06 basalt kernel: thunderbolt 0-3: device disconnected
Sep 07 02:27:06 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] disconnected (/sys/devices/pci0000:00/0000:00:0d.2/domai>
Sep 07 02:27:06 basalt kernel: zio pool=tank vdev=/dev/disk/by-id/nvme-eui.0000000000000000707c18002512911d-part1 error=5 type=2 offset=>
Sep 07 02:27:06 basalt kernel: zio pool=tank vdev=/dev/disk/by-id/nvme-eui.0000000000000000707c18002512911d-part1 error=5 type=2 offset=>
Sep 07 02:27:06 basalt kernel: zio pool=tank vdev=/dev/disk/by-id/nvme-eui.0000000000000000707c18002512911d-part1 error=5 type=2 offset=>
Sep 07 02:27:06 basalt kernel: pci_bus 0000:2d: busn_res: [bus 2d] is released
Sep 07 02:27:06 basalt kernel: pci_bus 0000:2c: busn_res: [bus 2c-2d] is released
Sep 07 02:27:08 basalt kernel: thunderbolt 0-3: new device found, vendor=0xb8 device=0x2463
Sep 07 02:27:08 basalt kernel: thunderbolt 0-3: ADATA ADATA SE920
Sep 07 02:27:08 basalt tbtacl[7621]: 7619: args: add /devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-3
Sep 07 02:27:08 basalt zed[7629]: eid=32 class=statechange pool='tank' vdev=nvme-eui.0000000000000000707c18002512911d-part1 vdev_state=R>
Sep 07 02:27:08 basalt zed[7631]: eid=33 class=removed pool='tank' vdev=nvme-eui.0000000000000000707c18002512911d-part1 vdev_state=REMOV>
Sep 07 02:27:08 basalt tbtacl[7638]: 7619: authorizing /sys/devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-3
Sep 07 02:27:08 basalt tbtacl[7640]: 7619: not in ACL
Sep 07 02:27:08 basalt (udev-worker)[7618]: 0-3: Process '/usr/lib/udev/tbtacl add    /devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-3' >
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] parent is 65e08780-4096...
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] connected: connected (/sys/devices/pci0000:00/0000:00:0d>
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] auto-auth: authmode: enabled, policy: iommu, iommu: yes >
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] auto-auth: security: iommu+user mode, key: no -> ok
Sep 07 02:27:08 basalt boltd[1751]: probing: started [1000]
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] authorize: authorization prepared for 'user' level
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] udev: device changed: authorizing -> authorizing
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] udev: device changed: authorizing -> authorizing
Sep 07 02:27:08 basalt postfix/pickup[2486]: 280D221C01E7: uid=0 from=<root>
Sep 07 02:27:08 basalt postfix/cleanup[7675]: 280D221C01E7: message-id=<20250907002708.280D221C01E7@****>
Sep 07 02:27:08 basalt zed[7694]: eid=34 class=config_sync pool='tank'
Sep 07 02:27:08 basalt postfix/qmgr[2487]: 280D221C01E7: from=<root@****>, size=865, nrcpt=1 (queue active)
Sep 07 02:27:08 basalt proxmox-mail-forward[7696]: could not notify via target `reports-internal`: could not notify via endpoint(s): rep>
Sep 07 02:27:08 basalt postfix/local[7695]: 280D221C01E7: to=<root@****>, orig_to=<root>, relay=local, delay=0.06, delays=0.0>
Sep 07 02:27:08 basalt postfix/qmgr[2487]: 280D221C01E7: removed
Sep 07 02:27:08 basalt kernel: thunderbolt 0-0:3.1: new retimer found, vendor=0x8087 device=0x15ee
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] authorize: finished: ok (status: authorized, flags: 0)
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] auto-auth: authorization successful
Sep 07 02:27:08 basalt tbtacl[7699]: 7698: args: change /devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-3
Sep 07 02:27:08 basalt tbtacl[7711]: 7698: no childs found
Sep 07 02:27:08 basalt (udev-worker)[7618]: 0-3: Process '/usr/lib/udev/tbtacl change /devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-3' >
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] udev: device changed: authorized -> authorized
Sep 07 02:27:08 basalt kernel: thunderbolt 0-0:3.1: retimer disconnected
Sep 07 02:27:08 basalt boltd[1751]: [124c4c17-b07d-ADATA SE920                ] disconnected (/sys/devices/pci0000:00/0000:00:0d.2/domai>
Sep 07 02:27:08 basalt kernel: thunderbolt 0-3: device disconnected
Sep 07 02:27:10 basalt kernel: thunderbolt 0-3: new device found, vendor=0xb8 device=0x2463
Sep 07 02:27:10 basalt kernel: thunderbolt 0-3: ADATA ADATA SE920
Sep 07 02:27:10 basalt tbtacl[7715]: 7714: args: add /devices/pci0000:00/0000:00:0d.2/domain0/0-0/0-3
... continued attempts