Regression with fastrpc 1.0.6 on a few platforms

[lool]

Hi

Arun Kumar pinged me about regressions running fastrpc_tests on glymur-crd with 1.0.6 which he thinks could be permission related. I don't have a glymur-crd handy, but I tried running qcom-linux-testkit tests on platforms available in LAVA, first with latest qcom-next builds which have 1.0.6, then with an older build from Jul 30th which had version 1.0.2.

Build (qcom-deb-images)	Board	ADSP Signed	CDSP Signed	CDSP Unsigned	Job
2026-07-30 (c6ae6fc)	qcs6490-rb3gen2-vision-kit	PASS (3/3)	PASS (3/3)	PASS (3/3)	350836
2026-08-05 (70c4895)	qcs6490-rb3gen2-vision-kit	PASS (3/3)	FAIL (0/3)	FAIL (0/3)	350580

Failure signature (both CDSP Signed and CDSP Unsigned invocations, 2026-08-05 build):

ERROR 0x72: Unable to create FastRPC session on domain 3
ERROR 0x72: Failed to compute sum on domain 3
ERROR 0x72: Failed to find max on domain 3
hap_example function FAILED
[FAIL] libhap_example.so (error code: 0x72)

remoteproc state at time of failure:

rproc.adsp: remoteproc1 state=running fw=qcom/qcs6490/adsp.mbn name=adsp
rproc.cdsp: remoteproc3 state=offline fw=qcom/qcs6490/cdsp.mbn name=cdsp

rproc.cdsp reports state=offline, consistent with the CDSP FastRPC session
creation failure (error 0x72) above.

Boards that ran cleanly (2026-07-30 build, c6ae6fc)

For comparison, all domains passed (9/9 subtests) on these boards/jobs:

Board	Job
qcs615-ride	350834
monaco-evk	350835
qcs6490-rb3gen2-vision-kit	350836
qcs8300-ride	350837

(glymur-crd and lemans-evk are omitted from this report as those runs did not
execute the test on this build cycle: glymur-crd's test was skipped by SoC
blacklist, and lemans-evk's job hit an unrelated infra failure, login-action
timeout.)

[lool]

First, sorry for the private LAVA logs, I forgot to set them as public

We discussed the issues with Dmitry and Ekansh, we suspect it's a regression from boot binaries updates last week. Dmitry also remembers an issue with a specific RB3Gen2 that was fused and was used in the lab in the past.

We discovered that the fastrpc tests are not fully run for meta-qcom.

We also discovered that the debian user is not in the fastrpc group anymore in recent images because the creation of the group is deferred to startup instead of package installation.

Next steps:

• Loïc to retest on another rb3gen2
• Ekansh to chase someone or add a patch for all fastrpc tests to be run on meta-qcom CI
• Loïc to send a PR to fix fastrpc group membership in qcom-deb-images
• Ekansh to ask for qcom-linux-testkit tests for fastrpc on glymur-crd and agatti/rb1

[lool]

Also:

• Ekansh to share stability patches needed on top of 1.0.6 as 1.0.7 release is still at least a couple of weeks away

[lool]

Re-run of fastrpc tests on rb3gen2 (public): https://lava.infra.foundries.io/scheduler/job/352225
(this is actually with today's qcom-next build, but should be very close to yesterdays)

[ekanshibu]

testkit update:
https://github.com/qualcomm-linux/lava-test-plans/pull/85/changes
qualcomm-linux/meta-qcom#2913

RB1 information is share over here:
#370

[quic-vkatoch]

Loïc Minier (@lool), is regression still observed with v1.0.7?

[lool]

Loïc Minier (@lool), is regression still observed with v1.0.7?

I expect they are still present with the fastrpc 1.0.7 code, but not visible with fastrpc as packaged in the deb packages since I'm now carrying the udev patch as a workaround.