[Faruque Ansari (faruque-ansari)]

Add CONFIG_RCU_EXPERT=y to rt.config so CONFIG_RCU_NOCB_CPU=y is honored for PREEMPT_RT kernels.

Enable CONFIG_RCU_NOCB_CPU because QLI PREEMPT_RT builds use 'rcu_nocbs=' in the kernel command line. Without this configuration, the boot parameter is not effective.

CRs-Fixed: 4687502

[qswat-orbit-external]

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

[qcomlnxci]

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on da6dbbf

• multimedia Job 238558 on hamoa-iot-evk
• multimedia Job 238561 on lemans-evk
• multimedia Job 238560 on monaco-evk
• multimedia Job 238556 on purwa-iot-evk
• multimedia Job 238557 on qcs615-ride
• multimedia Job 238559 on qcs6490-rb3gen2
• multimedia Job 238555 on qcs8300-ride
• multimedia Job 238554 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 238563 on shikra-iqs-evk

[qlijarvis]

PR #1177 — validate-patch

PR: #1177

Verdict	Issues	Detailed Report
❌	1	Full report

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1177 - QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT
Upstream commit: N/A (vendor-only QCLINUX: commit)
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	N/A	Vendor-only commit, no upstream source
Body preserves rationale	✅	Clear explanation of why CONFIG_RCU_EXPERT=y is needed
Fixes tag present/correct	N/A	Not applicable for config addition
Authorship preserved	✅	Proper author and Signed-off-by present
Backport note (if applicable)	N/A	Not a backport

Diff

File	Status	Notes
arch/arm64/configs/rt.config	✅	Adds CONFIG_RCU_EXPERT=y and CONFIG_RCU_NOCB_CPU=y as described

Issues

• Integration presence failure: Commit is missing from both qcom-next and topics branches. According to integration_presence_report.md, 1/1 commits are missing from the integration tree. This commit should be present in qcom-next or topics before being merged to the target branch.

Verdict

Do not merge. The commit itself is well-formed with proper commit message format, clear rationale, and correct diff content. However, it fails the integration presence check - it must be present in qcom-next or topics before being merged to the target branch.

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics (per integration_presence_report.md)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: e428097a36d210c50991063f17ee0848e9eb68a8
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] QCLINUX: arm64: configs: rt.config: Enable	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing

Final Status

overall_status: FAIL
present_commits: 0/1
partial_commits: 0/1
missing_commits: 1/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

[qlijarvis]

PR #1177 — checker-log-analyzer

PR: #1177
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/35829842752

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	No binding changes
dtb-check	⏭️	No DTS changes
sparse-check	⏭️	No C/H changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	QCLINUX: prefix not accepted
tag-check	⚠️	QCLINUX: is valid for qcom-6.18.y

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1177 - QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/35829842752

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	No binding changes
dtb-check	⏭️	No DTS changes
sparse-check	⏭️	No C/H changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	QCLINUX: prefix not accepted
tag-check	⚠️	QCLINUX: is valid for qcom-6.18.y

---

❌ check-patch-compliance

Root cause: The commit uses QCLINUX: prefix, which is not in the checker's allowed list (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:).

Failure details:

Checking commit: QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT
Commit summary does not start with a required prefix

Analysis:

This is a known limitation of the check-patch-compliance checker. The checker only accepts upstream-linkable prefixes (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:), but the Qualcomm Linux kernel tree uses additional vendor-internal prefixes including QCLINUX:, PENDING:, and WORKAROUND:.

According to the skill's log-patterns reference (Section 7):

Note on QCLINUX: and PENDING:: These are vendor-internal prefixes used in the tree but not accepted by check-patch-compliance. If a commit is vendor-only with no upstream equivalent, the checker will always fail for it. This is a known limitation — the checker enforces upstream-linkable prefixes only.

Context:

• Target branch: qcom-6.18.y (not qcom-next or qcom-next-staging)
• Commit type: Vendor-only kernel config change (enabling CONFIG_RCU_NOCB_CPU for RT kernels)
• Prefix used: QCLINUX: (appropriate for vendor-only changes)

Tag-check assessment (Step 2.7):

For branches other than qcom-next and qcom-next-staging, every commit must start with one of these prefixes:

• FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:, QCLINUX:, PENDING:, WORKAROUND:

✅ The commit subject QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT does start with a valid prefix (QCLINUX:), so tag-check passes.

Verdict on this failure:

This is a false positive caused by the checker's design limitation. The commit is correctly tagged with QCLINUX: for a vendor-only change. No patch modification is needed.

Options:

1. Accept as-is (recommended) — The QCLINUX: prefix is correct for this vendor-only config change. The check-patch-compliance failure is expected and can be ignored.
2. Add upstream link — If this change has been posted to lore.kernel.org, change the prefix to FROMLIST: and add a Link: tag. However, kernel config fragments are typically vendor-specific and not posted upstream.

Reproduce locally:

cd kernel
git log --oneline 8a24e588aae7..da6dbbf14a93
# Verify the commit subject starts with QCLINUX:

---

Verdict

Ready to merge. The check-patch-compliance failure is a known false positive for vendor-only commits using the QCLINUX: prefix. All other checkers passed or were correctly skipped. The commit is properly formatted with:

• ✅ Valid QCLINUX: prefix (appropriate for vendor-only changes)
• ✅ Proper Signed-off-by: trailer
• ✅ No checkpatch style issues
• ✅ No DTS/binding/sparse/UAPI changes to validate

[Shiraz Hashim (shashim-quic)]

QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT
Add CONFIG_RCU_EXPERT=y to rt.config so CONFIG_RCU_NOCB_CPU=y is
honored for PREEMPT_RT kernels.

Mention reason why you want to enable it.

[qlijarvis]

PR #1177 — validate-patch

PR: #1177

