我们正在调查我们的套件的一个问题，这是一个在 Ti-Davinci SoC 上运行 Busybox Linux 的 IP 摄像头。
某个站点有大量网络流量（我们无法控制），其中一个系统255.255.255.255每隔约 50 毫秒不停地向 发送广播数据包。它发送的数据不多，但非常持久。
ifdown ... ifup这对我们的系统产生了奇怪的影响 - 如果在存在此流量的情况下系统启动、重新启动或网络重新启动（等），网络接口将无法正常工作。它声称可以正常工作up，但只是在那里记录数千个 Rx 超限/帧错误。我们无法成功接收任何发送给我们的信息（PING 等），也无法发送任何信息，PING 失败就像丢失了一样（它们显示为已成功传输但实际上从未离开我们），而不是被主动拒绝/丢弃。网络驱动程序似乎认为它已启动并正常工作，但没有任何信息进出。
如果我们移除流量并启动/重新启动/循环网络，接口就会启动并完美运行 - 如果我们重新引入流量，那么我们就不会看到超限/帧错误累积。
作为一个运行 Busybox 的小型嵌入式系统，我们既没有足够的马力，也没有全套的网络工具来处理搜索时发现的一些更重要的建议（增加 Rx 缓冲区是我发现的主要建议）。
相反，我正在寻找有关根本原因的建议和/或有关从哪里开始尝试并防止这种情况发生的建议。它可能就像调整内核参数或重建网络驱动程序一样简单 - 明信片上的答案！
如果需要更多信息，请询问 - 除了 Rx Overflow/Frame 统计信息之外，这不会产生任何错误，ifconfig因此没有什么值得发布的。
答案1
好吧，看起来我找到了答案 - ti-davinci EMAC 驱动程序中有一个错误：
上述提交添加了对载波链接是否正常的检查。如果链接不正常，则释放 skb，并且不会将新的 dma 描述符添加到 rx dma 通道。当载波状态尚未更新时，这会在初始化期间造成麻烦。如果在 netif_carrier_ok 返回 false 时接收到大量数据包，则释放所有 dma 描述符并停止 rx dma 传输。
ifconfig eth0 down && ifconfig eth0 up为了重现该错误，请在开发板上执行操作时对 Davinci 开发板进行洪水 ping 。此后，rx 路径停止工作，并且 ifconfig 报告的溢出值不断增加。
我们已经构建并测试了它，该设备现在可以轻松承受每秒 2500 多个数据包的冲击而不会产生任何不利影响，因此可以肯定它已经得到修复 - 以前只需要大约每秒 50 个数据包就可以破坏它。