[qcom-6.18.y][monaco-evk] UFS Initialization Failed

[sgaud-quic]

UFS initialization failed on monaco-evk board :
Kernel Version : v6.18.30
Branch : qcom-6.18.y
Tag : qcom-6.18.y-20260527
Failed job : https://lava.infra.foundries.io/scheduler/job/235805

[    0.243706] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to find vdd-hba-supply regulator, assuming enabled
[    0.291993] qcom-pcie 1c00000.pci: iATU: unroll T, 32 ob, 8 ib, align 4K, limit 1024G
[    0.292002] qcom-pcie 1c10000.pci: iATU: unroll T, 32 ob, 8 ib, align 4K, limit 1024G
[    0.300674] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to find vccq2-supply regulator, assuming enabled
[    1.248858] qcom-pcie 1c10000.pci: Phy link never came up
[    1.299259] qcom-pcie 1c00000.pci: Phy link never came up
[    1.306174] qcom-pcie 1c10000.pci: PCI host bridge to bus 0001:00
[    2.821482] ufshcd-qcom 1d84000.ufs: ufshcd_query_flag: Sending flag query for idn 1 failed, err = -11
[    2.829060] pci_bus 0001:00: root bus resource [bus 00-ff]
[    2.837924] ufshcd-qcom 1d84000.ufs: ufshcd_complete_dev_init: reading fDeviceInit flag failed with error -11
[    2.844766] pci_bus 0001:00: root bus resource [io  0x100000-0x1fffff] (bus address [0x0000-0xfffff])
[    2.882471] ufshcd-qcom 1d84000.ufs: error -EAGAIN: Initialization failed with error -11
[    2.897544] pci_bus 0001:00: root bus resource [mem 0x60300000-0x7fffffff]
[    2.908675] ufshcd-qcom 1d84000.ufs: error -EAGAIN: ufshcd_pltfrm_init() failed
[    2.908677] ufshcd-qcom 1d84000.ufs: probe with driver ufshcd-qcom failed with error -11

[nitinrawat123]

Hi,

Please can you share the number of instances reported ? This looks to be a stability issue .

Based on the available logs, the fDeviceInit failure is triggered by a QUERY_REQ_TIMEOUT observed after ~1500 ms, indicating that the UFS query request completion is not being signaled within the expected timeout window.

From a protocol and device perspective, one possible reason could be delayed device response to the fDeviceInit query (e.g., slow device readiness or delayed firmware state transition). However, this scenario appears unlikely as this request ideally completes in few ms and instead in current logs we see few anomalies(dmesg time stamp jump) in the dmesg logs.

So more probable root cause appears to delayed or missed interrupt handling on the host side. Specifically:
Potential IRQ starvation or interrupt latency during early boot
Delayed execution of threaded IRQ handlers, preventing timely completion signaling for UFS query requests

Additionally, the dmesg logs exhibit noticeable timestamp discontinuities during early boot. Such behavior typically indicates system-wide scheduling rather than a UFS-specific issue. Based on prior observations, this could be related to excessive serial console logging, where prolonged log flushing under preemption-disabled contexts may block interrupt handling and delay ISR execution.

To further validate this hypothesis, debug patch is created with more prints and to be tested in Storage test farm .