Hello,
I am having some difficulties with kernel module Gadget Serial v2.4.
g_serial is used on ARM machine BeagleBone Black with Arch Linux 4.6.3-1
which is communicating with host PC. I originally reported it here:
bugzilla.kernel.org/show_bug.cgi?id=121441
The problem was reproduced on these hosts:
* Linux 4.2.0-23, PC x86_64,
* Linux 3.4.43, Cubieboard2 armv7l,
* Windows 10, PC x86_64,
and with different software:
* Device (BeagleBone Black):
* C++ and termios,
* python3-pyserial.
* Host (PC or Cubieboard2):
* C# + .NET,
* python3-pyserial.
Python test: https://github.com/tomasxvavra/serial_test.
The issue is that data is lost in direction device -> host. For example
if device sends to ttyGS0 100 MB of data, then the host receives from
ttyACM0 only 99.7 % of the data. This never happens in direction host ->
device.
Amount of data which is lost is significantly varying based on these
conditions:
* Size of data "packets" written to serial port:
* If 100 MB is written to port at once through s.write(data)
than it is much less likely to fail. Writing to port at various
packet sizes results in various error rates. For example,
* smaller packets <=512 B - mostly ok, sometimes fails with
around 10-512 B missing.
* Bigger packets 4096 - 32768 B: Fails more often and larger
amounts of data is missing.
* Speed of the host device - Fail rate was much higher on slower
Cubieboard2 than on PC, especially with bigger packets.
* CPU load - if found out, that if the host (Cubieboard 2, - 2 CPUs) has
1 CPU loaded with cat /dev/zero > /dev/null, then the failure rate
rapidly drops.
Sometime it fails when sending only 1024 B, or similar sized number,
usually 512 B is lost. I also tried to analyze USB packets with
Wireshark and there really was missing packets. But nothing else I could
interpret as a anomaly. Just maybe one thing bothers me, why is usbmon
capturing bulk endpoint packets which are bigger than 512 B? For example
I can mostly see bulk packets with size of 1024. I can attach an usbmon
output when it fails, but it will be much larger.
So from my kernel noob point of view, it looks like some timing issue to me.
Thank you, Tomas Vavra
### No error
### Started receiver.py - opens port and tries to read data
eeb3ed00 794415592 S Ii:2:002:2 -115:256 10 <
ee66d400 794415659 S Co:2:002:0 s 21 22 0003 0000 0000 0
ee66d400 794415836 C Co:2:002:0 0 0
eeb3ea80 794415980 S Bi:2:002:1 -115 1024 <
eeb3e100 794416054 S Bi:2:002:1 -115 1024 <
eeb3e080 794416133 S Bi:2:002:1 -115 1024 <
eeb3eb00 794416190 S Bi:2:002:1 -115 1024 <
eeb3e880 794416244 S Bi:2:002:1 -115 1024 <
eeb3e380 794416298 S Bi:2:002:1 -115 1024 <
eeb3e580 794416365 S Bi:2:002:1 -115 1024 <
eeb3e800 794416420 S Bi:2:002:1 -115 1024 <
eeb3ee00 794416475 S Bi:2:002:1 -115 1024 <
eeb3e600 794416525 S Bi:2:002:1 -115 1024 <
eeb3ec80 794416602 S Bi:2:002:1 -115 1024 <
eeb3e180 794416655 S Bi:2:002:1 -115 1024 <
eeb3ed80 794416708 S Bi:2:002:1 -115 1024 <
eeb3e480 794416760 S Bi:2:002:1 -115 1024 <
eeb3e680 794416813 S Bi:2:002:1 -115 1024 <
eeb3eb80 794416864 S Bi:2:002:1 -115 1024 <
### Started sender.py - sends 512 B at once
eeb3ed00 799439104 C Ii:2:002:2 0:256 10 = a1200000 00000200 0300
eeb3ed00 799439136 S Ii:2:002:2 -115:256 10 <
eeb3ea80 799924821 C Bi:2:002:1 0 187 = 16cc84c6 7a9d8c65 acf31121 e83f9b0a ca47b7fa b4d282b5 0abef9eb 4b9b718f
eeb3ea80 799924869 S Bi:2:002:1 -115 1024 <
eeb3e100 799925944 C Bi:2:002:1 0 255 = 2811bb95 896be660 6b828617 f10d583c f8c078a5 bae7bdba 061617e4 318dd4c4
eeb3e100 799925963 S Bi:2:002:1 -115 1024 <
eeb3e080 799925981 C Bi:2:002:1 0 70 = 7c9a7d31 951b2421 42144e3a b0b9682b 0d6bf37c 7aea3d4c 9201d786 c4bb16f1
eeb3e080 799925991 S Bi:2:002:1 -115 1024 <
eeb3ed00 799951116 C Ii:2:002:2 0:256 10 = a1200000 00000200 0000
eeb3ed00 799951147 S Ii:2:002:2 -115:256 10 <