Verdict	Issues	Detailed Report
⚠️	1	Full report

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1177 - QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT
Upstream commit: N/A (vendor-only QCLINUX: commit)
Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	N/A	Vendor-only commit; no upstream source
Body preserves rationale	✅	Clear explanation of why CONFIG_RCU_EXPERT is needed
Fixes tag present/correct	N/A	Not a fix; new configuration
Authorship preserved	✅	Signed-off-by present
Backport note (if applicable)	N/A	Not a backport

Diff

File	Status	Notes
arch/arm64/configs/rt.config	✅	Clean addition of two RCU config options

Issues

• ⚠️ Integration presence: Commit is missing from both qcom-next and topics branches. For a vendor-only configuration change, this commit should be present in the integration tree before merging to ensure it's been tested in the CI pipeline.

Verdict

This is a valid vendor-only configuration change with clear rationale. However, the commit is not yet present in qcom-next or topics, which suggests it has not been integrated or tested in the standard QLI workflow. Recommend integrating to qcom-next first for CI validation before merging to the target branch.

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: No — commit missing from both qcom-next and topics (FAIL per integration_presence_report.md)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: c7896917e523946138ce654d4b6c1e33d5a8f4e5
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] QCLINUX: arm64: configs: rt.config: Enable	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing

Final Status

overall_status: FAIL
present_commits: 0/1
partial_commits: 0/1
missing_commits: 1/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

[qlijarvis]

PR #1177 — checker-log-analyzer

PR: #1177
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/40818930925

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	No binding changes
dtb-check	⏭️	No DTS changes
sparse-check	⏭️	No C/H changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	QCLINUX: prefix not accepted (known limitation)
tag-check	✅	Valid QCLINUX: prefix for qcom-6.18.y

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1177 — QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/40818930925

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	No binding changes
dtb-check	⏭️	No DTS changes
sparse-check	⏭️	No C/H changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	QCLINUX: prefix not accepted (known limitation)
tag-check	✅	Valid QCLINUX: prefix for qcom-6.18.y

---

❌ check-patch-compliance

Root cause: The commit uses the QCLINUX: prefix, which is not in the checker's allowed list.

Failure details:

Checking commit: QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT
Commit summary does not start with a required prefix

Analysis:

This is a known limitation of the check-patch-compliance checker. The checker only accepts upstream-linkable prefixes:

• FROMLIST: (posted to mailing list)
• FROMGIT: (from maintainer tree)
• UPSTREAM: (merged into mainline)
• BACKPORT: (backported with modifications)

The QCLINUX: prefix is used for vendor-only changes with no upstream equivalent. This is a legitimate use case for Qualcomm Linux internal branches, but the checker does not recognize it.

Why this is acceptable:

1. This is a vendor-specific config change — enabling CONFIG_RCU_NOCB_CPU for Qualcomm's PREEMPT_RT builds. This is not an upstream-suitable change.

2. The tag-check passes — the commit correctly uses the QCLINUX: prefix, which is required for all commits targeting branches other than qcom-next or qcom-next-staging.

3. All other checkers pass or skip appropriately — no code quality, style, or ABI issues.

Fix: None required. This is a false positive due to checker limitations for vendor-only commits.

Reproduce locally:

cd kernel-checkers
./check-patch-compliance.sh <base_sha> <head_sha>

(Will reproduce the same failure for any QCLINUX:-prefixed commit.)

---

Verdict

Ready to merge. The check-patch-compliance failure is a known false positive for vendor-only commits using the QCLINUX: prefix. All other checkers pass, and the commit correctly follows the tagging convention for the qcom-6.18.y branch.

[qcomlnxci]

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on 9a18ce4

• multimedia Job 262516 on hamoa-iot-evk
• multimedia Job 262512 on lemans-evk
• multimedia Job 262514 on monaco-evk
• multimedia Job 262513 on purwa-iot-evk
• multimedia Job 262510 on qcs615-ride
• multimedia Job 262517 on qcs6490-rb3gen2
• multimedia Job 262511 on qcs8300-ride
• multimedia Job 262509 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 262515 on shikra-iqs-evk

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1177

Job 262509 | SoC qcs9100-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262509

Failed test cases in LAVA job 262509 (SoC: qcs9100-ride).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the wireless-regdb package (or equivalent firmware package containing /lib/firmware/regulatory.db) to the Yocto/distro image recipe used for CI testing. The file is typically provided by the wireless-regdb package in most Linux distributions.
4. Detail analysis attachment: failed_case_job262509_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device (aa00000.video-codec) is not attached to any IOMMU group on qcs9100-ride platform, causing the SMMU test's critical master validation to fail. This is a device tree configuration issue where the video codec node is missing the required iommus property to bind it to an IOMMU group.
3. Possible fix: Add the iommus property to the video-codec@aa00000 device tree node in the qcs9100-ride DTS file to bind it to an appropriate IOMMU group, following the pattern used by other critical masters (UFS, USB, Display) that successfully pass the test.
4. Detail analysis attachment: failed_case_job262509_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a bug requiring a fix. The KVM test suite should be configured to skip KVM tests on platforms that boot with a hypervisor (Gunyah/el2gh boot mode). Add a platform-specific test exclusion for qcs9100-ride when booted in Gunyah mode, or modify the test to check for hypervisor presence before attempting KVM validation.
4. Detail analysis attachment: failed_case_job262509_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM unavailable under hypervisor

1. Failed case: KVM_EL2_DTB — KVM unavailable under hypervisor
2. Root cause: KVM cannot initialize because the qcs9100-ride platform boots under the Gunyah hypervisor, which occupies EL2 (HYP mode). KVM requires exclusive access to EL2 to provide virtualization, but when a hypervisor is already running at EL2, the kernel runs at EL1 and cannot access EL2. This is an expected architectural limitation, not a kernel bug.
3. Possible fix: This is not a bug to fix—it is a platform configuration constraint. KVM and a host hypervisor (Gunyah) cannot coexist on the same boot. To enable KVM on qcs9100-ride, the platform must boot without the Gunyah hypervisor (i.e., boot the kernel directly at EL2 instead of as a guest under Gunyah). If nested virtualization is required, the hypervisor must support nested KVM (not currently available in Gunyah). For CI purposes, either: (1) skip KVM tests on qcs9100-ride targets that boot under Gunyah, or (2) provide a separate qcs9100-ride LAVA target that boots without a hypervisor.
4. Detail analysis attachment: failed_case_job262509_4_detailed.md

  Case 5: KVM_Infra — KVM Driver Initialization Failure

