CA is blocked by TA with open-tee

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
,
1

Hi

JP: 7.2 super

HW: AGX orin 32GB

We use CA to call TA, and several hours later, the ca is blocked and get no any message from ta

the kernel log error is :

2026-09-15T17:44:16.304347+08:00 localhost kernel: [TS:27215309321] INFO: task account_face:3685 blocked for more than 122 seconds.

2026-09-15T17:44:16.304368+08:00 localhost kernel: [TS:27215309706] Tainted: G O 6.8.12-1021-rt-tegra #1

2026-09-15T17:44:16.304370+08:00 localhost kernel: [TS:27215309782] “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.

2026-09-15T17:44:16.304372+08:00 localhost kernel: [TS:27215309851] task:account_face state:D stack:0 pid:3685 tgid:3655 ppid:2906 flags:0x00000004

2026-09-15T17:44:16.304375+08:00 localhost kernel: [TS:27215310031] Call trace:

2026-09-15T17:44:16.304377+08:00 localhost kernel: [TS:27215310095] __switch_to+0xe0/0x110

2026-09-15T17:44:16.304379+08:00 localhost kernel: [TS:27215310559] __schedule+0x37c/0x9a8

2026-09-15T17:44:16.304407+08:00 localhost kernel: [TS:27215310659] schedule+0x38/0xd0

2026-09-15T17:44:16.304409+08:00 localhost kernel: [TS:27215310748] schedule_timeout+0x1a8/0x1c0

2026-09-15T17:44:16.304411+08:00 localhost kernel: [TS:27215310887] wait_for_completion+0xc8/0x170

2026-09-15T17:44:16.304412+08:00 localhost kernel: [TS:27215311005] optee_notif_wait+0x194/0x1b8

2026-09-15T17:44:16.304413+08:00 localhost kernel: [TS:27215311246] optee_rpc_cmd+0x298/0x3b0

2026-09-15T17:44:16.304415+08:00 localhost kernel: [TS:27215311340] optee_smc_do_call_with_arg+0x40c/0x6e8

2026-09-15T17:44:16.304416+08:00 localhost kernel: [TS:27215311517] optee_invoke_func+0x134/0x218

2026-09-15T17:44:16.304417+08:00 localhost kernel: [TS:27215311591] tee_ioctl+0x122c/0x1680

2026-09-15T17:44:16.304418+08:00 localhost kernel: [TS:27215311659] __arm64_sys_ioctl+0xb4/0x100

2026-09-15T17:44:16.304419+08:00 localhost kernel: [TS:27215311796] invoke_syscall+0x50/0x128

2026-09-15T17:44:16.304420+08:00 localhost kernel: [TS:27215311947] el0_svc_common.constprop.0+0x48/0xf0

2026-09-15T17:44:16.304422+08:00 localhost kernel: [TS:27215312054] do_el0_svc+0x24/0x38

2026-09-15T17:44:16.304423+08:00 localhost kernel: [TS:27215312150] el0_svc+0x40/0x160

2026-09-15T17:44:16.304424+08:00 localhost kernel: [TS:27215312214] el0t_64_sync_handler+0x120/0x130

2026-09-15T17:44:16.304425+08:00 localhost kernel: [TS:27215312296] el0t_64_sync+0x194/0x198

please help us to check , thank you

3

hello smileandcry2023,

let me share the sequence..

  CA calls TA
    → OP-TEE asks Linux to wait
    → CA’s Linux thread sleeps in optee_notif_wait()
    → another secure-world execution must signal the condition
    → Linux optee_notif_send() wakes the CA thread

it’s a hung-task report instead of kernel crash. it has reported due to CA thread has been blocked too long.
please see-also.. Core — OP-TEE documentation documentation

hence,
please review your CA/TA implementation.
for instance, here’re some likely failures.
(1) TA waits for an event that no CA command triggers.
(2) Non-concurrent/single-instance TA causes a circular wait.
(3) TA fails to release a resource or finish an earlier command.
(4) CA/session lifecycle or multithreading is incorrect.

note, this only hide the call trace. you should not disable it since it would not fix the blocked CA.

4

Can we call the “TEE_InvokeTACommand()” interface in mutex context? like below

std::lock_guardstd::mutex lock(data_mutex);

