USB g_serial 错误？ - 向一个方向丢失数据

Question

我在使用内核模块 Gadget Serial v2.4 时遇到一些困难。 g_serial 在带有 Arch Linux 4.6.3-1 的 ARM 机器 BeagleBone Black 上使用，与主机 PC 通信。

该问题在这些主机上重现：

• Linux 4.2.0-23、PC x86_64、
• Linux 3.4.43，Cubieboard2 armv7l，
• Windows 10、PC x86_64、

并使用不同的软件：

• 设备（BeagleBone 黑色）：

  • C++ 和 termios，
  • python3-pyserial。

• 主机（PC 或 Cubieboard2）：

  • C# + .NET，
  • python3-pyserial。

Python测试：https://github.com/tomasxvavra/serial_test。

问题是数据在设备 -> 主机方向上丢失。例如，如果设备向 ttyGS0 发送 100 MB 数据，则主机仅从 ttyACM0 接收 99.7% 的数据。这绝不发生在主机 -> 设备方向。

丢失的数据量根据以下条件而有所不同：

• 写入串口的数据“包”大小： *如果通过 s.write(data) 一次将 100 MB 写入端口，则失败的可能性要小得多。以不同的数据包大小写入端口会导致不同的错误率。例如：
  • 较小的数据包 <= 512 B - 大部分都可以，有时会失败，丢失大约 10-512 B。
  • 更大的数据包 4096 - 32768 B：失败更频繁，并且丢失大量数据。
• 主机设备的速度- 速度较慢的 Cubieboard2 上的故障率比 PC 上的故障率高得多，尤其是数据包较大时。

有时，仅发送 1024 B 或类似大小的数字时会失败，通常会丢失 512 B。我还尝试用wireshark分析USB数据包，确实有数据包丢失。但除此之外我无法将其解释为异常。

因此，从我的内核角度来看，这对我来说似乎是一些计时问题。 g_serial 有类似的经历吗？谢谢。

编辑

我发现当主机是Cubieboard2（2个CPU）时，如果我加载一个CPU，故障率会迅速下降

cat /dev/zero > /dev/null

但不同的负载量可能会使情况变得更糟。仍然看起来有些时间问题：/