graphic: 0.957 other: 0.943 assembly: 0.938 device: 0.935 instruction: 0.934 boot: 0.930 network: 0.929 mistranslation: 0.915 socket: 0.912 semantic: 0.909 vnc: 0.897 KVM: 0.894 serial port data THRE comes too early When using a serial port with a Linux guest (and host) and the application uses hardware handshake, this fails because the handling of TEMT and/or THRE is not operating properly in such cases. As long as it takes _time_ for the 'real' port to output the data TEMT may not return true. After writing characters to a real port, the driver should timeout the transmission and after the total time expired, TEMT can be set. Some applications i.e. with a simplex modem do: RTS_on, WRITE_data, repeat IOCTL(GET_LSR_INFO), RTS_off, READ_data. At the moment this fails because very early in the transmission, GET_LSR_INFO returns true and the modem transmitter is switched off. I looked in the source (git) and found that 'char_transmit_time' is present. My skills fail to implement it myself. I build and ran the latest git version and found it to fail as decribed above. I hope someone can solve it. Could you please give more details, like the steps to reproduce this problems. Thanks. Hello, It is a Linux host and a Linux guest. One serial port (/dev/ttyS0) is passed from the host to the guest. The application (on the guest) does Hart (r) communication, This is done with a 1200 baud simplex modem (one side at a time). The application raises RTS so that the modem goes in transmit state, it writes a couple of bytes. Only after _all_ bytes are written in reality the RTS is to be de-activated which puts the modem in receive state. Normally a loop like int parm =0; while (!parm) ioctl(devicefd,TIOCSERGETLSR , &parm); is executed, The loop exits when parm is not zero (TEMT is set); The current implementation of TIOCSERGETLSR only checks fifo count which is nowhere a accurate way of checking if the device in the host has written all its characters, thus the function ioctl(devicefd,TIOCSERGETLSR , &parm) returns parms set already when the second character is transmitted and thus the whole communication cycle is disrupted. One possible solution is having ioctl(.... TIOCSERGETLSR ...) in the guest to check the result of ioctl(..... TIOCSERGETLSR....) in the host. Another way is timing of the transmission, that is for each character written the guest needs to add the charactertime to a timer and only when the timer timesout TEMT is to be set. does this help to understand the problem? best regards Kees Hello, I have attached 2 scope shots, SCR0002.BMP shows a failing communication cycle, the upper trace is the RTS signal on the port, the lower trace shows the databytes wriiten. SCR00004.BMP show how it had to be, RTS is active during the whole databytes. In general an application will issue ioctl(,TOICSERGETLSR, &) and continue as soon as the 'bits' are set. Thus for this to work the ioctl call should _only_ return 'bits' set if the _real hardware_ has written the bytes. Kees On 12/5/12, Lei Li