1. Failed case: KVM_Infra — KVM Driver Initialization Failure
2. Root cause: KVM driver failed to initialize because the qcs9100-ride (Lemans) platform does not support HYP mode (EL2 virtualization extensions). The kernel message "kvm [1]: HYP mode not available" at boot time (line 3377) indicates the CPU is not running at EL2 or virtualization extensions are disabled/unavailable, preventing /dev/kvm device creation.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR only modifies RCU configuration for RT kernels and does not affect KVM/virtualization. Mark KVM tests as "not applicable" for qcs9100-ride platform in CI, or configure the bootloader/firmware to enable EL2 if the hardware supports it but firmware is blocking access.
4. Detail analysis attachment: failed_case_job262509_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform does not support KVM virtualization — qcs9100-ride (LeMans Ride Rev3) boots without HYP (EL2) mode available, causing KVM initialization to fail with "HYP mode not available" and preventing /dev/kvm device node creation.
3. Possible fix: Mark KVM tests as expected-fail or skip them for qcs9100-ride platform in the LAVA job definition, as this SoC does not provide virtualization extensions or is not configured to boot with EL2 available. Alternatively, verify bootloader/firmware configuration to ensure the kernel is booted at EL2 if the hardware supports it.
4. Detail analysis attachment: failed_case_job262509_6_detailed.md

Job 262510 | SoC qcs615-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262510

Failed test cases in LAVA job 262510 (SoC: qcs615-ride).

  Case 1: Probe_Failure_Check — False Positive Firmware Load Failure

1. Failed case: Probe_Failure_Check — False Positive Firmware Load Failure
2. Root cause: The Probe_Failure_Check test flagged a benign cfg80211 regulatory.db firmware load failure (error -2, ENOENT) that occurs during WiFi subsystem initialization. This is a known non-issue: cfg80211 attempts to load an optional regulatory database file from the filesystem; when absent, it falls back to compiled-in regulatory data. WiFi functionality is unaffected, as proven by the WiFi_OnOff test passing with full interface creation and toggle validation.
3. Possible fix: Suppress regulatory.db firmware load failures in the Probe_Failure_Check test pattern matching, or add an exception rule that excludes this specific error when WiFi/BT functional tests pass. The test should not fail on optional firmware files that have working fallback mechanisms. No kernel or PR changes are required — this is a test infrastructure false positive.
4. Detail analysis attachment: failed_case_job262510_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test expects video-decoder and video-encoder sub-devices (children of aa00000.video-codec) to have individual IOMMU group attachments, but the Venus video codec driver on qcs615-ride creates only the parent device (aa00000.video-codec) with IOMMU group 7 attachment. The video-decoder and video-encoder are logical sub-devices created by the V4L2 video driver framework and do not have separate platform device entries or IOMMU group attachments in the current kernel implementation.
3. Possible fix: Update the smmu test expectations for qcs615-ride to check only the parent video-codec device (aa00000.video-codec) IOMMU attachment, not the logical V4L2 sub-devices. This is a test infrastructure issue, not a kernel regression introduced by PR QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT #1177 (which only modifies RCU configuration for RT kernels).
4. Detail analysis attachment: failed_case_job262510_2_detailed.md

  Case 3: ** KVM_Driver — Platform Does Not Support Virtualization

1. Failed case: ** KVM_Driver — Platform Does Not Support Virtualization
2. Root cause: ** QCS615 Ride platform does not support ARM virtualization extensions (HYP/EL2 mode). Kernel message at boot: kvm [1]: HYP mode not available [3.378651]. CONFIG_KVM is enabled in kernel config, but the hardware/firmware does not provide EL2 hypervisor mode, preventing /dev/kvm device node creation.
3. Possible fix: This is not a PR-introduced regression. The PR only modifies RCU config for RT kernels and does not affect KVM/virtualization. Action: Mark KVM tests as SKIP for QCS615 platform in LAVA job definition, or exclude QCS615 from KVM test matrix, as this SoC does not support virtualization in the current firmware/hardware configuration.
4. Detail analysis attachment: failed_case_job262510_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on platforms where Gunyah hypervisor is enabled. Add a test precondition check: if dmesg | grep -q "Hypervisor cold boot.*gunyah", mark KVM tests as SKIP with reason "KVM unavailable on Gunyah-enabled platform". Alternatively, disable Gunyah in the platform firmware/bootloader configuration if KVM functionality is required for testing.
4. Detail analysis attachment: failed_case_job262510_4_detailed.md

  Case 5: KVM_Infra — Platform Hardware Limitation (EL2/HYP mode not available)

1. Failed case: KVM_Infra — Platform Hardware Limitation (EL2/HYP mode not available)
2. Root cause: QCS615 platform does not support ARM Virtualization Extensions (EL2/HYP mode); kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU does not provide the required hardware capability for KVM, causing /dev/kvm device node creation to fail despite CONFIG_KVM being enabled in the kernel configuration.
3. Possible fix: This is not a kernel regression or PR-introduced issue — it is a pre-existing platform hardware limitation. The QCS615 SoC does not support ARM Virtualization Extensions. Mark KVM tests as "skip" or "not applicable" for QCS615 in the LAVA test suite configuration, or exclude QCS615 from KVM test runs entirely.
4. Detail analysis attachment: failed_case_job262510_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS615 platform does not support ARM EL2 (Hypervisor mode) — kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation despite CONFIG_KVM=y being enabled.
3. Possible fix: This is a pre-existing hardware/firmware limitation, not a PR-introduced regression. The PR only modifies RCU configuration for RT kernels and does not affect KVM/virtualization. Mark this test as expected-fail for QCS615 platform, or skip KVM tests on platforms without EL2 support. To enable KVM on QCS615, the bootloader/firmware must be configured to boot Linux at EL1 with EL2 available (currently booting without EL2 access).
4. Detail analysis attachment: failed_case_job262510_6_detailed.md

