Toybrick

标题: 在rk3399pro上使用rknn的接口rknn_init内部概率性崩溃！！！ [打印本页]

作者: panziwen86 时间: 2020-6-5 10:44
标题: 在rk3399pro上使用rknn的接口rknn_init内部概率性崩溃！！！
因为在项目中发现rknn_init接口出错然后引起程序直接崩溃，然后更换很多个模型，升级rknn_api发现都有这个问题，然后直接用官方提供的rknn_apiSDK中提供的rknn_ssd.cpp，稍微修改，多进程反复使用rknn_init初始化模型，发现也有此问题，而且时间长了npu_transfer_proxy这个npu的服务也会崩溃，而且有时候一个进程在调用rknn_api时出错或者崩溃了，会影响其他使用rknn_api的进程，不管是rknn_api调用崩溃，还是npu_transfer_proxy崩溃，都必须重启系统才能恢复，这在线上是一个非常严的问题，希望官网能及时解决，下面附件中是我修改的测试用例，和崩溃现象图片。

作者: jefferyzhang 时间: 2020-6-5 11:00
1. 什么板子
2. 什么固件
3. 什么系统

作者: panziwen86 时间: 2020-6-5 13:17

jefferyzhang 发表于 2020-6-5 11:00
1. 什么板子
2. 什么固件
3. 什么系统

您好，板子是TB-96AI Debian10固件v1.0-20191126

作者: leok 时间: 2020-6-5 14:43
升级完rknn，主机需要重启，或者先卸载旧rknn再升级新rknn，保证npu_transfer_proxy是新的，同时npu_transfer_proxy进程需要重启。

有按以上操作吗？

作者: panziwen86 时间: 2020-6-5 15:40

leok 发表于 2020-6-5 14:43
升级完rknn，主机需要重启，或者先卸载旧rknn再升级新rknn，保证npu_transfer_proxy是新的，同时npu_transf ...

您好，应该都是最新的：
npu_transfer_proxy:
I NPUTransfer: Starting NPU Transfer Proxy, Transfer version 2.0.0 (8f9ebbc@2020-04-03T09:12:43)
rknn_api:
D RKNNAPI: RKNN VERSION:
D RKNNAPI: API: 1.3.2 (9eebd73 build: 2020-04-02 14:54:02)
D RKNNAPI: DRV: 1.3.1 (6ebb4d7 build: 2020-01-02 09:37:58)
我主机重启过，也是一样的问题。我现在大概是四个进程测试，跑几个小时，npu_transfer_proxy这个进程就不见了。。。

作者: leok 时间: 2020-6-5 15:59

panziwen86 发表于 2020-6-5 15:40
您好，应该都是最新的：
npu_transfer_proxy:
I NPUTransfer: Starting NPU Transfer Proxy, Transfer ve ...

1、首先查看下内存；
2、尝试一个进程验证是否也有同样问题；

作者: chenxiao1116 时间: 2020-6-6 23:07
我们用的时候也有类似问题；
RK方案稳定性确实不怎么样

作者: leok 时间: 2020-6-7 11:10

chenxiao1116 发表于 2020-6-6 23:07
我们用的时候也有类似问题；
RK方案稳定性确实不怎么样

如遇见问题可以开帖，把问题列出来。并把信息提供全。提供复现脚本。

作者: iamher0 时间: 2020-6-8 08:56
我也遇到过这个问题，4路视频，每路3-4个模型，重启程序的时候很容易出现这个问题
复现步骤：多进程loop{rknn_init,inference n time,rknn_destory}

题主发的复现代码就可以

作者: panziwen86 时间: 2020-6-8 09:40

leok 发表于 2020-6-5 15:59
1、首先查看下内存；
2、尝试一个进程验证是否也有同样问题；

你好，查看了内存没有异常，一个进程测试验证，发现也有问题，只是发生的时间可能长点，
上周五开始测试，周一过来发现测试进程崩溃了，但npu_transfer_proxy这个进程还在，重启测试
进程发现直接崩溃在rknn_init接口里了，然后重启npu_transfer_proxy，再启动测试进程，发现
还是有问题，rknn_init接口一直报错，只能重启系统才能恢复正常了，测试程序崩溃日志已上传
附件中，测试程序代码就是之前上传的。

作者: iamher0 时间: 2020-6-8 16:21

leok 发表于 2020-6-7 11:10
如遇见问题可以开帖，把问题列出来。并把信息提供全。提供复现脚本。

你们是否尝试了复现这个问题？

作者: jefferyzhang 时间: 2020-6-8 16:35

iamher0 发表于 2020-6-8 16:21
你们是否尝试了复现这个问题？

很遗憾，我们没能复现该问题。
烤鸡72小时均无问题

作者: iamher0 时间: 2020-6-8 16:44

