• 状态
  • 已锁定 已锁定
  • 个回复 5 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 81 次查看
  • 用户 0 名在线用户
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM6442：[RPMsg]从 Linux 突发消息导致冻结 R5内核(锁定在 ISR 中)

admin
Guru**** 2013590 points
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1322768/am6442-rpmsg-burst-messages-from-linux-lead-to-freeze-r5-core-locked-in-isr

器件型号：AM6442

您好、TI！

我正在尝试实现内核驱动程序和 R5固件之间的交换以在以太网上发送帧(由 R5内核管理)。 在从内核驱动程序到 R5内核的突发消息之前、该实现正常运行。

我会观察到、R5内核在无限循环中被阻止、管理代码中以下特定行的 IPC 通知：

在几次反表情后,这是我的理解问题:

-为什么可能是原因?

我认为原因是因为 Linux 中的大量消息足以填满所有 vring 缓冲区。 Linux 比 R5获得缓冲区的速度快到足以填充 vring 缓冲区。

由于 VRING 缓冲区太小、无法吸收 Linux 发出的突发脉冲、所以我将丢失数据包=>好的、这是一个限制、但它不会导致在 ISR 中运行的无限循环中锁定 R5固件

-为什么 R5在这个 infirnite 循环堵塞?

这是一个很棘手的部分、但基本而言、我了解这样的代码：

-在 ISR 中:

--获取 邮箱消息( IpcNotify_ISR)

--检查 vring 中是否有内容( RPMessage_notifyCallback->RPMessage_vringIsFullRxBuf )

--处理消息(RPMMessage_recvHandler)

分配新消息-->失败!

--再次检查是否有任何东西在 vring

--分配新消息 -->失败！

--再次检查是否有任何东西在 vring

--分配新消息 -->失败！

由此、我了解在分配 新消息的期间没有可用的缓冲区。 缓冲区的释放是在一个任务中完成的、该任务由于在短时间内接收到过多的消息而从未被调用、并且在 ISR 中进行处理。

-问题:  

您能否确认此类行为？

你有什么建议,以避免这种麻烦?  

=>我看到在其他文章的实现"零倍频"在 R5和用户空间。 但我不确定这是否能解决问题、因为 RPMsg 仍用于管理通知。 (https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/)

此致、

纪尧姆

  • 0
    TI__Guru**** 2013590 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    纪尧姆、您好！

    我要将您的主题传递给另一位能够从 MCU+方面帮助进行更多调试的团队成员。

    调试 IPC RPMSg 行为

    1) 1)您正在使用哪个版本的 MCU+ SDK？

    2)运行 Linux 的 RPMsg 一次只能发送496个字节的数据。 您试图在操作系统之间传输的以太网帧有多大？

    零占空比可能是一个潜在的解决方案吗？  

    通过设置共享存储区、您可以按 RPMSg 通知发送更多的数据。 例如、如果发送1500字节的帧、则可以发送一个 RPMsg 而不是4个 RPMsg 消息。 或者、如果吞吐量对用例的重要性高于延迟、则可以将多个以太网帧聚合到共享存储器区域中、然后只需每10个帧(或类似的数据帧)发送一个 RPMsg。 在这种设计中、乒乓缓冲方案非常容易实现。

    此致、

    尼克

  • 0
    TI__Guru**** 2013590 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Nick、

    对不起,我忘记了我的基本要求:/

    -您正在使用哪个版本的 MCU+ SDK ?

    我使用的是 SDK 8.06。 我查看了最后一个版本(09.01)、但 版本说明未提及 IPC 上的任何修复、并且代码几乎相同。 只添加了 IPCSafe 机制、但我认为使用 IPCSafe 会遇到最糟糕的情况：可在 ISR 中直接管理 IPCSafe 的 CRC、这会进一步减慢 IPC 通知流程。

    -您试图在操作系统之间传输的以太网帧有多大?

    我知道这一限制、并将 MTU 定义为300字节(对于我的应用来说是可以的)。 我不是在寻找性能、低速流量应该通过 IPC、但可靠性更重要。 通常、文件传输可以通过 IPC 进行、但文件传输速度不重要。

    -  零占空比可能是一个潜在的解决方案吗？  

    我观察到的问题是 Linux 发送一组突发的消息。 将帧分离到更多的部分会增加 IPC 突发。

    我记下了您的第二个解决方案、但不同。 我不能在发送通知之前等待 n 帧、因为我不知道堆栈将要发送多少帧。

    相反、当需要第一次传输时、我可以等待1ms、并在1ms 的延迟后通过 IPC 进行通知。 同时、我可以复制共享存储器中的帧。 我需要调整这个1ms 的大小、使其小于以太网控制器的传输缓冲区。

    我不是内核驱动程序专家、内核空间中的共享内存对我来说是一项新功能

    谢谢！

    此致、

    纪尧姆

  • 0
    TI__Guru**** 2013590 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Nick、

    当收到太多 IPC 时，您是否有员工关于 R5死锁的回答？

    此致、

    纪尧姆

  • 0
    TI__Guru**** 2013590 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    纪尧姆、您好！
    您好、Nick、

    这看起来也是我们过去发现的一个问题。 由于没有缓冲区、ISR 持续触发、但是应用程序不能释放任何缓冲区、这是因为它不能优先于 IRQ。

    我们"修复了"、通过为受影响的远程内核禁用 IpcNotify IRQ 并返回允许应用程序处理收到的消息。 稍后、我们会在释放缓冲区后重新启用 IRQ。

    这"对我们有用"、但不确定这是否考虑到了所有可能的代码路径。

    此致、

    多米尼克

  • 0
    TI__Guru**** 2013590 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Dominic：

    感谢您的反馈。 我与您完全吻合。  

    我做了同样的修改,但正如你所说:它是有效的,但不相信它是否是稳健的所有场景:/

    这就是此帖子的目的：确认问题并在下一个版本中请求正确的修复。

    此致、

    纪尧姆