On Wed, Aug 07, 2019 at 02:41:47PM -0400, Robert Middleton wrote: > On Wed, Aug 7, 2019 at 11:04 AM Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > > On Wed, Aug 07, 2019 at 09:48:03AM -0400, Robert Middleton wrote: > > > > I'll try to get some firm results in the morning; otherwise I won't be > > > > able to check until early next week as I will be away from the > > > > hardware. > > > > > > After doing more testing, I think that I finally have something that > > > is working fully at all baud rates. I've tested this at > > > 115200,9600,and 4800, testing via: echo "the quick brown fox jumps > > > over the lazy dog" > /dev/ttySx > > > > > > Removing the check to uart_circ_empty in the while loop makes it more > > > reliable, however it will occasionally fail and only transmit the > > > first part of the message(at 4800, it will transmit only "t", at > > > 115200 it will transmit "the quick bro"). > > > > I'm not sure about the loop for uart_circ_empty(). Can you try 2-3 kB of text > > at lower baud rate, let's say 2400 or so? > > So at the lower baud rate, it does not transmit all of the data, > probably because the timeout eventually stops it. However, it does > get back into a very weird state that I have seen before, where > opening up the port again will cause it to transmit some of the > previously-buffered data. See below for some more details. > > > > I've found that breaking it > > > into two loops, one checking the uart_circ_empty and the other doing > > > the LSR check is reliable at all baud rates. > > > > If my suspicion is correct, the shutdown of the port will take ages which is > > inappropriate. > > The shutdown probably does take a while, but the fact that not all of > the data is transmitted is what tripped me up in the first place and > sent me down this track trying to figure out why all of the data was > not being transmitted out of the serial port properly. > > The previous hardware used an FTDI USB to serial converter to send > serial data, and changing to the exar caused some of our applications > to stop working. They do a similar thing to echoing from the terminal, > that is they come up, send a command, and then exit. I tried just now > with an FTDI cable and got some interesting results vs. using the > exar. The data(3kB) gets fully transmitted when I do 'cat > lorem-ipsum.txt > /dev/ttyUSB0', but when I do it via 'cat > lorem-ipsum.txt > /dev/exar-serial' it will timeout after a second. > Doing an 'echo "" > /dev/exar-serial' will send more of the text, > until it stops again. I have to do this about 5 times before all of > the data gets transmitted over the serial port. This is also at 2400 > baud on both the exar and the FTDI. 8250 driver has device nodes like /dev/ttySxxx. Just to be sure are you really using kernel's native driver? > At this point, this leads me to believe that there is actually a more > fundamental problem with the 8250 driver and flushing data. I was > focusing more on the exar, since that is the only hardware that I have > available that uses the 8250 driver. Hmm... It's weird that no-one else had noticed so far an issue. In any case I would recommend to include Exar driver related people in case of specific behaviour of the hardware you are testing on. I'm Cc'ing them now. Sorry guys, I forgot to do this earlier, nevertheless I left the text of Robert's last mail untouched. -- With Best Regards, Andy Shevchenko
