• 状态 Resolved
  • 已锁定 已锁定
  • 回复 10 回复
  • 订户 0 订户
  • 视图 403 视图
  • 用户 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.

[参考译文] RTOS/TM4C129ENCPDT：多次重启 DHCP 客户端失败

admin
Guru**** 2601915 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/741003/rtos-tm4c129encpdt-restart-dhcp-client-fails-after-several-times

器件型号：TM4C129ENCPDT

工具/软件：TI-RTOS

您好！

 

我们有一个使用 M4和 TI-RTOS for TivaC 2.14.4.31的系统、在该系统中、我们通过单独的线程来实现了重新启动 DHCP 客户端、该线程监控以太网链路的状态、并在插入网络电缆后重新添加 DHCP 客户端。

由于我们还允许系统具有静态 IP 地址、因此在连接电缆时、我们会删除静态 IP 地址的配置条目(CFGTAG _IPNet、CFGTAG _route、CFGTAG _SYSINFO/CFGITEM_DHCP_DHCADOMAINNAMESERVER)和 DHCP 客户端的配置条目(CFGTAG _SERVICE_CFGITEM_DHCP_DHCP_DHCPLINESERVER)。 之后，我们添加静态 IP 地址的配置条目或 DHCP 客户端的配置条目。

这一切都像一种魅力，但……

当我们反复拔下并插入以太网电缆时，有时会出现错误计时或尝试次数不确定的情况，DHCP 客户端由于在 dhcpSocketOpen()中没有插槽而失败。 在深入调查之后，这是由 PBM_Alloc()返回 NULL 引起的，也是由于 PBMQ_DEQ()在数据包池中没有遇到任何剩余的内容。

这是 NDK 版本中的错误、还是我们可能会做错误的事情？

 

