I've been writing serial port regression test programs to test the
serial drivers I maintain. I occasionally run them on "standard"
16x50 serial ports for comparison purposes. My flow control
regression test passes with my driver and fails with 16x50 serial
ports (some are Moschip parallel-serial port boards, some are Oxford
multi-port serial boards). At the moment, I don't have any
motherboards with serial ports that I can test on. I've tested under
3.5 and 3.8 kernels so far.
Here's the test scenario:
1) Port is in "raw" mode with rtscts flow control enabled.
2) Send receive data to port until RTS goes off (receive ~3968
bytes).
3) Make read() calls on port until RTS comes back on (read ~3840
bytes).
4) Send receive data to port until RTS goes off again (receive ~3968
bytes).
so far, everything's working fine...
5) Call tcflush(TCIFLUSH).
RTS should go back on at this point, since the receive buffer is
now empty and there's plenty of room to receive more data.
RTS does not come back on: it stays off (forever, AFAICT).
If you read() the port in non-blocking mode it returns EAGAIN. A
read() in blocking mode will block. The receive buffer is empty and
incoming data is throttled off, so a blocking read() never returns.
This seems like a bug to me.
Calling tcflow(TCION) once it's in this state does nothing. [I guess
it's not supposed to since it's only intended to be used in XON/XOFF
mode.]
With my driver, calling tcflush(TCIFLUSH) causes RTS to come back on
again and incoming data resumes. Why isn't this the right thing to
do?
--
Grant Edwards grant.b.edwards Yow! PUNK ROCK!! DISCO
at DUCK!! BIRTH CONTROL!!
gmail.com
--
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
