~4 minute boot time on ASUS ProArt X870E-Creator WiFi with two NVMe SSDs (Samsung 990 Pro)

Issues & Assistance
1

Since the very first CachyOS installation, boot time has been around 4-5 minutes. The system is otherwise completely stable and fast. This is not a regression — it has always been this way.

Hardware

  • CPU: AMD Ryzen 7 9800X3D
  • Motherboard: ASUS ProArt X870E-Creator WiFi
  • RAM: 64 GB DDR5
  • nvme0 (4TB, Windows): Samsung SSD 990 PRO 4TB
  • nvme1 (2TB, CachyOS): Samsung SSD 990 PRO 2TB
  • GPU: NVIDIA RTX 5090

systemd-analyze output
Startup finished in 13.8s (firmware) + 5.5s (loader) + 3.5s (kernel) + 3.4s (initrd) + 3min 54s (userspace) = 4min 20s
graphical.target reached after 3min 54s in userspace

systemd-analyze critical-chain
The critical chain always ends at boot.mount, which is reached after ~3min 43s — not because it takes long to mount, but because it starts very late.

dmesg finding
[ 291.392201] nvme nvme0: using unchecked data buffer
nvme0 (the 4TB Windows SSD) appears in dmesg after ~291 seconds. This seems related.

What I have already tried

  • Disabled cachyos-rate-mirrors.service and NetworkManager-wait-online.service
  • Removed splash kernel parameter (Limine bootloader)
  • Added nvme_core.default_ps_max_latency_us=0 kernel parameter
  • Added udev rule to set nvme0 power control to “on”
  • Tried enabling Memory Context Restore in BIOS (AI Tweaker + AMD CBS path)
  • POST Delay Time set to 0s in BIOS, Fast Boot enabled

Has anyone seen this kind of boot delay specifically with two Samsung 990 Pro NVMe drives on an AM5 board? Is the nvme0 initialization at 291 seconds a known issue? Any suggestions welcome.

Thanks Garehard

2

Welcome to the forum!

Do you have fast startup enabled in Windows? If so, the drive will be flagged as “dirty” and can cause some issues.

3

Could you post the whole output of

systemd-analyze blame

systemd-analyze critical-chain

?

Also:

systemd-analyze blame –user

and

systemd-critical-chain –user

4

Thanks for the quick reply! Here are the full outputs:

systemd-analyze blame (relevant entries)
10.812s boot.mount
4.781s dev-tpmrm0.device
4.750s dev-nvme1n1p1.device (CachyOS EFI partition)
4.708s dev-nvme0n1.device (Windows 4TB SSD)
1.542s home.mount
113ms NetworkManager.service

systemd-analyze critical-chain
graphical.target reached after 3min 54s
boot.mount started at 3min 43s, took 10.8s
boot.mount waited for: dev-nvme1n1p1.device

systemd-analyze blame --user — completely fine, 69ms total, no issues there.

nvme1 (CachyOS SSD) is detected after ~4.75s, but boot.mount doesn’t start until 3min 43s. Something is blocking systemd for ~3.5 minutes before local-fs.target even starts — but blame shows nothing that accounts for that time.

Also: dmesg shows nvme nvme0: using unchecked data buffer at timestamp [291s]. The Windows SSD has no fstab entries. Fast Startup in Windows was already disabled.

What could cause this ~3.5 minute gap before local-fs.target starts?

5

If you are comfortable sharing it, you can run sudo cachyos-bugreport.sh and post the link here for people to better see what is going on with your system.

6

Here is the bug report: 53b6485

7

Looks like the stall is happening here:

image
image1355×295 86.7 KB

There is a firmware update for your system from ASUS website. BTW, nice system board, almost 800USD? Hopefully, it’s not the processor.

8

I’m just grasping at straws but this problem reminds me of long boot times I would get when I used Xubuntu or Ubuntu Studio. For me, back then, it tended to have to do with the system losing track of the UUID of the swap partitition but it would eventually find it. There was a published fix for it also, but it didn’t seem to always be permanent, as the problem could resurface. Long boot times is actually one reason why I switched away from the ‘buntus. Sorry if all this isn’t relevant, but hopefully something will get figured out. I hope this helps somehow.

9

Thanks for the suggestions! I updated the BIOS from version 2004 to 2202 (latest stable from ASUS) but unfortunately the boot time remains the same at around 4 minutes.

Regarding the swap suggestion — in my case swap is handled by zram0 (compressed RAM, no partition) and it shows only 246ms in systemd-analyze blame, so that doesn’t seem to be the issue either.

Still hoping someone has an idea what’s causing that ~3.5 minute gap before local-fs.target starts!