AJ

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

    几件事情
    一、看一下： processors.wiki.ti.com/.../TI-RTOS_Networking_Stack_Memory_Usage 。 您可以尝试增加 PBM 缓冲器。 当然、如果泄漏(我没有泄漏)、这将不起作用。

    2.查看以下内容： processors.wiki.ti.com/.../TI-RTOS_Support 。 TM4C EMAC 驱动程序存在一些已知问题。

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

    您好 Todd、

    在其他任务之间、我们正在尝试隔离该问题。

    我可以100%肯定地说、当使用 TI-RTOS 2.14.4.31时、DHCP 客户端服务在任务本身 处于阻塞重新调用中时被删除、由于套接字的锁定计数不为0、因此无法释放套接字。 未释放的内存为 fdOpenSession 的20字节、SockNew 的240字节和 SBNew 的20字节。

    为了尝试创建一个新项目来解决这个问题、我们考虑从网络示例 TcpEcho 开始、但该示例要求我们使用 TI-RTOS 2.16.4.31。

    当然、我们在那里看到所有内存都已正确及时释放、因此现在我们将产品"升级"到2.16.4.31 (并再次构建 NDK)、看看这是否能解决问题、我想、希望大家都能

    我无法在发行说明中快速看到任何此类问题的引用、您是否知道这是问题、或者是否可以通过正常更新意外修复此类问题？

    无论如何、感谢您关注此问题。

    我将跟进我们的"升级"结果。

    AJ

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

    "升级"没有太大影响。
    因此，我们尝试了删除和添加 DHCP 客户端的任务的不同优先级。 这似乎起了作用，但我们不理解为什么。
    在另一个线程中使用 CfgGetEntry、CfgAddEntry、CfgRemoveEntry 等时、我们是否必须遵循一些指导原则、如优先级？

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

    我们修复了2.26版本 NDK 中某些清理代码中的内存泄漏。 如果您附加有问题的小示例工程(以及有关如何重现问题的说明)、则可能会更容易、以便我们可以对其进行一些处理、以确定这是问题还是另一个问题。

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

    您好 Todd、

    我的同事 Steve 根据 tcpEcho 示例制作了一个示例项目。

    在函数 netwOpenHook()中，它创建了一个任务，然后基本上只循环添加和删除 DHCP。  如果您创建的此任务的优先级小于5、则没有问题、但如果优先级为6或更高、则会发生问题。

    不确定是否可以通过显式下载访问 NDK 2.26、而不是 TI-RTOS 软件包的一部分。

    如果您可以解释为什么在示例项目中更改优先级会使其产生或中断、我们一定会听到这个消息。

    感谢您对此进行深入研究。

    AJ

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

    e2e.ti.com/.../6567.tcpEcho_5F00_EK_5F00_TM4C129EXL_5F00_TI_5F00_TivaTM4C129ENCPDT.zipHiTodd、

    下面是我之前的帖子中应该附加的示例项目。

    AJ

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

    你好、AJ、

    感谢您的项目。 我重现了这个问题。 我相信这是一个与原来的帖子不同的问题。 DHCP 和 NDK 引导任务都处于优先级5。 当堆栈获得 IP 地址时、NDK 引导任务会调用 netOpenHook 函数。 它以优先级6调度任务、因此 tcpHandler 开始运行并调用 remove_dhcp_client。 这似乎不是一个有效的用例、因为您没有让引导任务完成。 但是、我找不到任何警告用户的内容。 这是一个相当不寻常的用例、因此我们没有考虑它、我并不感到意外。 如果您降低 tcpHandler 的优先级或取消注释、则问题会消失。  我将为此打开一个 JIRA、但我认为我们不应该继续沿着这条路解决您的初始问题。

    您能否启用 HeapTrack 来查看我们是否发现您的原始设置存在任何内存泄漏？ 下面是一个视频/演示文稿： 。 希望这可以让我们对这个问题有所了解。

    关于 您原始设置的已知内存 leak...in，您能否在 SockCleanPcb()中设置断点以查看是否已命中？  我们只 关闭了第一个，没有关闭列表的其余部分...啊！ 我已附加了包含修复程序的2.26文件。

    e2e.ti.com/.../7416.sockpcb.c

    Todd

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

    您好 Todd、

    难道不是这样，Task_create()只创建任务，然后在某个方便的时候，任务调度程序将启动任务？ 尤其是当创建的 tcpHandler 任务的优先级仅为1时。

    因此，我认为 netOpenHook()将及时返回，并为引导任务提供完成的机会。

    我的理论是，在较高优先级的设置下，删除 DHCP 客户服务的任务会在不方便的时刻取代仍在运行的 DHCP 客户服务，并从其下面抽取 rug。

    在 DHCP 重新启动任务的优先级较高的原始设置中(15)、我在所用套接字的 lockCount 上放置了一个观察点、 在 DHCP 客户端任务的 recv 调用中、它始终成对锁定和解锁、在这种情况下解锁不会发生、因此清理中的套接字不会被破坏。

    不过、我仍然想知道、如果 DHCP 客户端正在进行阻塞式 recv 调用、或者它可能会这样做、那么优先级较低的 DHCP 重新启动程序任务是否以及为什么不能切换到、 但是、由于删除任务的优先级较低、将被删除的任务将有机会正确清理(例如检测套接字锁定时清除发出的信标信号)。

    但是、目前我们的直接问题似乎已经解决、因为系统可以在95K DHCP 重新启动后继续运行、而内存使用不会增加。

    我们的解决方案似乎是：

    运行优先级低于 NDK 引导任务和 DHCP 客户端服务任务的单独线程。

    在该线程中、监视网络电缆连接(EMAC_isLinkUp (0))、并使用 CfgGetEntry、CfgRemoveEntry 和 CfgAddEntry 删除和添加 DHCP 客户端以有效地重新启动 DHCP 客户端。

    感谢所有的帮助。

    AJ

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

    你好、AJ、

    [引用 user="aart Janse van den Boscha]]Task_create()只是创建任务，然后在某个方便的位置，任务调度程序将启动任务吗？ 尤其是在创建的 tcpHandler 任务的优先级仅为1时。

    否 正在优先级为5的任务的上下文中调用您的函数。 当您在函数中创建优先级6任务时、该新任务将立即优先于优先级5任务。  

    让单独线程的优先级低于 NDK Boot 和 DHCP 客户端任务的解决方案似乎是最佳解决方案。

    Todd