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(<fdn>,TOICSERGETLSR, &<bits>) 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 <matrixs.z...@gmail.com> wrote: > Could you please give more details, like the steps to reproduce this > problems. > > Thanks. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1086745 > > Title: > serial port data THRE comes too early > > Status in QEMU: > New > > Bug description: > 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. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1086745/+subscriptions > ** Attachment added: "SCR00002.BMP" https://bugs.launchpad.net/bugs/1086745/+attachment/3452879/+files/SCR00002.BMP ** Attachment added: "SCR00004.BMP" https://bugs.launchpad.net/bugs/1086745/+attachment/3452880/+files/SCR00004.BMP -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1086745 Title: serial port data THRE comes too early Status in QEMU: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1086745/+subscriptions
