USB host controller not enumerating in early boot on Apple Silicon M1 with kernel 6.18.10 (USB root broken, works on 6.17)

Description:

On Apple Silicon M1 (Asahi Linux), booting with kernel 6.18.10 breaks USB in early boot.
When the root filesystem is on a USB SSD, the system drops into the initramfs/emergency shell because the root device is not found. The USB bus is not enumerated at all in early boot.

This works reliably with 6.17.12, but fails with 6.18.10.

Observed behavior (6.18.10):

Kernel: 6.18.10-1-1-ARCH (aarch64, Asahi)

In early boot / initramfs:

/sys/bus/usb/devices is empty
/sys/class/scsi_host is empty
No /dev/sdX devices appear

dmesg shows:

usbcore, usb-storage, and uas drivers are registered
xhci_hcd and xhci_plat_hcd initcalls run
But no USB root hub / host is actually registered and no devices are enumerated

Result: root=UUID=… on USB cannot be found, boot drops to emergency shell.

Expected behavior:

USB host controller should be initialized in early boot
USB bus should appear in /sys/bus/usb/devices
USB storage should be enumerated and /dev/sdX should appear
Booting with root on USB should work (as it does on 6.17.12)

Regression:

6.17.12: USB root works, USB is enumerated normally in early boot
6.18.10: USB host not enumerated in early boot, USB root impossible

Additional notes:

The same USB SSD works fine with 6.18.10 when booting from internal NVMe and mounting the device later (i.e. USB works in the fully booted system).

This appears to be specific to early boot / initramfs / host controller bring-up.

Boot bundle (m1n1/DTBs) was updated and verified; the correct ESP is used.

The kernel version actually booted is confirmed via uname -a.

dmesg (early boot) shows xhci_hcd init but no actual host/bus registration.

Hardware:

Apple Silicon MacBook Pro M1 (Asahi Linux)

USB SSD: Silicon Motion / Feiya bridge (VID:PID 090c:2320)
(But the issue seems to be at host controller level, not storage/UAS.)

Steps to reproduce:

Install Asahi Linux with root filesystem on a USB SSD.

Boot with kernel 6.18.10. → System drops to emergency shell: root device not found.

Check:

/sys/bus/usb/devices → empty
/sys/class/scsi_host → empty

Boot same setup with kernel 6.17.12 → USB root works.

i wonder if this is related to the gentoo asahi livecd not working. it is 6.18.5, but i checked building it with 6.18.8 didn't work either.

