问题：
ORT推理时使用EP spacemit推理时，每推理一次控制台输出“alloc failed(131072)”，使用EP CPU推理时不会报错
使用模型：
从 https://gitee.com/bianbu/spacemit-demo/blob/main/examples/CV/arcface/model/download_model.sh 下载的 arcface_mobilefacenet_cut.q.onnx
测试ORT版本
spacemit-ort.riscv64.2.0.1.tar.gz （该版本出现上述 alloc failed(131072) 问题）
spacemit-ort.riscv64.1.2.3.tar.gz （无该问题，但EP spacemit的耗时比EP CPU要长）
设备：
Muse Pi Pro (X60 * 8) , 8GB内存
测试程序
onnxruntime_perf_test、根据文档编写的调用ORT代码均有相同表现
测试了其他模型： arcface_mobilefacenet_cut.onnx 和另一个我自己的SSD定位模型（非量化onnx，在PC上和ORT 1.2.3推理均正常），问题表现与描述一样
试一下root，以及sudo chmod 777 /dev/tcm，./bin/onnxruntime_perf_test arcface_mobilefacenet_cut.q.onnx -e spacemit -r 10 -x 1 -S 1 -s -I -c 1确认没有alloc failed，性能就正常了
感谢您的回复，尝试了chmod增加权限、切换sudo运行、直接在root命令行执行，但目前还存在这个问题
spacemit-k1-x-MUSE-Pi-Pro-board# pwd
/home/admin/libs/spacemit-ort.riscv64.2.0.1
spacemit-k1-x-MUSE-Pi-Pro-board# ls -lA /dev/tcm
crwxrwxrwx 1 root root 10, 122 Jan 17 2025 /dev/tcm
spacemit-k1-x-MUSE-Pi-Pro-board# ldd bin/onnxruntime_perf_test
linux-vdso.so.1 (0x0000003fbd5cb000)
libatomic.so.1 => /lib/riscv64-linux-gnu/libatomic.so.1 (0x0000003fbd5a6000)
libonnxruntime.so.1 => /home/admin/libs/spacemit-ort.riscv64.2.0.1/lib/libonnxruntime.so.1 (0x0000003fbc400000)
libstdc++.so.6 => /lib/riscv64-linux-gnu/libstdc++.so.6 (0x0000003fbc000000)
libm.so.6 => /lib/riscv64-linux-gnu/libm.so.6 (0x0000003fbd528000)
libgcc_s.so.1 => /lib/riscv64-linux-gnu/libgcc_s.so.1 (0x0000003fbd50a000)
libc.so.6 => /lib/riscv64-linux-gnu/libc.so.6 (0x0000003fbc282000)
/lib/ld-linux-riscv64-lp64d.so.1 (0x0000003fbd5cd000)
spacemit-k1-x-MUSE-Pi-Pro-board# ./bin/onnxruntime_perf_test arcface_mobilefacenet_cut.q.onnx -e spacemit -r 10 -x 1 -S 1 -s -I -c 1
using SpaceMITExecutionProvider
Setting intra_op_num_threads to 1
alloc failed(131072)
alloc failed(131072)
# 省略大量 alloc failed
alloc failed(131072)
Session creation time cost: 0.567197 s
First inference time cost: 153 ms
Total inference time cost: 0.56988 s
Total inference requests: 10
Average inference time cost: 56.988 ms
Total inference run time: 0.569996 s
Number of inferences per second: 17.544
Avg CPU usage: 12 %
Peak working set size: 63348736 bytes
Avg CPU usage:12
Peak working set size:63348736
Runs:10
Min Latency: 0.0558249 s
Max Latency: 0.0627359 s
P50 Latency: 0.0564374 s
P90 Latency: 0.0627359 s
P95 Latency: 0.0627359 s
P99 Latency: 0.0627359 s
P999 Latency: 0.0627359 s
是否可能是系统中存在同名so导致呢？
发现ort的so未链接到2.0.1的ep so
spacemit-k1-x-MUSE-Pi-Pro-board# pwd
/home/admin/libs/spacemit-ort.riscv64.2.0.1/lib
spacemit-k1-x-MUSE-Pi-Pro-board# ls -lA
total 20872
-rw-r--r-- 1 admin admin 5944 Nov 6 13:57 libonnxruntime_providers_shared.so
lrwxrwxrwx 1 admin admin 19 Nov 6 13:57 libonnxruntime.so -> libonnxruntime.so.1
lrwxrwxrwx 1 admin admin 33 Nov 6 13:57 libonnxruntime.so.1 -> libonnxruntime.so.1.20.2+spacemit
-rw-r--r-- 1 admin admin 17532384 Nov 6 13:57 libonnxruntime.so.1.20.2+spacemit
lrwxrwxrwx 1 admin admin 19 Nov 6 13:57 libspacemit_ep.so -> libspacemit_ep.so.2
lrwxrwxrwx 1 admin admin 23 Nov 6 13:57 libspacemit_ep.so.2 -> libspacemit_ep.so.2.0.1
-rw-r--r-- 1 admin admin 3829168 Nov 6 13:57 libspacemit_ep.so.2.0.1
spacemit-k1-x-MUSE-Pi-Pro-board# ldd libonnxruntime.so
linux-vdso.so.1 (0x0000003f87d98000)
libstdc++.so.6 => /lib/riscv64-linux-gnu/libstdc++.so.6 (0x0000003f86800000)
libm.so.6 => /lib/riscv64-linux-gnu/libm.so.6 (0x0000003f87cfe000)
libgcc_s.so.1 => /lib/riscv64-linux-gnu/libgcc_s.so.1 (0x0000003f87ce0000)
libc.so.6 => /lib/riscv64-linux-gnu/libc.so.6 (0x0000003f86a82000)
/lib/ld-linux-riscv64-lp64d.so.1 (0x0000003f87d9a000)
# cd /
# find | grep libspacemit_ep.so
./opt/spacemit-asr/spacemit_ort/libspacemit_ep.so.1.2.2
./usr/lib/libspacemit_ep.so
./usr/lib/libspacemit_ep.so.1.2.2
./usr/lib/python3.12/dist-packages/spacemit_ort/libspacemit_ep.so.1.2.2
./usr/lib/libspacemit_ep.so.1
./home/admin/libs/spacemit-ort.riscv64.2.0.1/lib/libspacemit_ep.so
./home/admin/libs/spacemit-ort.riscv64.2.0.1/lib/libspacemit_ep.so.2
./home/admin/libs/spacemit-ort.riscv64.2.0.1/lib/libspacemit_ep.so.2.0.1
libonnxruntime不会主动链接ep.so，它是动态加载的，你如果export LD_LIBRARY_PATH=xxx/spacemit-ort.riscv64.2.0.1/lib/ 这样就优先用这里面的so，另外，alloc failed实际就是tcm alloc failed，可能有别的程序在用，或者以前有进程意外挂了没能正常清掉使用，也会这样，不妨reboot一下
重启后解决了，感谢帮助！
首次启动后运行了桌面上的AI Fusion X，运行了各个Demo后未重启，可能是未释放资源
发现系统启动后，只要在图形界面登陆进系统，就出现2个进程占用/dev/tcm
admin@spacemit-k1-x-MUSE-Pi-Pro-board ~
% cat /proc/2751/cmdline
python/opt/spacemit-ai-tool/ai-tool-io%
这两个进程kill之后，又会自动启动，请问如何彻底关闭呢
这个服务是ai-fusion-x的后台服务，可以卸载spacemit-ai-fusion-x，或者注释掉/usr/bin/spacemit-ai-fusion-x-service中相关服务，并重新启动