[参考译文] Linux/AM5728：使用两个 DSP 时、邮箱出现故障

下面是一些器件树详细信息：

dra74x.dtsi：
mailbox5｛(&M)
mbox_ippu1_ipc3x：mbox_ippu1_ipc3x｛
TI、mbox-TX =<6 2 2>；
ti、mbox-Rx =<4 2 2>；
STATUS ="禁用"；
}；
mbox_dsp1_ipc3x：mbox_dsp1_ipc3x｛
TI、mbox-TX =<5 2 2>；
TI、mbox-Rx =<1 2 2>；
STATUS ="禁用"；
}；
}；

mailbox6｛(&M)
mbox_ipu2_ipc3x：mbox_ipu2_ipc3x｛
TI、mbox-TX =<6 2 2>；
ti、mbox-Rx =<4 2 2>；
STATUS ="禁用"；
}；
mbox_dsp2_ipc3x：mbox_dsp2_ipc3x｛
TI、mbox-TX =<5 2 2>；
TI、mbox-Rx =<1 2 2>；
STATUS ="禁用"；
}；
}；

自定义 DTS 文件：
dsp1｛.dsp1｝(&D)
状态="正常"；
Memory-region =<&dsp1_CMA_pool>；
mbox =<&mailbox5 &mbox_dsp1_ipc3x>；
计时器=<&timer5>；
}；

dsp2｛.dsp2｝
状态="正常"；
Memory-region =<&dsp2_CMA_pool>；
mbox =<&mailbox6 &mbox_dsp2_ipc3x>；
计时器=<&timer6>；
}；

软件团队已收到通知。 他们将在这里作出回应。

您好、Gerard、

我正在尝试进行设置、以便在 TI EVM 上重现此过程。 从错误消息中、我假设需要 MessageQ 流量。 我的想法是让我们的 ex02_MessageQ 示例运行、然后解除对两个 DSP 的绑定。 然后再次绑定、重新运行和重新解除绑定。 设置时可能会有问题、但让我们看看我能得到什么。准备好东西需要一段时间。

雷克斯

谢谢你。 当它发生故障时、我通常会看到如下所示的 Oops。 在这种情况下、ARM 上的应用软件刚刚关闭了 DSP 的 MessageQ、并准备好销毁主机 MessageQ。

