erro g_serial USB? - perdendo dados em uma direção

Question

Estou tendo algumas dificuldades com o módulo do kernel Gadget Serial v2.4. O g_serial é usado na máquina ARM BeagleBone Black com o Arch Linux 4.6.3-1 que está se comunicando com o PC host.

O problema foi reproduzido nesses hosts:

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

e com software diferente:

• Dispositivo (BeagleBone Black):

  • C ++ e termios,
  • python3-pyserial.

• Host (PC ou Cubieboard2):

  • C # + .NET,
  • python3-pyserial.

Teste do Python: link .

A questão é que os dados são perdidos no dispositivo de direção - > hospedeiro. Por exemplo, se o dispositivo enviar para ttyGS0 100 MB de dados, o host receberá de ttyACM0 apenas 99,7% dos dados. Este nunca acontece na direção do host - > dispositivo.

A quantidade de dados perdidos varia com base nessas condições:

• Tamanho dos dados "pacotes" gravados na porta serial: * Se 100 MB forem gravados na porta de uma vez por meio de s.write (dados), é muito menos provável que falhe. A gravação na porta em vários tamanhos de pacote resulta em várias taxas de erro. Por exemplo:
  • Pacotes menores < = 512 B - principalmente ok, às vezes falha com cerca de 10-512 B mising.
  • Pacotes maiores 4096 - 32768 B: Falham com mais frequência e quantidades maiores de dados estão faltando.
• Velocidade do dispositivo host - A taxa de falha foi muito maior no Cubieboard2 mais lento do que no PC, especialmente com pacotes maiores.

Em algum momento falha ao enviar apenas 1024 B, ou um número de tamanho similar, geralmente 512 B é perdido. Eu também tentei analisar pacotes USB com wireshark e realmente faltavam pacotes. Mas nada mais eu poderia interpretar como uma anomalia.

Então, do ponto de vista do meu kernel, parece um problema de tempo para mim. Alguma experiência semelhante com g_serial? Obrigado.

Editar

Descobri que quando o host é Cubieboard2 (2 CPUs), a taxa de falha cai rapidamente se eu carregar uma cpu com

cat /dev/zero > /dev/null

Mas quantidades diferentes de carga podem piorar ainda mais. Ainda está procurando algum problema de tempo: /