Job 262511 | SoC qcs8300-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262511

Failed test cases in LAVA job 262511 (SoC: qcs8300-ride).

  Case 1: Driver Probe Failure — Aquantia PHY and regulatory.db firmware

1. Failed case: Driver Probe Failure — Aquantia PHY and regulatory.db firmware
2. Root cause: Two pre-existing probe failures unrelated to PR changes: (1) Aquantia AQR115C PHY driver fails with -EINVAL due to missing or malformed firmware-name property in qcs8300-ride device tree node at stmmac-0:08, (2) cfg80211 regulatory database firmware file (regulatory.db) missing from rootfs /lib/firmware.
3. Possible fix: (1) Add firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld"; property to the Aquantia PHY node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts under the stmmac MDIO bus, (2) Add linux-firmware package (or equivalent containing regulatory.db) to the Yocto image recipe for qcs8300-ride builds.
4. Detail analysis attachment: failed_case_job262511_1_detailed.md

  Case 2: Driver Probe Failure — Ethernet_Basic_Validation

1. Failed case: Driver Probe Failure — Ethernet_Basic_Validation
2. Root cause: Aquantia AQR115C PHY driver probe fails with -EINVAL because the device tree node for the PHY is missing the required firmware-name property, preventing the PHY from loading its firmware and causing the qcom-ethqos Ethernet MAC driver to fail PHY attachment on qcs8300-ride.
3. Possible fix: Add the firmware-name property to the Aquantia AQR115C PHY device tree node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts (or the appropriate qcs8300 DTSI file). The property should specify the path to the Aquantia PHY firmware file, typically firmware-name = "Rhe-ethqos-AQR_Mediatek_23B_P5_ID45623_VER_0.cld"; or the appropriate firmware file for this PHY model. This is a pre-existing platform DT issue, not a regression from PR QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT #1177 (which only modifies RCU config options).
4. Detail analysis attachment: failed_case_job262511_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the KVM test suite to detect hypervisor presence and skip tests with SKIP status instead of FAIL. Add a hypervisor detection gate in Runner/suites/Virtualization/KVM/*/run.sh: check for /sys/hypervisor or dmesg | grep -i "hypervisor" and exit with skip status if detected. This is a test infrastructure fix, not a kernel fix.
4. Detail analysis attachment: failed_case_job262511_3_detailed.md

  Case 4: KVM Device Unavailable — Platform Running as Hypervisor Guest

1. Failed case: KVM Device Unavailable — Platform Running as Hypervisor Guest
2. Root cause: /dev/kvm is not available because the QCS8300 Ride platform is running as a guest under the Gunyah hypervisor at EL1, not as a host at EL2. KVM requires EL2 (hypervisor mode) access to initialize and create the /dev/kvm device node. This is a platform architecture constraint, not a kernel defect.
3. Possible fix: Exclude KVM host functionality tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the test suite for QCS8300 Ride and other platforms configured to run as guests under Gunyah hypervisor. These tests are only applicable to platforms where the kernel runs at EL2 as a KVM host.
4. Detail analysis attachment: failed_case_job262511_4_detailed.md

  Case 5: KVM_Infra — /dev/kvm device node unavailable

1. Failed case: KVM_Infra — /dev/kvm device node unavailable
2. Root cause: QCS8300 platform runs under Gunyah hypervisor (detected at boot: "Hypervisor cold boot, version: gunyah-cdfb73831"), which operates at EL2 and prevents KVM from initializing. CONFIG_KVM=y is enabled but KVM cannot create /dev/kvm because the hypervisor already controls EL2, blocking nested virtualization. This is a platform limitation, not a kernel regression.
3. Possible fix: Mark KVM_Infra, KVM_Driver, and KVM_EL2_DTB tests as expected failures (XFAIL) for qcs8300-ride in the LAVA test suite configuration, or skip these tests entirely on Gunyah-based platforms. The PR (RCU config changes) is unrelated and does not cause this failure.
4. Detail analysis attachment: failed_case_job262511_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: The PR changes (adding CONFIG_RCU_EXPERT=y and CONFIG_RCU_NOCB_CPU=y to rt.config) are unrelated to the test failures. All failures are pre-existing issues: (1) For Probe_Failure_Check: suppress or fix the Aquantia PHY probe failure (likely missing PHY configuration in device tree) and the regulatory.db firmware load failure (benign - regulatory database not required for basic operation). (2) For Ethernet: fix the PHY attachment issue in the qcs8300 device tree or Ethernet driver. (3) For KVM: ensure KVM module is loaded and /dev/kvm is created, or mark KVM tests as expected-fail on qcs8300-ride if KVM is not supported on this platform. Re-trigger the CI job after addressing these platform-specific issues, or accept these as known limitations and merge the PR since it does not introduce new failures.
4. Detail analysis attachment: failed_case_job262511_6_detailed.md

Job 262512 | SoC lemans-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262512

Failed test cases in LAVA job 262512 (SoC: lemans-evk).

  Case 1: Probe_Failure_Check — Firmware Load Fallback Attempts (Known Benign)

1. Failed case: Probe_Failure_Check — Firmware Load Fallback Attempts (Known Benign)
2. Root cause: The test detected 3 firmware load failures during boot (regulatory.db, wcnhpbtfw21.tlv, hpbtfw21.tlv), but these are fallback firmware load attempts that failed benignly. Both BT_ON_OFF and WiFi_OnOff functional tests passed, confirming that Bluetooth and WiFi drivers successfully loaded alternative firmware and became fully operational. This is not a genuine failure.
3. Possible fix: Suppress this failure per lava-known-benign-failures.md Rules 2 & 3. The Probe_Failure_Check test should be updated to exclude firmware load errors when the corresponding functional tests (BT_ON_OFF, WiFi_OnOff) pass, as these represent expected fallback behavior during driver initialization on lemans-evk.
4. Detail analysis attachment: failed_case_job262512_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test failed because the video codec device (aa00000.video-codec) is not attached to any IOMMU group on the lemans-evk platform. The device is expected by the test but is either not present in the device tree, not probed by the driver, or the driver is not enabled in the kernel configuration for this SoC.
3. Possible fix: This is a pre-existing platform/test compatibility issue, not a regression introduced by PR QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT #1177 (which only modifies RCU configuration for RT kernels). The test should either be skipped for lemans-evk or the platform support should be updated to include the video codec device with proper IOMMU bindings. No action required on this PR.
4. Detail analysis attachment: failed_case_job262512_2_detailed.md

  Case 3: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test runner marked the test definition as "unfinished" because the result_parse.sh script listed 4 test result files (CPU_affinity.res, Freq_Scaling.res, irq.res, smmu.res) that were already reported as PASS earlier in the test run, but LAVA's test shell completion logic interpreted this as incomplete test execution and marked the overall test definition as failed.
3. Possible fix: This is a LAVA test infrastructure issue, not a kernel regression. The PR changes (adding CONFIG_RCU_EXPERT=y and CONFIG_RCU_NOCB_CPU=y to rt.config) do not affect test execution. Re-trigger the CI job; if the issue persists, investigate the result_parse.sh script logic to ensure it properly signals test completion to LAVA without listing already-completed test result files.
4. Detail analysis attachment: failed_case_job262512_3_detailed.md

Job 262513 | SoC purwa-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262513

Failed test cases in LAVA job 262513 (SoC: purwa-evk).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Four pre-existing, platform-specific probe failures unrelated to PR QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT #1177 (RCU config changes for RT kernels): (1) qcom_qseecom_uefisecapp -EBUSY due to efivars conflict, (2-3) two qcom-pcie controllers -ENODATA because PHY init sequences are missing for purwa-evk SoC, (4) regulatory.db firmware -ENOENT (optional wireless regulatory database).
3. Possible fix: Suppress these known benign probe failures in the Probe_Failure_Check test for purwa-evk. These failures do not impact system functionality — all dependent tests (PCIe, WiFi, BT, USB, UFS) passed successfully.
4. Detail analysis attachment: failed_case_job262513_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test expects video codec device (aa00000.video-codec) to be attached to an IOMMU group, but the device does not probe on purwa-evk platform. This is a pre-existing board/DT configuration issue unrelated to the PR (which only changes RCU config for RT kernels).
3. Possible fix: Update the SMMU test to make video codec device check conditional based on platform, or verify/fix the purwa-evk device tree to enable the video codec node if the hardware is present.
4. Detail analysis attachment: failed_case_job262513_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because the purwa-evk platform does not support ARM Virtualization Extensions (VHE/nVHE) — kernel message "kvm [1]: HYP mode not available" indicates the CPU cannot enter EL2 hypervisor mode, which is a hardware prerequisite for KVM on ARM64.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. The purwa-evk SoC does not support ARM Virtualization Extensions. Either: (1) skip KVM tests on purwa-evk in the CI test matrix, or (2) run KVM tests only on platforms with VHE support (e.g., rb3gen2, kodiak). The PR (RCU config changes) did not cause this failure.
4. Detail analysis attachment: failed_case_job262513_3_detailed.md

  Case 4: ** KVM Test Environment Incompatibility — /dev/kvm unavailable (Gunyah hypervisor occupies EL2)

1. Failed case: ** KVM Test Environment Incompatibility — /dev/kvm unavailable (Gunyah hypervisor occupies EL2)
2. Root cause: ** The purwa-evk board boots with Gunyah hypervisor running at EL2 (line 2710: "Hypervisor cold boot, version: gunyah-mobile-1f99e07c2"), preventing KVM from initializing because KVM requires exclusive EL2 access. At line 3782, KVM explicitly reports "HYP mode not available" during initialization. CONFIG_KVM is enabled, but /dev/kvm cannot be created because the hypervisor privilege level is already occupied.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The PR (RCU config changes for RT) is unrelated to KVM/virtualization. To enable KVM testing on purwa-evk: (1) reconfigure the board firmware/bootloader to boot Linux directly at EL2 without Gunyah, OR (2) move KVM tests to a different platform that boots Linux at EL2, OR (3) mark KVM tests as "skip" for Gunyah-enabled platforms in the LAVA job definition with a platform-specific conditional.
4. Detail analysis attachment: failed_case_job262513_4_detailed.md

  Case 5: KVM Infrastructure Test Failure — KVM driver initialization failed

1. Failed case: KVM Infrastructure Test Failure — KVM driver initialization failed
2. Root cause: KVM driver failed to initialize because the Purwa IoT EVK platform firmware does not boot the kernel with EL2 (hypervisor mode) support enabled; kernel log shows "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: Enable EL2/HYP mode support in the Purwa platform bootloader/firmware configuration (ABL/XBL) to allow the kernel to initialize KVM; alternatively, if the platform hardware does not support virtualization extensions, mark KVM tests as "not applicable" for this SoC in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job262513_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM subsystem initialization failed because the kernel was not booted in EL2 (HYP mode). The bootloader/firmware on Purwa IoT EVK boots Linux in EL1 without granting EL2 access, preventing KVM from creating the /dev/kvm device node. This is a platform firmware/bootloader configuration issue, not a kernel regression.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT #1177 (which only modifies RCU config for RT kernels). To enable KVM on Purwa EVK: (1) Update bootloader (ABL/UEFI) configuration to boot Linux in EL2 mode, or (2) Configure TrustZone/firmware to grant EL2 access to non-secure world, or (3) If this platform is not intended to support KVM, mark KVM tests as expected-fail for purwa-evk in the LAVA job definition.
4. Detail analysis attachment: failed_case_job262513_6_detailed.md

Job 262514 | SoC monaco-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262514

Failed test cases in LAVA job 262514 (SoC: monaco-evk).

  Case 1: Driver Probe Failure — ath11k_pci WiFi driver

1. Failed case: Driver Probe Failure — ath11k_pci WiFi driver
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk, indicating the WiFi hardware (WCN6855 PCIe device at 0000:01:00.0) did not respond during initialization, likely due to firmware load failure (ath11k/WCN6855/hw2.1/nfa765/amss.bin missing with error -2) or MHI link timeout during device bring-up.
3. Possible fix: This is NOT a PR-introduced regression. The PR only modifies arch/arm64/configs/rt.config to add RCU configuration for PREEMPT_RT builds and does not touch WiFi drivers, firmware paths, device tree, or PCIe subsystem. The failure is a pre-existing platform/firmware issue on monaco-evk where the ath11k WiFi firmware for WCN6855 (nfa765 variant) is either missing from the rootfs or the PCIe/MHI link to the WiFi chip is not establishing correctly. Verify firmware files are present in /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ on the target rootfs, and check PCIe link training logs for the WiFi device.
4. Detail analysis attachment: failed_case_job262514_1_detailed.md

  Case 2: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (-ENOENT). The MHI power-up sequence timed out waiting for firmware load, causing the entire WiFi PCI device initialization to fail. This is a pre-existing platform/image issue, not introduced by PR QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT #1177 (which only modifies RCU config for RT kernels).
3. Possible fix: Add the missing ath11k WCN6855 nfa765 firmware files to the Yocto image recipe. Specifically, ensure linux-firmware-ath11k or equivalent package includes the ath11k/WCN6855/hw2.1/nfa765/ directory with amss.bin and related firmware blobs. Verify the firmware path matches the driver's request_firmware() call for this hardware variant on monaco-evk.
4. Detail analysis attachment: failed_case_job262514_2_detailed.md

  Case 3: WiFi_OnOff — ath11k_pci probe failure

1. Failed case: WiFi_OnOff — ath11k_pci probe failure
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image. The MHI (Modem Host Interface) subsystem attempted to load the firmware for the WCN6855 WiFi chip but received error -2 (ENOENT), causing the MHI power-up to timeout and the driver probe to fail.
3. Possible fix: Add the missing WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image under /lib/firmware/. This is a pre-existing image packaging issue unrelated to PR QCLINUX: arm64: configs: rt.config: Enable CONFIG_RCU_NOCB_CPU for RT #1177 (which only modifies RCU config for RT kernels). The firmware should be sourced from the linux-firmware repository or Qualcomm's firmware package for QCS8300/Monaco platform.
4. Detail analysis attachment: failed_case_job262514_3_detailed.md

  Case 4: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA infrastructure issue — test runner completed successfully (all tests executed and reported results via LAVA_SIGNAL_TESTCASE), but LAVA dispatcher marked the test definition as "unfinished" and failed it despite receiving the <LAVA_TEST_RUNNER EXIT> signal. This is a LAVA job definition or dispatcher configuration issue, not a kernel regression. The PR changes (adding CONFIG_RCU_EXPERT=y and CONFIG_RCU_NOCB_CPU=y to rt.config) are unrelated to this failure — they only affect PREEMPT_RT builds with rcu_nocbs= cmdline parameter, which is not used on this monaco-evk target.
3. Possible fix: Re-trigger the LAVA job. If the issue persists, review the LAVA job definition for the test action timeout and expected completion signals — the dispatcher may be expecting a different completion pattern or the test action timeout may be too short for the monaco-evk platform's test suite duration (465 seconds observed).
4. Detail analysis attachment: failed_case_job262514_4_detailed.md

Job 262515 | SoC shikra-iqs-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262515

Failed test cases in LAVA job 262515 (SoC: shikra-iqs-evk).

  Case 1: GIC Test Script Bug — Test Harness Parsing Error

1. Failed case: GIC Test Script Bug — Test Harness Parsing Error
2. Root cause: The GIC test script (run.sh line 75) incorrectly parses /proc/interrupts for systems with only 4 CPUs (0-3), attempting to validate non-existent CPUs 4-7 by splitting the interrupt line on whitespace without accounting for the variable number of CPU columns, causing bash integer comparison errors ([: GICv3: integer expected) when it tries to compare non-numeric fields (GICv3, Level, arch_timer) as timer counts.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online (which correctly reports 0-3 for shikra-iqs-evk) and only validate timer increments for CPUs that actually exist, rather than hardcoding an assumption of 8 CPUs.
4. Detail analysis attachment: failed_case_job262515_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The test detected probe/firmware failures for non-critical peripherals (ucsi_ccg USB-C controller missing firmware, regulatory.db missing, tpm_tis_spi timeout, and audio codec deferred probe issues) that are pre-existing platform/board configuration issues unrelated to the PR's RCU configuration changes.
3. Possible fix: These are known benign hardware/firmware configuration issues on the shikra-iqs-evk board. The PR changes (adding CONFIG_RCU_EXPERT=y and CONFIG_RCU_NOCB_CPU=y to rt.config) do not affect device probe behavior. Mark this test failure as a false positive for this PR — the failures existed before this change and are board-specific configuration gaps, not kernel regressions introduced by the RCU config patch.
4. Detail analysis attachment: failed_case_job262515_2_detailed.md

  Case 3: PCIe — QPS615 Firmware and Driver Module Missing

1. Failed case: PCIe — QPS615 Firmware and Driver Module Missing
2. Root cause: The shikra-iqs-evk board includes a QPS615 (Toshiba TC956X) PCIe-to-Ethernet bridge switch, but the QLI kernel build does not include the required firmware blob (TC956X_Firmware_PCIeBridge.bin) or the kernel driver module (tc956x_pcie_eth.ko). This is a pre-existing board support gap in the Yocto distribution, not a regression introduced by PR#1177 (which only modifies RCU configuration for RT kernels).
3. Possible fix: Add the TC956X firmware blob and tc956x_pcie_eth driver module to the meta-qcom Yocto recipe for shikra-iqs-evk. Specifically: (1) Add TC956X_Firmware_PCIeBridge.bin to the linux-firmware package or board-specific firmware recipe, (2) Enable CONFIG_TC956X_PCIE_ETH (or equivalent) in the kernel defconfig for shikra, (3) Rebuild and reflash. This is a board enablement task, not a kernel bug fix.
4. Detail analysis attachment: failed_case_job262515_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USB controllers (4c00000.usb and 4e00000.usb) are configured in gadget/device mode and the DWC3/xHCI host controller drivers did not probe, resulting in no USB root hubs being exposed. The system reached "Hardware activated USB gadget" target, confirming gadget-only operation. This is NOT a PR-introduced regression—the PR only modifies RCU configuration (CONFIG_RCU_EXPERT=y, CONFIG_RCU_NOCB_CPU=y) in rt.config and does not touch USB, device tree, or driver code.
3. Possible fix: This is a pre-existing platform/board configuration issue, not a kernel regression. The shikra-iqs-evk board's device tree or bootloader is configuring USB ports in device/gadget mode instead of host mode. To enable USB host functionality: (1) verify the device tree USB connector nodes specify dr_mode = "host" or dr_mode = "otg" (not dr_mode = "peripheral"), (2) ensure the Type-C connector configuration allows host mode, (3) check that the UCSI CCG firmware (which failed to probe with error -2) is not blocking role switching, and (4) if using OTG, ensure the ID pin or role-switch mechanism is configured correctly. This test failure should be marked as a known board limitation or suppressed until the platform USB configuration is corrected.
4. Detail analysis attachment: failed_case_job262515_4_detailed.md

  Case 5: ** KVM_Driver (also KVM_EL2_DTB, KVM_Infra - all KVM tests failed for same reason)

1. Failed case: ** KVM_Driver (also KVM_EL2_DTB, KVM_Infra - all KVM tests failed for same reason)
2. Root cause: ** KVM driver initialization failed because Gunyah hypervisor is already running at EL2 on the Shikra IQS EVK platform. KVM requires exclusive EL2 access and cannot coexist with another hypervisor. This is a platform configuration issue, not a kernel regression. The PR patch (RCU config changes for RT kernel) is unrelated to this failure.
3. Possible fix: This is not a bug requiring a fix. The KVM tests should be skipped or marked as expected-fail on Gunyah-enabled platforms like Shikra IQS EVK. To enable KVM testing, the platform would need to boot without Gunyah (requires firmware/bootloader changes to not initialize Gunyah), which would break Gunyah-dependent virtualization features. Recommended action: Update CI test configuration to skip KVM tests on Gunyah platforms, or add platform detection to mark these as expected failures.
4. Detail analysis attachment: failed_case_job262515_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Shikra IQS EVK booted with Gunyah hypervisor occupying EL2 (boot selection: 'el2gh'), preventing KVM initialization. KVM requires exclusive access to EL2 (HYP mode) which is already occupied by Gunyah. This is a platform configuration issue, not a kernel regression.
3. Possible fix: Skip KVM tests on Shikra IQS EVK when booted with Gunyah hypervisor (el2gh boot selection), or reconfigure the board to boot without Gunyah if KVM testing is required. The two hypervisors are mutually exclusive and cannot coexist.
4. Detail analysis attachment: failed_case_job262515_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a kernel bug requiring a code fix. To enable KVM tests on shikra-iqs-evk, the LAVA job must boot with a non-Gunyah configuration (e.g., el2 or el1 boot selection instead of el2gh). Update the LAVA job definition or board configuration to select a boot mode that does not load Gunyah hypervisor, or exclude KVM tests from Gunyah-based test runs.
4. Detail analysis attachment: failed_case_job262515_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM module initialization failed because HYP (Hypervisor) mode is not available on the shikra-iqs-evk platform — kernel log shows "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression introduced by the PR (which only modifies RCU configs in rt.config). The shikra-iqs-evk board does not support EL2/HYP mode required for KVM. Either: (1) skip KVM tests on this platform in CI, or (2) verify the board firmware/bootloader is configured to boot the kernel at EL2 instead of EL1, or (3) use a different platform that supports virtualization for KVM testing.
4. Detail analysis attachment: failed_case_job262515_8_detailed.md

Job 262516 | SoC hamoa-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262516

Failed test cases in LAVA job 262516 (SoC: hamoa-evk).

  Case 1: Probe_Failure_Check — Pre-existing benign probe failures (not PR-introduced)

1. Failed case: Probe_Failure_Check — Pre-existing benign probe failures (not PR-introduced)
2. Root cause: The Probe_Failure_Check test detected two pre-existing, non-critical probe failures during boot: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (device/resource busy) — a known benign condition on hamoa-evk where the UEFI secure app may be in use by firmware; (2) regulatory.db firmware file missing (-ENOENT) — a known benign false positive because WiFi_OnOff test passed, confirming WiFi is fully functional. Neither failure is related to the PR's RCU configuration changes in rt.config.
3. Possible fix: Mark this test case as PASS with suppressed failures. The Probe_Failure_Check test should apply known-benign suppression rules: (1) qcom_qseecom_uefisecapp -EBUSY is a known platform-specific benign failure on hamoa-evk and should be added to the suppression list; (2) regulatory.db firmware load failure should already be suppressed per Rule 2 in lava-known-benign-failures.md when WiFi_OnOff passes. Update the test harness to exclude these patterns from failure detection, or document them as expected/benign for this platform.
4. Detail analysis attachment: failed_case_job262516_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec at address 0xaa00000 is not attached to any IOMMU group on hamoa-evk (x7181), indicating either the device failed to probe, the device tree is missing IOMMU bindings for this device, or the video codec driver is not enabled/loaded in this kernel configuration.
3. Possible fix: Verify the device tree for hamoa-evk includes the iommus property for the aa00000.video-codec node; if present, check kernel logs for video codec driver probe failures; if the driver is not probing, enable the required video codec driver config (likely CONFIG_VIDEO_QCOM_IRIS or similar) in the kernel configuration, or investigate why the driver probe is failing for this SoC.
4. Detail analysis attachment: failed_case_job262516_2_detailed.md

  Case 3: KVM_Driver — /dev/kvm device node not created

1. Failed case: KVM_Driver — /dev/kvm device node not created
2. Root cause: KVM driver initialization failed with "HYP mode not available" on Hamoa IoT EVK (iq-x7181-evk) — this is a platform-specific hardware limitation where the SoC/firmware does not support EL2 hypervisor mode, preventing KVM from creating the /dev/kvm device node. The failure is not PR-introduced (PR only modifies RCU config for RT kernels); KVM passes on other platforms (Lemans, Monaco, RB3gen2) in the same test run.
3. Possible fix: Mark KVM_Driver test as expected-fail or skip for hamoa-evk platform in the LAVA test plan — the platform does not support virtualization in hardware/firmware. If virtualization support is required for this platform, escalate to platform/firmware team to enable EL2/HYP mode in the bootloader/TrustZone configuration.
4. Detail analysis attachment: failed_case_job262516_3_detailed.md

  Case 4: KVM_EL2_DTB — Platform EL2/HYP Mode Not Available

1. Failed case: KVM_EL2_DTB — Platform EL2/HYP Mode Not Available
2. Root cause: KVM initialization failed at boot because the hamoa-evk platform does not support EL2 (hypervisor exception level). The kernel printed "kvm [1]: HYP mode not available" at line 3850, indicating the CPU is running at EL1 and cannot access EL2, which is required for KVM/virtualization. This is a platform hardware/bootloader limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: Exclude KVM tests from hamoa-evk CI by adding hamoa-evk to the KVM test skip list in the LAVA job definition, as this platform does not support virtualization. If EL2 support is required, modify the bootloader (ABL/XBL) to drop the kernel into EL2 and ensure TrustZone policy allows non-secure EL2 access.
4. Detail analysis attachment: failed_case_job262516_4_detailed.md

  Case 5: ** KVM_Infra — KVM driver initialization failure (HYP mode not available)

1. Failed case: ** KVM_Infra — KVM driver initialization failure (HYP mode not available)
2. Root cause: ** The hamoa-evk platform does not support ARM virtualization extensions (EL2/HYP mode). The KVM driver detected this during initialization with message "kvm [1]: HYP mode not available", preventing /dev/kvm device node creation. CONFIG_KVM is enabled in the kernel config, but the underlying hardware/firmware does not provide the required virtualization support.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The hamoa-evk board does not support KVM virtualization. Either: (1) Skip KVM tests on hamoa-evk in the CI test matrix, or (2) If KVM support is expected on this platform, verify the bootloader/firmware is configured to enable EL2 mode and that the SoC variant supports virtualization extensions.
4. Detail analysis attachment: failed_case_job262516_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform does not support HYP mode (EL2) required for KVM virtualization. Kernel message kvm [1]: HYP mode not available indicates hardware/firmware limitation on Hamoa IoT EVK, not a kernel regression.
3. Possible fix: Exclude KVM tests from Hamoa IoT EVK test suite, as this platform does not support virtualization. Alternatively, verify if firmware/bootloader configuration can enable EL2 mode for this SoC.
4. Detail analysis attachment: failed_case_job262516_6_detailed.md

Job 262517 | SoC qcs6490-rb3gen2

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262517

Failed test cases in LAVA job 262517 (SoC: qcs6490-rb3gen2).

  Case 1: Probe_Failure_Check — Pre-existing Infrastructure Firmware Gaps (Not PR-Introduced)

1. Failed case: Probe_Failure_Check — Pre-existing Infrastructure Firmware Gaps (Not PR-Introduced)
2. Root cause: The Probe_Failure_Check test detected two benign firmware loading failures that are pre-existing infrastructure/hardware limitations on qcs6490-rb3gen2: (1) regulatory.db firmware missing for cfg80211 wireless regulatory database (error -2 / -ENOENT), and (2) renesas_usb_fw.mem firmware missing for the Renesas xHCI PCIe USB controller (error -2 / -ENOENT). Both failures are unrelated to the PR's RCU configuration changes and do not impact system functionality — WiFi_OnOff and BT_ON_OFF tests passed, confirming wireless subsystem is operational despite the regulatory.db warning, and the Renesas USB controller is an optional PCIe add-on card not required for core platform functionality.
3. Possible fix: Suppress these two known benign firmware load failures in the Probe_Failure_Check test for qcs6490-rb3gen2 by adding them to the test's exclusion list. The failures are expected on this platform: (1) regulatory.db is not shipped in the rootfs and cfg80211 falls back to built-in regulatory rules successfully, and (2) the Renesas USB controller firmware is not provided because the PCIe card is optional hardware. No kernel or PR changes are required — this is a test infrastructure tuning issue.
4. Detail analysis attachment: failed_case_job262517_1_detailed.md

  Case 2: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test definition marked as failed because the Probe_Failure_Check test case detected kernel probe/firmware errors: (1) regulatory.db firmware load failure (error -2), and (2) xhci-pci-renesas driver probe failure (error -2). These are pre-existing platform issues unrelated to the PR's RCU configuration changes in rt.config.
3. Possible fix: The PR changes (adding CONFIG_RCU_EXPERT=y and CONFIG_RCU_NOCB_CPU=y to rt.config) do not cause these probe failures. These are known platform issues: (1) regulatory.db is a wireless regulatory database file that may be missing from the rootfs, and (2) xhci-pci-renesas requires firmware that may not be present. To resolve: either suppress Probe_Failure_Check failures for these known missing firmware files in the test configuration, or add the missing firmware files (regulatory.db and renesas_usb_fw.mem) to the rootfs image.
4. Detail analysis attachment: failed_case_job262517_2_detailed.md