我在使用内核模块 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
但不同的负载量可能会使情况变得更糟。仍然看起来有些时间问题：/