NVMe I/O timeouts and slow boot on ASUS Zenbook with Micron MTFDKBA1T0QGN

Ask Fedora
1

Hi,

I’m experiencing NVMe I/O timeouts on a brand new ASUS Zenbook 14 UX3405CA running Fedora Kinoite (via Aurora DX stable, version 43.20260408.1).

Hardware:

  • Machine: ASUS Zenbook 14 UX3405CA_UX3405CA (1.0)
  • CPU: Intel Core Ultra 9 285H
  • NVMe: Micron MTFDKBA1T0QGN-1BN1AABGA, Firmware V8MA000 (VID: 0x1344)
  • Kernel: 6.19.7-200.fc43.x86_64
  • Filesystem: btrfs + LUKS

Symptoms:

Without any kernel parameters, boot takes ~76 seconds, entirely in NVMe/device enumeration. Journal shows recurring timeouts during first app launch:

kernel: nvme nvme0: I/O tag 656 (7290) QID 4 timeout, completion polled

The NVMe is connected via Intel’s PCIe fabric at 10000:e1:00.0 (not a standard 0000: bus), which may be relevant.

First launch of any app (Firefox, etc.) takes 2+ minutes and freezes. Second launch is always fast. Occasionally the system fails to boot entirely with:

Warning: /dev/disk/by-uuid/... does not exist
dracut-initqueue: Warning: Not all disks have been found

What I tried:

  • nvme_core.default_ps_max_latency_us=0 → boot drops from 76s to ~16s, timeouts reduced but still present during first app launch
  • nvme_core.noacpi=1 → made things worse
  • pcie_aspm=off → eliminated timeouts but caused overlay: No changes allowed in reconfigure breaking the ostree root mount
  • nvme_core.io_timeout=255 nvme_core.max_retries=10 → added recently, still evaluating
  • rd.timeout=60 → added to prevent boot failure

Current kernel parameters:

nvme_core.default_ps_max_latency_us=0 nvme_core.io_timeout=255 nvme_core.max_retries=10 rd.timeout=60 i915.enable_psr=0

Notes:

  • NVMe SMART log shows no errors, 100% available spare, 0% used, temperature 33°C
  • The timeout pattern (slow first access, fast second) strongly suggests the drive is entering a deep power state and taking too long to wake up
  • pcie_aspm=off would likely fix it but is incompatible with ostree/composefs overlay filesystem

Has anyone seen this with the Micron MTFDKBA1T0QGN or the Intel Core Ultra 200H series? Is there a known quirk or firmware workaround?

2

Yes, there have been many such reports. A fix someone found was disabling Intel VMD in the UEFI. That fix was given in the Arch discussion. Note: If you do decide to do this, a reinstallation (or manual reconfiguration) may be required. You seem knowledgeable, so I’m sure you’ll manage.

3

Thank you so much, disabling VMD actually worked!