Based on upstream (#asahi-dev irc channel) discussion, this issue will probably be solved by AsahiLinux/asahi-installer#414.

Does the boot from USB rootfs use a separate uefi-only install? Then it's likely that it uses 6.17 DTBs in $ESP/m1n1/boot.bin. You can verify it with find /proc/device-tree/soc*/i2c* -name port. That will be empty with the 6.18 DTBs but have one result per USB type-c port for 6.17 DTBs (and vice versa for ports as name).
The install on the USB rootfs is expected to refresh $ESP/m1n1/boot.bin. As a workaround you can manually replace it with the boot.bin from https://github.com/AsahiLinux/m1n1/actions/runs/22668119346 (double unzip)
The same workaround will work for Gentoo asahi livecd. AsahiLinux/asahi-installer#414 will by itself not fix anything. It will just avoid the issue for new uefi-only installs once everything is in place.

Does the boot from USB rootfs use a separate uefi-only install? Then it's likely that it uses 6.17 DTBs in $ESP/m1n1/boot.bin. You can verify it with find /proc/device-tree/soc*/i2c* -name port. That will be empty with the 6.18 DTBs but have one result per USB type-c port for 6.17 DTBs (and vice versa for ports as name). The install on the USB rootfs is expected to refresh $ESP/m1n1/boot.bin. As a workaround you can manually replace it with the boot.bin from https://github.com/AsahiLinux/m1n1/actions/runs/22668119346 (double unzip) The same workaround will work for Gentoo asahi livecd. AsahiLinux/asahi-installer#414 will by itself not fix anything. It will just avoid the issue for new uefi-only installs once everything is in place.

Thank you for your justification. This is exactly my case (UEFI-only installation + DTBS under /proc/device-tree/soc*/i2c*). I will try your solution later.

Does the boot from USB rootfs use a separate uefi-only install? Then it's likely that it uses 6.17 DTBs in $ESP/m1n1/boot.bin. You can verify it with find /proc/device-tree/soc*/i2c* -name port. That will be empty with the 6.18 DTBs but have one result per USB type-c port for 6.17 DTBs (and vice versa for ports as name). The install on the USB rootfs is expected to refresh $ESP/m1n1/boot.bin. As a workaround you can manually replace it with the boot.bin from https://github.com/AsahiLinux/m1n1/actions/runs/22668119346 (double unzip) The same workaround will work for Gentoo asahi livecd. AsahiLinux/asahi-installer#414 will by itself not fix anything. It will just avoid the issue for new uefi-only installs once everything is in place.

I have Asahi minimal on my internal nvme partition. EFI on a second internal partition, mounted at /boot/efi
tried your suggestions, but unfortunately no luck.

boot.bin (on the efi partition) was definitely updated by update-m1n1. but I also tried replacing it with the download.

what else I tried:
reinstalled linux asahi 6.18.10-1-1

mkinitgpio -P
update-m1n1

checked that drivers are present.

in the emergency shell
name -r -> 6.18.10-1-1-ARCH

the device tree gives:
../connector/ports:
port@0
port@1

503000000.phy modalias: Capple, t8103-atcphy
phy-apple-atc binds to 503000000.phy, but registering 503000000.phy-mux gives -> EEXIST
no *phy-mux* to be found though.
unbind 503000000.phy -> "No such device"
USB host -> waiting_for_supplier

@jannau

@jannau I have a similar result to @ushi909's. With my latest LiveCD after updating the boot.bin manually, the find /proc/device-tree/soc*/i2c* -name port command outputs are empty which shows that I am using 6.18.* DTBs. However, my USB port still doesn't work. My kernel is 6.18.10 as well.

updated to 6.18.15-1-1-ARCH
unfortunately same issue

Same problem here, find /proc/device-tree/soc*/i2c* -name port returns nothing, while I am on 6.18.15-400. Wondering if this may be a result of updated firmware? I copied it maybe two weeks ago as I was trying to get the ALS to work.

OK, so my issue looks like a similar, but unrelated one. Specifically USB actually does work here, with /dev/bus populated until I suspend. After resuming, /dev/bus is gone. Doesn't look like there's anything in dmesg that would suggest any issue:

[  721.145822] PM: suspend devices took 0.210 seconds
[  721.172780] macsmc 23e400000.smc: RTKit: syslog message: apComms.cpp:354: SMC HID Event: 03 00 01
[  721.173156] apple-pmgr-pwrstate 23b700000.power-management:power-controller@1e0: PS fpwm1: Failed to reach power state 0xf (now: 0x80f)
[  721.200212] nvme-apple 27bcc0000.nvme: RTKit: Initializing (protocol version 12)
[  721.258232] nvme-apple 27bcc0000.nvme: RTKit: syslog message: cmd.c:6546:  boot mode normal
[  721.308606] PM: resume devices took 0.109 seconds
[  721.308812] OOM killer enabled.
[  721.308818] Restarting tasks: Starting
[  721.310813] Restarting tasks: Done
[  721.310824] efivarfs: resyncing variable state
[  721.311218] efivarfs: finished resyncing variable state
[  721.311247] random: crng reseeded on system resumption
[  721.311258] PM: suspend exit
[  721.359097] apple-dcp 231c00000.dcp: dcp_poweron() starting
[  721.359270] apple-dcp 231c00000.dcp: RTKit: syslog message: nifiedPipeline.cpp:1356: set_device_enabled_gated: current state: 0, requested state: 1
[  721.359603] apple-dcp 231c00000.dcp: RTKit: syslog message: PPipeDCP_H13P.cpp:10468: set_run_mode_safe: no need to defer: 0 -> 1
[  721.359643] apple-dcp 231c00000.dcp: RTKit: syslog message: ock_Tunables_v1.cpp:651: IOMFB: Writing tunables with target 4
[  721.360268] apple-dcp 231c00000.dcp: RTKit: syslog message: PPipeDCP_H13P.cpp:10468: set_run_mode_safe: no need to defer: 1 -> 2
[  721.360546] apple-dcp 231c00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:237: bool VideoInterfaceIOAV::open_ioav_gated(): IOAVVideoInterface open failed
[  721.360551] apple-dcp 231c00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:296: IOMFB: VideoInterfaceIOAV::power_on: m_power_ctrl->setPower( 1 )
[  721.360957] apple-dcp 231c00000.dcp: RTKit: syslog message: AppleDCPDPTX.cpp:355: [AFK]powering nub 0x884d98
[  721.361096] apple-dcp 231c00000.dcp: RTKit: syslog message: AppleDCPDPTX.cpp:355: [AFK]powerin
[  721.362428] apple-dcp 231c00000.dcp: dcp_set_power_state_req returned, 4997 ms remaining
[  721.362432] apple-dcp 231c00000.dcp: set_digital_out_mode(color:1 timing:2) "2560x1600": 60 266630 2560 2568 2600 2642 1600 1632 1640 1682 0x48 0x0
[  721.362434] apple-dcp 231c00000.dcp: set_digital_out_mode() color mode depth:8 format:0 colorimetry:16 eotf:0 range:0 vrr:0
[  721.362517] apple-dcp 231c00000.dcp: RTKit: syslog message: nifiedPipeline.cpp:7462: set_digital_out_mode: Modeset requested for colorID: 1, timingID: 2
[  721.362544] apple-dcp 231c00000.dcp: RTKit: syslog message: PPipeDCP_H13P.cpp:18011: Dual pipe disabled offset 0
[  721.362553] apple-dcp 231c00000.dcp: RTKit: syslog message: nifiedPipeline.cpp:7465: set_digital_out_mode returned 8000000b
[  721.362588] apple-dcp 231c00000.dcp: set_digital_out_mode finished:8500
[  721.512086] apple-dcp 231c00000.dcp: RTKit: syslog message: ileCDIDPDisplay.cpp:119: [AFK]SAC enable: DP=1 CDI=1
[  721.512105] apple-dcp 231c00000.dcp: RTKit: syslog message: DCPDP13Service.cpp:60: [AFK]version: 13
[  721.512109] apple-dcp 231c00000.dcp: RTKit: syslog message: DCPDPService.cpp:76: [AFK]version: 13
[  721.547106] apple-dcp 231c00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:135: IOMFB: IOAVVideoInterface published
[  721.547120] apple-dcp 231c00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:714: IOMFBStatus VideoInterfaceIOAV::plug_gated(IOAVVideoInterface *, bool): display HPD asserted
[  721.552677] apple-dcp 231c00000.dcp: RTKit: syslog message: PPipeDCP_H13P.cpp:10490: set_run_mode_safe: deferring: 2 -> 4
[  721.552690] apple-dcp 231c00000.dcp: RTKit: syslog message: PPipeDCP_H13P.cpp:10395: virtual IOMFBStatus IOMFB::UPPipeDCP_H13P::ready_for_run_mode_change(IOMFB::AppleRegisterStream *): initiating deferred run mod
[  721.552764] apple-dcp 231c00000.dcp: RTKit: syslog message: M3Hal_v1.cpp:197: IOMFB: load APT M3 IMem : size 0x7948
[  721.552951] apple-dcp 231c00000.dcp: RTKit: syslog message: M3Hal_v1.cpp:197: IOMFB: load APT M3 DMem : size 0x6f60
[  721.553121] apple-dcp 231c00000.dcp: RTKit: syslog message: CAHandler.cpp:188: IOMFB load_ca_data: Unrecognized data version 0 (expected 1 or 2)
[  721.553490] apple-dcp 231c00000.dcp: RTKit: syslog message: UPPipe.cpp:3767: IOMFB read_pmu_data_sync: pmu ram read error (e00800d8)
[  721.553745] apple-dcp 231c00000.dcp: RTKit: syslog message: PPipeDCP_H13P.cpp:14085: IOMFB Int RTBandwidth: program_M3_rt_config: Using Legacy, scratch 23b738014
[  721.553752] apple-dcp 231c00000.dcp: RTKit: syslog message: PPipeDCP_H13P.cpp:14105: IOMFB Int RTBandwidth: using legacy. Doorbell 23bc3c000, bit 2
[  721.553791] apple-dcp 231c00000.dcp: RTKit: syslog message: UPTSQManager.cpp:133: IOMFB: clearing M3 reset
[  721.553886] apple-dcp 231c00000.dcp: RTKit: syslog message: UPTSQ_Hal_v1.cpp:349: IOMFB: timebase_offset = 4
[  721.569451] apple-dcp 231c00000.dcp: RTKit: syslog message: UPTSQManager.cpp:105: IOMFB: switch to normal mode succeeded
[  721.571416] apple-dcp 231c00000.dcp: RTKit: syslog message: ock_PCC2DLTM_v1.cpp:910: IOMFBStatus IOMFB::UPBlock_PCC2DLTM_v1::set_mcpu_power(IOMFB::AppleRegisterStream *, bool) Loading M3 Hal
[  721.571422] apple-dcp 231c00000.dcp: RTKit: syslog message: M3Hal_v1.cpp:197: IOMFB: load LTM M3 IMem : size 0x8ebc
[  721.571955] apple-dcp 231c00000.dcp: RTKit: syslog message: M3Hal_v1.cpp:197: IOMFB: load LTM M3 DMem : size 0xedd8
[  721.607813] apple-dcp 231c00000.dcp: RTKit: syslog message: PPipeDCP_H13P.cpp:17179: handle_stage1_enable blm_en 0 ltm_en 1

Is it possible that USB root doesn't come back from sleep/device tree is misconfigured?

EDIT. While I was investigating another issue (#473) related to suspending, I noticed this happened there:

[141807.998930] PM: suspend exit
[141808.610784] ieee80211 phy0: brcmf_p2p_set_firmware: failed to update device address ret -52
[141808.613487] ieee80211 phy0: brcmf_p2p_create_p2pdev: set p2p_disc error
[141808.613491] ieee80211 phy0: brcmf_cfg80211_add_iface: add iface p2p-dev-wlp1s0f type 10 failed: err=-52
[141838.450310] macsmc 23e400000.smc: RTKit: syslog message: apComms.cpp:354: SMC HID Event: 03 00 01
[141866.615163] macsmc-power macsmc-power: Port 2 state change (charge port: 255)
[141866.615193] macsmc-power macsmc-power: Connector event: Port 2 (status 0x02)
[141866.615462] macsmc-power macsmc-power: Connector event: Port 2 (status 0x03)
[141866.616693] macsmc 23e400000.smc: RTKit: syslog message: aceElec.cpp:1123: 	Elec: Elec Cause 0x0
[141866.634907] macsmc-power macsmc-power: Connector event: Port 2 (status 0x05)
[141867.119501] xhci-hcd xhci-hcd.2.auto: remove, state 4
[141867.119522] usb usb2: USB disconnect, device number 1
[141867.120282] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered
[141867.121540] xhci-hcd xhci-hcd.2.auto: remove, state 4
[141867.121544] usb usb1: USB disconnect, device number 1
[141867.168360] xhci-hcd xhci-hcd.2.auto: Host halt failed, -110
[141867.168373] xhci-hcd xhci-hcd.2.auto: Host controller not halted, aborting reset.
[141867.172032] xhci-hcd xhci-hcd.2.auto: USB bus 1 deregistered
[141868.064506] PM: suspend entry (s2idle)
[141868.085255] Filesystems sync: 0.020 seconds
[141868.089877] Freezing user space processes

Has anyone tried rebuilding U-Boot with newer 6.18 kernel dtbs?
This is what let me get back USB on my M1 Air with 6.18 kernels.
I can attach my U-Boot build if anyone wishes, but it's with an M1 Air DTB from 6.18 since USB was changed there.
~~Note, I havent checked if it functions fully but dmesg looks good. I will check soon and update here.~~

Can confirm USB 2 and 3.x both work fine now. Just need to update U-Boot DTBs with newer 6.18 dtbs for the fix.

AsahiLinux/u-boot#31

I have created a pull request on the AsahiLinux u-boot with the required fix. Hopefully gets merged or, the fix is just added.

@ObiKeahloa

@ObiKeahloa surprised this is even needed, I was under impression u-boot was kept up to date to match the current kernel and its device tree?

@ObiKeahloa

@ObiKeahloa I built u-boot from your repo and also built the DTBs fresh from AsahiLinux. Unfortunately on my Apple M1 MBP (2020) the regression persists. Still no USB in early boot. Between 6.17 and 6.18, 502280000.usb no longer transitions into a working xHCI host. Under 6.17 it creates xhci-hcd.0.auto and USB boot works; under 6.18 it stays present but never binds to xHCI, so root-on-USB fails.

I found a solution for my issue. The early boot path was using the wrong driver stack in initramfs

dwc3_of_simple was used instead of dwc3_apple.
adding dwc3_apple to MODULES in mkinitcpio.conf in my minimal boot system fixed it.

strangely, 6.17.x was working with the same configuration, so apparently something changed, which requires a new configuration for 6.18.x

@uschi909

@uschi909 I wouldn't mark it as completed, it probably requires some upstream changes in configuration?

How about sleep mode? In my configuration after suspend drive was unmount forever, but early (in 6.17) after wake up drive have been mounted.

@uschi909

@uschi909

I agree with @wrobelda it is too early to close this issue, U-boot hasn't yet updated the DTBs and the issue may persist should someone update normally.

@ObiKeahloa surprised this is even needed, I was under impression u-boot was kept up to date to match the current kernel and its device tree?

AFAIK it usually is, seems like it was forgotten this time? Genuinely no clue whats going on.

Merge branch 'selftests-bpf-convert-test_tc_tunnel-sh-to-test_progs'

Navigation Menu

Repository navigation

USB host controller not enumerating in early boot on Apple Silicon M1 with kernel 6.18.10 (USB root broken, works on 6.17) #454

Description:

Expected behavior:

Regression:

Additional notes:

Hardware:

Steps to reproduce:

Check:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

USB host controller not enumerating in early boot on Apple Silicon M1 with kernel 6.18.10 (USB root broken, works on 6.17) #454

Description

Description:

Expected behavior:

Regression:

Additional notes:

Hardware:

Steps to reproduce:

Check:

Activity

discapes commented on Feb 25, 2026

ArchieMeng commented on Mar 4, 2026

jannau commented on Mar 4, 2026

ArchieMeng commented on Mar 4, 2026

uschi909 commented on Mar 4, 2026

ArchieMeng commented on Mar 6, 2026

uschi909 commented on Mar 6, 2026

wrobelda commented on Mar 30, 2026

wrobelda commented on Mar 31, 2026

ObiKeahloa commented on Mar 31, 2026

ObiKeahloa commented on Mar 31, 2026

wrobelda commented on Apr 1, 2026

uschi909 commented on Apr 1, 2026

uschi909 commented on Apr 4, 2026

wrobelda commented on Apr 4, 2026

zavrik965 commented on Apr 4, 2026

ObiKeahloa commented on Apr 7, 2026

ObiKeahloa commented on Apr 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions