我们正在使用我们的套件研究一个问题，该套件是在Ti-Davinci SoC上运行Busybox Linux的IP摄像机。
在一个特定的网站上，有很多networkingstream量（我们无法控制），一个系统每隔大约50ms不间断地发送广播数据包（到255.255.255.255 ）。 这不是发送太多的数据，而是非常持久。
这对我们的系统有一个奇怪的影响 – 如果系统启动，重新启动，或者networking重新启动（ ifdown ... ifup等），而此stream量存在，networking接口将无法正常工作。 它声称是up但只是坐在那里logging成千上万的Rx超限/帧错误。 我们没有成功地收到任何东西（PING等）给我们，也不能发送任何东西，PING失败，就像他们已经失踪（他们显示成功传输，但从来没有真正离开我们），而不是被主动拒绝/下降。 networking驱动程序似乎相信它的工作正常，但没有进入或退出。
如果我们删除stream量并启动/重新启动/重新启动networking，界面就会出现并且运行良好 – 如果我们重新引入stream量，我们就不会看到溢出/帧错误消失。
作为一个运行Busybox的小型embedded式系统，我们既没有在search时发现的一些重要build议（增加Rx缓冲区是我find的主要缓冲区）的function，也没有提供全部的networking工具。
相反，我正在寻找根本原因的build议和/或build议从哪里开始尝试和防止这种情况发生。 这可能像调整内核参数或重buildnetworking驱动程序一样简单 – 在明信片上回答！
如果需要更多信息，请询问 – 除了ifconfig的Rx Overflow / Frame统计信息，这不会产生任何错误，所以没有什么值得发布的。
那么它看起来像我find了答案 – 在ti-davinci EMAC司机有一个错误：
Davinci-Linux邮件列表笔记：
所述提交添加检查运营商链接是否正常。 如果链接不正确，skb将被释放，并且没有新的dma描述符被添加到rx dma通道。 当载波状态尚未更新时，这在初始化期间造成麻烦。 如果在netif_carrier_ok返回false时接收到大量数据包，则释放所有的dma描述符，并停止rx dma传输。
为了重现这个错误，在执行
ifconfig eth0 down && ifconfig eth0 up同时，将ping davinci板填满。之后，rxpath停止工作，ifconfig报告的溢出值正在计数。
我们已经build立并testing了这个设备，现在该设备可以快速地承受2500+包/秒的冲击，没有任何负面影响，因此可以肯定它是固定的 – 以前只需要约50包/秒来破坏它。