Hi all,
After this morning’s update, all USB-C ports on my laptop stopped working — devices get no power and aren’t detected. USB-A ports continue to work normally. Looking for help narrowing down whether this is a known regression or something specific to my setup.
Hardware
- Laptop: AiStone X6AR57TY
- BIOS: N.1.17PCS12
- CPU: Intel Core Ultra 9 275HX (Arrow Lake-HX)
- GPU: Intel Arrow Lake-S iGPU + NVIDIA GeForce RTX 5070 Ti Mobile (GB205M)
- RAM: ~128 GB
- Network: Intel Arrow Lake-S CNVi Wi-Fi, Realtek RTL8125 2.5GbE
- Thunderbolt 4 controllers:
00:0d.0(TB4 USB Controller, 8086:7ec0) and00:0d.2(TB4 NHI, 8086:7ec2) - PCH xHCI for USB-A:
80:14.0(8086:7f6e)
Software
- Qubes OS 4.3 (i3 as WM in dom0)
- All three USB controllers attached to sys-usb
- sys-usb template is on Fedora 43 (fc43)
- Currently running dom0 kernel
6.19.14-1.qubes.fc41(rollback to 6.19.5-1 did not help)
Symptom
- USB-A ports: working
- USB-C ports: no power, no enumeration. A USB-C device with a power LED stays off when plugged in.
- Was working before this morning’s update. (Pre-existing issue with TB docks specifically, but plain USB-C devices were fine until today.)
What changed today (dnf history transaction 27)
Dom0:
- Installed:
kernel-1000:6.18.31-1.qubes.fc41(not booted, still on 6.19.x) - Upgraded:
qubes-core-admin-client4.3.30 → 4.3.31,python3-qubesadmin4.3.30 → 4.3.31 - Upgraded: several firmware packages from 20260410 → 20260519 (intel-gpu-firmware, intel-audio-firmware, nvidia-gpu-firmware, amd-ucode-firmware, etc. — no thunderbolt-related blobs)
Inside sys-usb template (fc43):
qubes-core-agent-*4.3.43-1python3-qubesadmin4.3.31-1- Firmware packages (20260519)
Investigation so far
PCI assignment is correct — qvm-pci shows both TB controllers attached to sys-usb with no-strict-reset=True.
Inside sys-usb:
lspcishows the TB4 USB controller (00:06.0) and NHI (00:07.0) present.dmesgshowsxhci_hcd 0000:00:06.0initializing normally and athunderbolt 0000:00:07.0: device links to tunneled native ports are missing!warning./sys/bus/thunderbolt/devices/containsdomain0and0-0(host router).- Security level:
user. lsusb -tshows the TB USB controller buses present but with no devices ever appearing when something is plugged into a USB-C port.
Initially I thought it was a missing bolt daemon (was not installed in sys-usb post-update). Installed it; boltctl list returns empty even when a USB-C device is connected, suggesting the device never gets detected at the TB link layer in the first place.
Type-C subsystem state:
- dom0 has
/sys/class/typec/with port0, port1, partners, plugs, cables. - sys-usb has
ucsi_acpi,typec_ucsi,typecmodules loaded but no/sys/class/typec/directory.
So dom0 owns the Type-C ports (via UCSI/ACPI) and sys-usb owns the USB and TB controllers — which is presumably the working split. Something in today’s update appears to have broken the handoff between them.
Kernel command line (and why)
intel_pmc_core.disable=1 initcall_blacklist=intel_pmc_ssram_telemetry_driver_init module_blacklist=intel_pmc_ssram_telemetry rd.qubes.hide_all_usb
The intel_pmc_* parameters were added against kernel 6.19.4-1 (R4.3-rc4) to avoid a boot panic. They may no longer be required on current kernels, but they were already in place when USB-C was working yesterday, so I don’t think they’re related to today’s regression.
Question
Has anyone else seen USB-C break after a recent update on Qubes 4.3? Or is there a known interaction between qubes-core-admin-client 4.3.31 / qubes-core-agent 4.3.43 and Thunderbolt/USB-C passthrough that I should be aware of?
Happy to provide further logs (full dmesg, qvm-pci, etc.) if useful.
Thanks!