jefferyzhang 发表于 2020-6-8 16:35
很遗憾，我们没能复现该问题。
烤鸡72小时均无问题

你们是在 96 AI board上复现的吗？难道复现环境有什么差异？

作者: jefferyzhang 时间: 2020-6-8 16:45

iamher0 发表于 2020-6-8 16:44
你们是在 96 AI board上复现的吗？难道复现环境有什么差异？

我们没有96Ai板子，这个是代理商做的。

作者: jefferyzhang 时间: 2020-6-8 16:47
还有烤鸡不是烤你的程序，是烤我们自己的ssd。
我们没有义务帮客户程序烤鸡，我们只保证自己代码是稳定的，基本就可以排除是系统问题。
剩下的就是检查你们自己代码问题。

作者: iamher0 时间: 2020-6-8 16:50

jefferyzhang 发表于 2020-6-8 16:45
我们没有96Ai板子，这个是代理商做的。

上面不是用的你们的核心板吗？核心板的方式和官方的开发板用的驱动和API都是一样的吧？

作者: jefferyzhang 时间: 2020-6-8 16:51

iamher0 发表于 2020-6-8 16:50
上面不是用的你们的核心板吗？核心板的方式和官方的开发板用的驱动和API都是一样的吧？ ...

是的。理论上说96AI板子质量不会有问题

作者: iamher0 时间: 2020-6-8 16:55
本帖最后由 iamher0 于 2020-6-8 16:57 编辑

jefferyzhang 发表于 2020-6-8 16:47
还有烤鸡不是烤你的程序，是烤我们自己的ssd。
我们没有义务帮客户程序烤鸡，我们只保证自己代码是稳定的， ...

这个用例是否包含在你们的烤鸡程序里？反复多进程并发初始化-推理-销毁
我直觉这是驱动或SDK的逻辑问题

毕竟这个问题我们也是实实在在的出现了

作者: jefferyzhang 时间: 2020-6-8 16:58

iamher0 发表于 2020-6-8 16:55
这个用例是否包含在你们的烤鸡程序里？反复多进程并发初始化-推理-销毁

毕竟这个问题我们也是实实在在的 ...

为啥要不停销毁？NPU的session建立完就一直在用了，不需要销毁。
不同模型不停切换session即可。

作者: iamher0 时间: 2020-6-8 17:04
本帖最后由 iamher0 于 2020-6-8 17:07 编辑

jefferyzhang 发表于 2020-6-8 16:58
为啥要不停销毁？NPU的session建立完就一直在用了，不需要销毁。
不同模型不停切换session即可。 ...

正常情况，我们不会不停的销毁，我们是在线上设备发现的问题，4个进程，4路视频，每个进程跑大概3个模型，当重启程序的时候，会出现无论如何都重启不成功，只有重启设备

为了快速复现这个问题：快速模拟重启行为，才会不停的init,inference,destory,如果这么测没有问题的话，就说明底层没有问题是应用的问题
我们也怀疑过是模型的问题，但用rockx也同样出现问题

作者: jefferyzhang 时间: 2020-6-8 17:07

iamher0 发表于 2020-6-8 17:04
正常情况，我们不会不停的销毁，我们是在线上设备发现的问题，4个进程，4路视频，每个进程跑大概3个模型 ...

异构运算，你的快速能保证和NPU同步么，不能的话拼命销毁重建模型，考虑过NPU那边会不会爆掉么？

作者: iamher0 时间: 2020-6-8 17:14
本帖最后由 iamher0 于 2020-6-8 17:20 编辑

jefferyzhang 发表于 2020-6-8 17:07
异构运算，你的快速能保证和NPU同步么，不能的话拼命销毁重建模型，考虑过NPU那边会不会爆掉么？ ...

我觉得这是你们应该考虑的吧，从驱动或SDK里面加上保证稳定性的逻辑

为什么复现代码都提供了，还是一堆的问题，而不去复现呢？
而且我们不频繁操作也同样会出现问题，我们是多进程使用，NPU的同步不应该让应用层去考虑

作者: jefferyzhang 时间: 2020-6-8 17:25

iamher0 发表于 2020-6-8 17:14
我觉得这是你们应该考虑的吧，从驱动或SDK里面加上保证稳定性的逻辑

为什么复现代码都提供了，还是一堆的 ...

因为我们不是NPU的人啊，NPU那边就是说了不能频繁建立和销毁模型，你要我怎么弄？
如果你有FAE渠道，建议你通过FAE给NPU部门提问题，社区这里在公司问题处理优先级是最低的。

作者: iamher0 时间: 2020-6-8 17:30
好的，非常感谢你的耐心答复，也希望你能把我们的疑问反馈给NPU的相关人员

