On Wed, Sep 14, 2016 at 04:15:11PM +0100, Martin Townsend wrote: > Hi, > > We are seeing a very strange problem here with our embedded AM4378 > (ARM Cortex A9) board. We have 2 UARTS configured as RS485 ports and > very occasionally we are seeing a byte missing from a received message > and it's always the 49th byte. By occasionally it could take around > 8000 or more received messages before we see it. > > I can reproduce the problem by configuring both TTY ports the same > (raw mode) using > stty -F /dev/ttyS3 intr undef quit undef erase undef kill undef eof > undef eol undef eol2 undef swtch undef start undef stop undef susp > undef rprnt undef werase undef lnext undef discard undef \ > parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts \ > -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl > -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 \ > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 > bs0 vt0 ff0 \ > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase > -tostop -echoprt -echoctl -echoke -flusho -extproc 115200 > > and then loopback the 2 UARTs on the board and use cat and echo. > > Here's an example of the missing byte. > .... > 123456789012345678901234567890123456789012345678x0 > 123456789012345678901234567890123456789012345678x0 > 1234567890123456789012345678901234567890123456780 > 123456789012345678901234567890123456789012345678x0 > 123456789012345678901234567890123456789012345678x0 > .... > > By using the following stress-ng command > > stress-ng --cpu-load 50 --io 4 --vm 2 --vm-bytes 128M --fork 4 > > It will happen more often but not straightaway you may have to leave > it for a while and then it starts happening more frequently for a > period and then it's fine again. Increasing the cpu-load didn't seem > to make it happen more frequently but that is just from observation. > > The serial driver is 8250, as it's a TI CPU the driver is the OMAP version. > The Linux kernel is 4.1 LTSI. Does this happen in 4.7? 4.8-rc? 4.1 is really old, loads of things have been fixed since then... > I'm at a loss on how to debug this, I tried putting printk's in the > tty_buffer code to see if the actual message being passed in from the > serial driver contained the full message to try and work out if the > driver was the problem but I didn't get any output in dmesg. > > One thing I also noticed that maybe completely unrelated is that I > accidentally turned on the echo on the receiving end > stty -F /dev/ttyS2 echo > and then transmitted a long string > echo '123456789012345678901234567890123456789012345678x012345678' > /dev/ttyS3 > With this I always get > 123456789012345678901234567890123456789012345678x > The x is the 49th byte. echo and cat are not good things to use for serial ports, they do not handle error handling properly or flow control. So you can't really know much about this. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