{

 ...

 tee_invoketacommand()

 ...

}

5

hello smileandcry2023,

no, it may not resolve the issue.
please identify what condition the TA command is waiting for.

6

1, we added “efi=noruntime” to the cmdline and did the same test, and the issue was gone.

2, After we added “efi=noruntime” , we found the efivars were unavailable and nvbootctl couldn’t switch slot

3, we found a new way that after the system boot up, we umount the “/sys/firmware/efi/efivars”

with “efi=runtime” cmdline, did the same test, and the issue was also gone.

So does umount “/sys/firmware/efi/efivars” pose a risk to system stability?

7

hello smileandcry2023,

you may refer to.. efivarfs - a (U)EFI variable filesystem — The Linux Kernel documentation
umount /sys/firmware/efi/efivars should not effect system stability, but, efivarfs is the user-space interface for reading and modifying EFI variables; unmount efivarfs leaves EFI runtime enabled but prevents normal user-space EFI-variable access.
FYI, it can be remounted when needed, $ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars

8

Yes. we remount /sys/firmware/efi/efivars when we need to use efivars, but we want to know the root case that lead to the ca was blocked by the ta and un-mounting the /sys/firmware/efi/efivars let the issue gone. Thank you

9

(1) TA 在等 CA 不会触发的事件

业务均由 InvokeCommand 驱动，无故意异步等 event。可见的是 REE 堵在 wait。请问如何查 pending notif / completion 是否丢失？

(2) 单实例导致循环等待

已串行 Invoke，避免重叠。但「新 session 可用 + 旧 waiter 需 reboot」不太像单纯二次 Invoke 互等。请问该属性+RT+高频 Invoke 是否有已知 orphan/circular wait？诊断能否 A/B 改实例属性？

(3) TA 未释放资源/未完成前一命令

与「某条 outstanding 未完成」相符；新 session 仍可用，更像单条路径卡住而非 TA 全局死。请问卡住时如何 dump 在途命令/session？

(4) CA/session 生命周期或多线程有误

多 worker，但 Invoke 串行；挂起多见于 account_face。进程重启清不掉 waiter，疑状态残留驱动侧。请问 outstanding Invoke 时 kill CA，JP7.2/OP-TEE4.6+RT 是否已知 orphan waiter？除 reboot 外有无缓解？

11

hello smileandcry2023,

could you please examine your kernel sources, whether it has a timeout workaround in wq_sleep()?
it should looks like below..

diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c

+#define SLEEP_TIMEOUT (msecs_to_jiffies(100))

 struct wq_entry {
 	struct list_head link;
 	struct completion c;
@@ -170,7 +173,7 @@ static void wq_sleep(struct optee_wait_queue *wq, u32 key)
 	struct wq_entry *w = wq_entry_get(wq, key);
 
 	if (w) {
-		wait_for_completion(&w->c);
+		(void)wait_for_completion_timeout(&w->c, SLEEP_TIMEOUT);
 		mutex_lock(&wq->mu);
12

our kernel source is from JP7.2 and the version is 6.8.12

13

I has check drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c, and it doesn’t contain “struct wq_entry” structure. I think the rpc.c in our project is competely different with yours

14

hi

Could you help up to check the diff of the rpc.c

15

hello smileandcry2023,

actually, the idea doesn’t change. you may change the wait_for_completion to wait_for_completion_timeout.
BTW, is there a solid step list that can reproduce this issue?

16

1, you can use ca to call ta every 20ms for 4 hours. The ca and ta are the common examples

17

the rpc.c has no “wait_for_completion” function and I find other files has this function , do I chanage these?

image
image1086×960 124 KB

18

hello smileandcry2023,

the path looks like below..
kernel/3rdparty/canonical/linux-noble/drivers/tee/optee/rpc.c

rpc.c: handle_rpc_func_cmd_wq()
→ optee_notif_wait(key, timeout)

kernel/3rdparty/canonical/linux-noble/drivers/tee/optee/notif.c

notif.c: optee_notif_wait()
→ timeout != 0: wait_for_completion_timeout()
→ timeout == 0: wait_for_completion()

let’s check the timeout variable of optee_notif_wait(), if timeout is zero, secure world requested an indefinite wait.