On Wed, Sep 14, 2016 at 4:15 PM, Martin Townsend <mtownsend1973@xxxxxxxxx> 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. > > 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. > Looking at the logic analyser this is when the receive tries to echo > something back. Might be completely unrelated but I thought I would > mention it. > > Any help would be greatly appreciated, > Martin. Forgot to mention that the 8250 driver was modified to support the half duplex RS485 transceivers we are using. It basically drives a GPIO when transmitting. My latest thinking is that the serial driver is being called with a single byte to transmit whilst receiving. Not sure how this happens with the simple cat and echo test though. I'll put some logic in the driver to see if this does actually occur and panic if it does to see a back trace. Cheers, Martin. -- 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