因为在正常的程序重启过程中：3个模型销毁重建就是6次操作，同时另外3个进程的9个模型也在推理
中间可能出现了同步的问题

作者: panziwen86 时间: 2020-6-8 21:35

jefferyzhang 发表于 2020-6-8 17:25
因为我们不是NPU的人啊，NPU那边就是说了不能频繁建立和销毁模型，你要我怎么弄？
如果你有FAE渠道，建议 ...

你好，我这边再给你们提供一个简单完整的测试用例，代码只有几十行，只需要拷贝到系统里，执行make install编译，
然后进入test/bin目录执行./start.sh脚本就可以运行起来，可以拷贝test目录，多进程测试。
现在测试发现的问题是rknn_api和npu服务进程都存在崩溃现象，而且是必现，不管是参数错误、内存不够还是
其它问题，都不应该崩溃，最多是返回错误，崩溃肯定是程序问题，希望尽快解决！！！

作者: jefferyzhang 时间: 2020-6-8 22:38

panziwen86 发表于 2020-6-8 21:35
你好，我这边再给你们提供一个简单完整的测试用例，代码只有几十行，只需要拷贝到系统里，执行make insta ...

1. 本社区是工程师交流的地方，不是提交bug的地方，NPU部门同事只会偶尔会上来看看问题。
2. 咨询过NPU的同事，你这么用就是有问题的，不允许频繁的init和destroy，NPU来不及释放肯定会出错
3. 如果有疑问，请向FAE咨询

作者: zhanghq 时间: 2020-6-9 09:43

jefferyzhang 发表于 2020-6-8 22:38
1. 本社区是工程师交流的地方，不是提交bug的地方，NPU部门同事只会偶尔会上来看看问题。
2. 咨询过NPU的 ...

1、如果不是提交Bug的地方，我们这些开发者来这里还有什么价值？我们买的是板子，怎么着FAE？
2、前面的帖子已经说明了，这个测试是为了快速复现问题，真正的问题是当实例重启的时候根本没法重启起来，因为我们的实例里有多个模型，当重启的时候就会有多次init和destroy，你们应该在接口层面提供阻塞或者错误代码，否则我们也不知道何时可以正常使用

作者: panziwen86 时间: 2020-6-9 09:59

jefferyzhang 发表于 2020-6-8 22:38
1. 本社区是工程师交流的地方，不是提交bug的地方，NPU部门同事只会偶尔会上来看看问题。
2. 咨询过NPU的 ...

1、这只是我的测试代码，为了更快的复现问题，以便解决，我们在具体项目中并没有这么频繁的init和destroy，但同样也出现此问题；
2、你说不允许频繁的init和destroy，sdk的文档中没这么写吧，那多少频率算频繁呢？NPU来不及释放可以返回错误码，不一定要崩溃吧，感觉这都说不过去呀；
3、我们没有要求你们现在就立马解决问题，只是希望你们向你们的FAE反馈一下问题，而你直接就说这是我们使用上的问题，要我自己联系FAE，但我也没有联系方式呀，更没有讨论的平台啊。

作者: iamher0 时间: 2020-6-9 10:03
我怎么感觉，他们很抵触问题，不正面回答，而且态度上就是程序员易犯的思维模式“有问题肯定是别人的问题”

作者: jefferyzhang 时间: 2020-6-9 18:57

iamher0 发表于 2020-6-9 10:03
我怎么感觉，他们很抵触问题，不正面回答，而且态度上就是程序员易犯的思维模式“有问题肯定是别人的问题” ...

没办法，我们也只是普通工程师，偶尔上来交流问题而已，你们问我们的问题，我们报给NPU部门，他们就这么回得。
但是这个你也必须理解，他们手上非常多立项客户，不会去在意我们论坛客户的。。。

作者: jefferyzhang 时间: 2020-6-9 18:59

panziwen86 发表于 2020-6-9 09:59
1、这只是我的测试代码，为了更快的复现问题，以便解决，我们在具体项目中并没有这么频繁的init和destroy ...

早都反馈过了，不是你一家有这问题的，上一个客户直接FAE报的，他们看完就是说NPU不停初始化不停销毁内存爆掉了。
别提什么错误码了，我这里一堆问题返回的错误码都不靠谱，我们最终是直接在1808上调试才能知道真正错误原因的。

作者: jefferyzhang 时间: 2020-6-9 19:00
你们如果有FAE途径，就直接走FAE，我们内部员工报10个bug都没fae客户报一个bug来的好使。。。

作者: panziwen86 时间: 2020-6-10 09:21

jefferyzhang 发表于 2020-6-9 18:59
早都反馈过了，不是你一家有这问题的，上一个客户直接FAE报的，他们看完就是说NPU不停初始化不停销毁内存 ...

好的，谢谢了

欢迎光临 Toybrick (https://t.rock-chips.com/)