10

can you add this option on boot kernel split_lock_detect=
see 27. Bus lock detection and handling — The Linux Kernel documentation
section 27.3

split_lock_detect=warn(default) or Off or ratelimit:n

and this from audio

[   68.903094] CPU: 0 UID: 0 PID: 192 Comm: kworker/0:3 Tainted: G           O        7.0.3-1-cachyos #1 PREEMPT  aedc9f01cfda4b99b1427548f1866e0838a12223
[   68.903098] Tainted: [O]=OOT_MODULE
[   68.903099] Hardware name: ASUS System Product Name/ProArt X870E-CREATOR WIFI, BIOS 2004 01/28/2026
[   68.903100] Workqueue: events azx_probe_work [snd_hda_intel]
[   68.903110] RIP: 0010:snd_hdac_bus_init_cmd_io+0x108/0x250 [snd_hda_core]
[   68.903118] Code: c6 84 9c cb c1 e8 c8 bf 0a c3 49 8b 46 20 31 c9 66 89 48 4a bd e9 03 00 00 66 0f 1f 84 00 00 00 00 00 49 8b 46 20 66 8b 40 4a <66> 85 c0 74 2b bf c7 10 00 00 e8 69 67 23 c3 ff cd 83 fd 01 77 e2
[   68.903120] RSP: 0018:ffffd2c402197d18 EFLAGS: 00000002
[   68.903121] RAX: ffffd2c40078ffff RBX: ffff8ecd9a5a44d0 RCX: 0000000000000000
[   68.903122] RDX: 000000639bfacae8 RSI: 0000000000001253 RDI: 000000639bfaa8c2
[   68.903123] RBP: 00000000000002db R08: 0000000000000000 R09: 0000000000000000
[   68.903124] R10: 0000000000000000 R11: ffffffff84dee490 R12: ffff8ecd82694000
[   68.903125] R13: 00000000ffffffff R14: ffff8ecd9a5a4028 R15: 00000000ffffffff
[   68.903126] FS:  0000000000000000(0000) GS:ffff8edd35a9a000(0000) knlGS:0000000000000000
[   68.903127] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   68.903128] CR2: 00005590003cc908 CR3: 000000011f3b8000 CR4: 0000000000f50ef0
[   68.903130] PKRU: 55555554
[   68.903130] Call Trace:
[   68.903131]  <TASK>
[   68.903133]  snd_hdac_bus_init_chip+0x7b/0xf0 [snd_hda_core 4491aeffb017746e54c0543ee9df9359583b8a32]
[   68.903139]  azx_init_chip+0x12/0x40 [snd_hda_codec 5bca07dca83228b3d76aa5d217c31634cbe5be3e]
[   68.903149]  hda_intel_init_chip+0x77/0x240 [snd_hda_intel edabcf730276855a468375fea081315fc7e2fbb9]
[   68.903154]  ? pci_conf1_write+0x9a/0xe0
[   68.903157]  ? azx_init_pci+0x70/0x340 [snd_hda_intel edabcf730276855a468375fea081315fc7e2fbb9]
[   68.903160]  azx_probe_continue+0x4a4/0x8f0 [snd_hda_intel edabcf730276855a468375fea081315fc7e2fbb9]
[   68.903164]  process_scheduled_works+0x24d/0x5a0
[   68.903166]  worker_thread+0x198/0x350
[   68.903168]  ? __pfx_worker_thread+0x10/0x10
[   68.903170]  kthread+0xfb/0x120
[   68.903171]  ? __pfx_kthread+0x10/0x10
[   68.903173]  ret_from_fork+0x113/0x970
[   68.903174]  ? __pfx_kthread+0x10/0x10
[   68.903176]  ret_from_fork_asm+0x1a/0x30
[   68.903178]  </TASK>

i will just add from my part ( X870E elite Wifi 7 & 9900x )
i see since switch from systemd mkinicpio very far from udev
i get about 4s with nvme just after fuse ( only 4s … )

11

Taking a second look at your dmesg output, there’s a huge(?) jump in time at 9.05… to 68.89… This is right when/after it says:

Adding 65461244k swap on /dev/zram0. …

Then it mentions a “self-detected stall on CPU” … related(?) to the rcu_preempt

It mentions rcu_preempt a few more times and even that “OOM is now expected behavior”.

OOM means “Out of Memory” (insufficient RAM, etc.)

How I would approach this is to assume that the zram0 compression is somehow failing or not working out at least. Maybe it’s just taking too long.

Even though the time lag might not be fully logged, it does mention a “grace period” (a pause) and maybe even an error log dump (which takes time). Maybe there’s a huge error log somewhere? Or it doesn’t have enough RAM after the OOM to even to a log? IDK.

