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.
工具与软件:
我偶尔在 RPMessage_vringPutEmptyRxBuf ()->IpcNotify_sendMsg ()的无限循环中锁定了2个或3个内核。
显然、如果它们都卡在无限循环中、等待另一个内核清空邮箱、没有内核可以清空邮箱。
从 RPMessage 的整体设计来看,我不知道如何避免这样的死锁。
RPMessage 设计人员能否确认这是一个基本特征? 或许是速度的折衷? 我会重写 RPMessage 如果我需要,但我希望我缺少一些东西。 同时、一个内核锁定另一个内核不是我们可以在系统中实现的功能。
我正在将内核0、2、3、4 (根据 IPC 内核枚举)用于 RPMessage IPC。 由于我一直在开发、我同时出现了0、3、4次死锁。 任何一对内核每2-3天就会死锁几次。 我还没有记录哪一对、但在中、M4F 内核可能比其他门锁更频繁地处于死锁状态。
所有内核都负载过大。 每个内核上的处理循环具有20-500微秒的周期。 我有~30个接收器使用回调。 接收器尊重其中断上下文。 所有发件人都有超时、大多数发件人超时为0、并且有更高级别的队列来处理被拒绝的发送。
除了死锁之外、所有功能都运行得很好。
我们必须在工业通信 SDK 9.0.0.3锁定版本。
然而,我又把修复移植到了阿什温·拉杰的主要开发分支中的 Message_Send 140,因为这一问题也造成了死锁。
您好、旅行者:
您能否提供用于复制问题以加快调试的示例代码?
您能否还要检查死锁何时发生、每个内核当前正在执行的代码片段是什么?
此致、
Tushar
尊敬的 Tushar:
抱歉、代码太大、而且过于依赖于我们的特定硬件。
我的内核锁定的代码位于 vringPutEmptyRxBuf 中:
我的系统在大多数内核上都加载了大量共享内存和大量 IPC (RPMessage 和自旋锁)。 但是、这看起来像是 RPMessage 设计中的一个逻辑错误。 关于 TRM 中涉及的交叉开关没有很多细节、但是 RPMessage 代码似乎假定没有邮箱动态写入、并且在多个事务处理过程中、不同的内核如何访问给定的邮箱之间存在一个很强的顺序。
我已修改 RPMessage 在其他内核上不无限等待(有必要的额外逻辑,以确保可靠的通信)。