[950.515904][0000002c]* PgD=9cfcb003、* PMD=9cfb6003、* Pte=00000000
[950.52361]内部错误：Oops：A07 [#1]抢占 SMP ARM
[950.527874]链接模块：cmemk (O) rpmsg_proto virtio_rpmsg_bus omap_remoteproc virtio_ring virtipfpfgpa_config bnep hci_uart btbcm usb_fned rfmCOMM xhci_plat_hcmp_hdwxhcmc_domap_hipt_core_tb_gp_ipt_decure_v_ipt_en_ipt_c_decur_ipt_ipt_ipt_en_c_decur_ipt_ipt_ipt_en_ipt_c_dec_decur_ipt_ipt_ipt_c_decur_ip_ip_t_ipt_c_decur_ip_ipt_ipt_t_iptx_t_t_ipt_t_ipt_iptx_
[950.570792] CPU：0 PID：1104 Comm：hwtest_server 被污染：g WC O 4.4.4.41-gf9f6f0db2d #1
[950.579616]硬件名称：通用 DRA74X (平展器件树)
[950.585736]任务：dd34d400 ti：de0bc000 task.ti：de0bc000
[950.591168] PC 位于 rpmsg_sock_release+0xe4/0x11c [rpmsg_proT]
[950.597198] lr 位于0xfffffa
[950.600355]电脑：[ ] LR：[ ] PSR：80060013
[950.600355] sp：de0bdee8 IP：dd52b774 FP：de0bdefc
[950.611882] R10：ddbd4c08 R9：00000008 R8：dd51c660
[950.617129] r7：de047e50 R6：00000000 R5：dd4548c0 R4：dcc50800
[950.62365] r3：00000000 r2：00000000 r1：00000003 r0：bf2771dc
[950.630243]标志：模式 SVC_32 ISA ARM 段用户上 FIQ 上的 Nzcv IRQ
[950.637408]控制：30c5387d 表：9ccb16c0 DAC：fffffffffd
[950.643179]进程 hwtest_server (pid：1104、栈限制= 0xde0bc218)
[950.649823]栈：(0xde0bdee8至0xde0be000)
[950.654199] DEe0： dd4548c0 bf2773c0 de0bdf14 de0bdf00 c0559e1c bf276654
[950.662414] df00：ddbd4c00 dd4548e0 de0bdf24 de0bdf18 c0559eac c0559e00 de0bdf5c de0bdf28
[950.670627] df20：c012632c c0559ea4 00000000 de0bdf54 dd34d770 c0b3189c 00000000
[950.678839] df40：dd34d400 c000fbe4 de0bc000 00000000 de0bdf6c de0bdf60 c01264dc c01262b0
[950.687055] df60：de0bdf8c de0bdf70 c004d51c c01264d8 de0bc010 c000fbe4 de0bdfb0 de0bc000
[950.695268] df80：de0bdfag0bdf90 c0012cf4 c004d490 b5795fa0 afbfda10 00000011 00000006
[950.703483] dfa0：00000000 de0bdfb0 c000fa8c c0012c4c 00000000 afbff4d4 00000002 00000000
[950.711697] dfc0：b5795fa0 afbfda10 00000011 00000006 b5795eb4 b2500880 00000003 00000006
[950.719910] dfe0：00000000 afbfda08 afbff910 b5ce4764 80060010 00000011 82993410 00000028
[950.728120]回溯：
[950.730595][ ](rpmsg_sock_release [rpmsg_proto ])、来自[ ](SOCK_RELEAS+0x28/0xa4)
[950.739941] R5：bf2773c0 R4：dd4548c0
[950.743550][ ](SOCK_RELEASE)从[ ](SOCK_CLOC+0x14/0x1c)
[950.750976] R5：dd4548e0 R4：ddbd4c00
[950.754591][ ](SOCK_CLOSE)、从[ ](_fput + 0x88/0x1d8)
[950.761587][ ](__fput)从[ ](___fput + 0x10/0x14)
[950.768314] R10：00000000 R9：de0bc000 R8：c000fbe4 r7：dd34d400 R6：00000000 R5：c0b3189c
[950.776218] R4：dd34d770
[950.778775][ ](___fput)、来自[ ](Task_Work_run+0x98/0xcc)
[950.786123][ ](task_work 运行)从[ ](do_work _暂挂+b4 /b8)
[950.794072] r7：de0bc000 R6：de0bdfb0 R5：c000fbe4 R4：de0bc010
[950.799793][ ](Do_Work_Pending)、来自[ ](SLOW_work 挂起+ 0xc/0x20)
[950.808003] r7：00000006 R6：00000011 R5：afbfda10 R4：b5795fa0
[950.813719]代码：e30701dc e3a02000 e34b0f27 e59331d0 (e583202c)
[950.822682]--[结束线迹 d0089e7fbb7baa73 ]--

[引用 user="Rex Chang"]
我正在尝试进行设置、以便在 TI EVM 上重现此过程。 从错误消息中、我假设需要 MessageQ 流量。 我的想法是让我们的 ex02_MessageQ 示例运行、然后解除对两个 DSP 的绑定。 然后再次绑定、重新运行和重新解除绑定。 设置时可能会有问题、但让我们看看我能得到什么。准备好东西需要一段时间。

[/报价]

Rex、

在示例 TI MessageQ 应用程序运行时、是否幸运地获得此测试设置？

谢谢

您好、Gerard、

我对反应缓慢表示歉意。 我遇到了与您不同的错误。 我尝试在1个 DSP 场景中复位每个 DSP、并通过不同的复位间隔来查看差异。

使用 numLoops：100000；payloadSize：8，ProcID：4
输入 MessageQApp_execute
使用 numLoops：100000；payloadSize：8，ProcID：3
输入 MessageQApp_execute
本地 MessageQId：0x81
本地 MessageQId：0x80
MessageQ_open [-1]中出错
MessageQ_open [-1]中出错
离开 MessageQApp_execute

离开 MessageQApp_execute

雷克斯

如果只使用单个 DSP 运行循环测试、它是否适合您？

您好、Gerard、

在一个 DSP 情况下、它在第10次迭代时得到第一个误差、在第11次迭代时恢复、然后在此后得到误差。 从代码中、似乎错误来自名称服务器。 尝试了解什么是抱怨、并检查是否可能、是否没有彻底解决问题。

雷克斯

[引用 user="Rex Chang"]
在一个 DSP 情况下、它在第10次迭代时得到第一个误差、在第11次迭代时恢复、然后在此后得到误差。 从代码中、似乎错误来自名称服务器。 尝试了解什么是抱怨、并检查是否可能、是否没有彻底解决问题。

[/报价]

我认为这不适用于您和您的 EVM 测试、但在我们的定制硬件上、如果我们在关闭 DSP 电源之前未重置 PCIe、我们会遇到如您所述的间歇性错误。

Rex、

您能告诉我您使用的 TI IPC 库/MessageQ 示例应用的哪个版本、并提供链接吗？

谢谢

您好、Gerard、

我使用了 ProcSDK 3.3.0.4、IPC 版本应为3.44.01.01。 MessageQBench 包含在 Linux 文件系统中。 可从 software-dl.ti.com/.../index_FDS.html 下载 Linux ProcSDK 3.3.0.4

我要测试的 shell 脚本：

I=0
而事实是如此
操作
让"i=i+1"
echo "================================================================================ "
echo "================================================================================ "
ECHO "测试#$I"
echo "================================================================================ "

MessageQBench 100000 2 4 &
MessageQBench 100000 2 3 &

睡眠2.

回波""
回声"---------------------------------------- "
回波""

echo 40800000.DSP >/sys/bus/platform/drivers/omap-rproc/unbind
echo 41000000.dsp >/sys/bus/platform/drivers/omap-rproc/unbind

回波""
回声"---------------------------------------- "
回波""

睡眠15.

echo 40800000.DSP >/sys/bus/platform/drivers/omap-rproc/bind
echo 41000000.dsp >/sys/bus/platform/drivers/omap-rproc/bind

回波""
回波""
睡眠20.
完成

雷克斯

您好、Gerard、

在我看来、邮箱错误似乎是邮箱队列在被占用之前被填满。 如果您的应用程序使用邮箱、则在邮箱堵塞时可能需要执行一些操作。 我们在内部进行检查、以查看 DSP 出现后 TX 队列中的待处理消息是否会重新发送、但您是否可以尝试增加 TX_queue_LEN 以覆盖 DSP 停机时间？ 我们无法理解为什么2个 DSP 与仅1个 DSP 方案不同、因为我们使用单独的邮箱与 DSP1和 DSP2通信。 两者都有自己的状态、并且行为方式与一个处理器运行时完全相同。 这可能是两个 DSP 都使用了相同的 TX Fifo_id、这会加剧它的恶化。

雷克斯

您好、Gerard、

以下是有关您所遇到错误的更多信息。  

Remoteproc 会根据10秒的超时过期尝试自动挂起。在此期间、没有与 DSP 通信。 在进入挂起状态之前、它会再向 DSP 发送一条消息。 当尝试发送消息时、挂起的 DSP 实际上会被唤醒。 DSP 读取消息会在硬件 FIFO 中创建空间以再发送一条消息。 由于 DSP 上没有处理消息、因此 Remoteproc 最后一次尝试由于队列已满而失败。 因此、在错误中、出现"OMAP-remoteproc：pm mbox_send_msg failed (OMAP-remoteproc：pm mbox_send_msg 失败)"错误、该错误是由达到 TX_queue_LEN 引起的。

雷克斯

[引用 user="Rex Chang"]
在我看来、邮箱错误似乎是邮箱队列在被占用之前被填满。 如果您的应用程序使用邮箱、则在邮箱堵塞时可能需要执行一些操作。 我们在内部进行检查、以查看 DSP 出现后 TX 队列中的待处理消息是否会重新发送、但您是否可以尝试增加 TX_queue_LEN 以覆盖 DSP 停机时间？ 我们无法理解为什么2个 DSP 与仅1个 DSP 方案不同、因为我们使用单独的邮箱与 DSP1和 DSP2通信。 两者都有自己的状态、并且行为方式与一个处理器运行时完全相同。 这可能是两个 DSP 都使用了相同的 TX Fifo_id、这会加剧它的恶化。

[/报价]

我们的应用程序不直接使用邮箱。 我们目前仅直接使用 MessageQ。 如上所述、我们为每个 DSP 指定了单独的邮箱、因此当两个 DSP 都处于活动状态时、我不会认为存在任何类型的冲突。

Gerard、

MessageQ 使用邮箱、但我们同意每个 MessageQ 应使用不同的集、而不应成为您发现问题的直接原因。 DSP 在您的测试中唤醒时、它们是否能够使用消息？ 在重置邮件之前，您会消耗多少条邮件？

由于这可能与时序相关、因为现在两个 DSP 都处于复位状态、您是否尝试延长每次复位之间的时间以查看这是否会产生影响？

[引用用户="RonB"]

MessageQ 使用邮箱、但我们同意每个 MessageQ 应使用不同的集、而不应成为您发现问题的直接原因。 DSP 在您的测试中唤醒时、它们是否能够使用消息？ 在重置邮件之前，您会消耗多少条邮件？

由于这可能与时序相关、因为现在两个 DSP 都处于复位状态、您是否尝试延长每次复位之间的时间以查看这是否会产生影响？

[/报价]

当测试成功运行时、它们会在断电/复位之前消耗3条 MessageQ 消息。 遗憾的是，为延长时间而增加延迟不会产生影响。 在您的终端上使用 MessageQ 示例应用程序时、是否有任何进展？

谢谢！

[引用 user="Rex Chang"]

关闭远程处理器时，邮箱驱动程序不会清除任何待处理的消息。 因此、如果 Tx 队列中有待处理的消息、它们将继续保留在邮箱 IP 中。 我们希望了解您的测试方案。 是否有多个应用、每个应用与两个 DSP 内核还是单个内核通信、使用了多少个 MessageQ？
 [/报价]

每个 DSP 在 ARM 上运行1个应用。 每个应用程序都被分配到单个 DSP 内核、并且只与该内核进行通信。 每个应用程序都有一个主机 MessageQ、并尝试打开它正在与之通信的 DSP 的从器件 MessageQ。  

谢谢、

Gerard

Gerard、

与我之前的帖子一样、邮箱不会清除任何待处理的消息、但当远程处理器出现时、应该会有等待处理的邮箱中断、因此这取决于 DSP 对这些消息的处理方式。

我们进行了内部讨论，可以在释放邮箱信道时添加代码以释放/删除所有未处理的消息，但这只是内核级别的修补程序。 我们仍然没有对过时/未处理的消息进行解释，需要了解 IPC 代码中是否存在任何需要插入的漏洞，或者客户应用程序/基本映像本身是否存在漏洞。

因为我看到您的错误不同、所以我们是否有任何方法让您的 DSP 应用在 EVM 上重现确切的错误、以便我们可以更深入地研究这个问题？ 如果它可以共享、您可以将它发送给 Randy 以将其转发给我吗？

雷克斯

[引用 user="Rex Chang"]

因为我看到您的错误不同、所以我们是否有任何方法让您的 DSP 应用在 EVM 上重现确切的错误、以便我们可以更深入地研究这个问题？ 如果它可以共享、您可以将它发送给 Randy 以将其转发给我吗？

[/报价]

考虑到这是您自己在 EVM 上的演示代码、您会看到错误、周期。 这会导致一个补丁吗？

我将使我们的已剥离 DSP 应用在 EVM 上启动并运行、并尝试重现与邮箱队列相关的异步负载故障。

谢谢