However, what I would do next is try the system without zram, (no RAM compression) and instead use an ordinary swap file or a SWAP partition.

If you have enough RAM, you could possibly even try no swap, but I’d only try that as a last resort since the error message already mentions OOM.

Let us know how it goes if you try that.

12

Tried disabling HD Audio Controller in BIOS — no improvement in boot time. Also tried removing zram (emergency mode on boot, reverted). Also tried blacklisting snd_hda_intel and removing plymouth from mkinitcpio hooks — no improvement.

The HDA Intel error in dmesg at 68s seems to be a symptom, not the cause. The ~3.5 minute gap before local-fs.target starts remains unexplained.

Still investigating. Any other ideas welcome!

13

That’s an annoying issue, particularly with the rocket ship PC!

I don’t have Linux expertise, so my troubleshooting is more generic:

  1. factory reset BIOS and reinstall
  2. unplug the Windows drive / reinstall
  3. reinstall with EXT4

Try to isolate some aspect of the cause.

  1. utter desperation - ask an LLM and trust nothing it tells you!
14

SOLVED! The culprit was a Creative Sound Blaster AE-9 PCIe sound card. It has no Linux drivers and was hanging during initialization, blocking the entire boot process. Removed the card and boot time is now fast. The HDA Intel errors in dmesg were related to this card. Thanks everyone for the help!

15

Out of curiosity, I gave Gemini your specs + bug report:

The bug report indicates your NVIDIA RTX 5090 is currently running at PCIe Gen 1 speed (2.5 GT/s) with 8 lanes, despite being capable of Gen 5 speed (32 GT/s) with 16 lanes.

While the GPU downclocks to Gen 1 at idle to save power, the fact that it is limited to 8 lanes (x8) instead of 16 lanes (x16) suggests a hardware bandwidth allocation issue.

The 4+ minute boot delay is caused by an RCU CPU stall occurring during the initialization of your Creative Sound Blaster AE-9 (detected as AE-7 in the log due to the shared CA0132 chipset).

The dmesg log shows the kernel hanging at snd_hdac_bus_init_cmd_io while snd_hda_intel attempts to probe the Creative card. The CPU is stuck in a loop waiting for a response from the hardware that never comes, triggering a 60-second stall, which likely repeats multiple times during the boot sequence.

1. Primary Hardware/Firmware Fix

AM5 motherboards, particularly high-end X870E boards, frequently have timing issues with PCIe sound cards during the training phase.

  • Step 1: Enter the UEFI BIOS.
  • Step 2: Navigate to Advanced \ PCI Subsystem Settings.
  • Step 3: Change the PCIe slot speed for the slot containing the Sound Blaster AE-9 from Auto/Gen4 to Gen3.
    • Note: Sound cards do not benefit from Gen4/Gen5 bandwidth, and forcing Gen3 often resolves handshake timeouts.
  • Step 4: Disable Fast Boot in the Boot tab to allow for a full hardware enumeration.

2. Kernel Workaround (Driver Blacklist)

To confirm the sound card is the culprit and restore normal boot speeds, you can temporarily prevent the driver from loading.

  • Step 1: Edit the kernel command line at the boot loader (Limine).
  • Step 2: Append the following parameter:
module_blacklist=snd_hda_intel
  • Step 3: Boot the system. If it boots in seconds, the AE-9 hardware/driver interaction is definitely the bottleneck.

3. Persistent Driver Configuration

If you wish to keep the card but prevent the stall, try specific driver options for the snd_hda_intel module.

  • Step 1: Create a configuration file:
sudo micro /etc/modprobe.d/soundblaster.conf
  • Step 2: Add the following line to disable power saving and MSI (Message Signaled Interrupts), which often conflict with Creative PCIe bridges:
options snd-hda-intel enable_msi=0 power_save=0

4. Note on Ryzen 9000 Memory Training

Since you have 64GB of DDR5 on an X870E platform, ensure that “Memory Context Restore” is set to Enabled in the BIOS (under AI Tweaker or Advanced Memory settings).

While the log explicitly shows the sound card stall, AM5 platforms without Context Restore enabled will also add 60-90 seconds of black-screen time before the OS even begins to load. Combining this with the sound card stall results in your 4+ minute total.

16

Thanks for the detailed Gemini analysis — very accurate! A few updates on my end:
Moved the Linux NVMe to M.2 slot 1 and Windows NVMe to another slot — GPU is now running at full x16 lanes. Also managed to enable Memory Context Restore in BIOS. Both changes were easy wins.
Overall the system is now fast, stable and everything works as expected. Thanks to everyone who contributed!