工具/软件：Linux
我使用 Sitara AM3354作为 USB 器件、该器件通过 Linux USB CDC-EEM (以太网-over-USB)器件堆栈连接到 x86主机。 从 x86主机对 Sitara USB 设备端点执行 nmap 端口扫描时、Sitara 将经常报告"RT 节流已激活"、有时会重置看门狗。
我推测、nmap 端口扫描生成的 USB 中断量会阻止在 Sitara 上运行的守护程序定期更新其"脚踢"文件、并且看门狗守护程序会检测到此情况并重置 Sitara。 以下是一个示例、其中传感器监控守护程序(sensord)无法"触摸"其 sensord.kick 文件5秒钟、而看门狗守护程序让硬件看门狗过期以重置系统。
DEC 5 18：20：41：Jan 1 00：00：54 127.4.2.2错误安全装置[1247]：文件/var/run/sensord.kick 在5秒内未更改。
12月5日18：20：41：Jan 1 00：00：55 127.4.2.2警告内核：[59.967841][sched_Delayed] sched：RT 节流已激活
DEC 5 18：20：41：JAN 1 00：00：55 127.4.2.2错误安全装置[1247]：修复二进制文件/usr/sbin/capture_logs_before_shutdown.sh 返回255
DEC 5 18：20：41：JAN 1 00：00：55 127.4.2.2警报安全装置[1247]：由于错误255关闭系统
DEC 5 18：20：51：JAN 1 00：01：05 127.4.2.2注意看门狗[1247]：硬件看门狗已启用、让其过期。
DEC 5 18：20：51：JAN 1 00：01：05 127.4.2.2警报安全装置[1247]：安全装置设置为1秒
此问题似乎取决于 nmap 执行的端口扫描的速率。 将 nmap 扫描速率限制为10000个数据包/秒可以避免这一问题-但我想在 Sitara 端找到一个解决方案。 如果 x86可能导致 Sitara 重置看门狗、则这是我们系统中的一个潜在拒绝服务漏洞。
我在执行 nmap 端口扫描时运行了一个检查中断计数器的测试。
while [1]；do echo "---"; date；cat /proc/interrupts；echo； 完成
在6秒内、DMA 和 USB0中断显著增加。 所有其他中断的增加量都很小。
这几乎是11、000次中断/秒、或每92 us 中断1次。
我在内核中启用了跟踪功能、以尝试确定处理 USB 中断所花费的时间。
Sitara# echo OMAP3_intc_handle_IRQ > set_ftrace_filter
Sitara#回波 nop > Current_tracer
Sitara# echo 1 > function_profile_enabled
Sitara# echo 0 > function_profile_enabled
sitara# cat trace_stat/function0
函数命中时间平均 s^2
---- ------------
OMAP3_intc_handle_IRQ 115547 9388735 us 81.254us 3963830 us
我知道我每92us 就会收到一个中断(没有内核跟踪)、平均需要81us 来处理该中断。 这样就没有太多时间去做任何有用的事情了！
这些数字是否看起来合理-每92us 中断一次、每81us 中断一次 USB 中断服务？
可以对 Sitara 执行哪些操作来降低所有这些 USB 中断的影响？
是否有办法限制 USB 接口的带宽以降低中断频率？
感谢您的任何帮助、
Gregg。
