Hello, The scope traces that I sent are from 2 sources yes, the one with the 'short' RTS time is taken when the port was driven by the (Linux) guest .
The trace with the correct RTS length was taken when the port was driven by the (Linux) host. Both times the same application. I looked in the sources for QEMU and I am believing that the functionality of the ioctl(..., TIOCSERGETLSR ...) is not returning the correct status of the guest+host port. I will look to the report again anyway. best regards Kees On 12/9/12, Koen Hendrix <koen.hend...@pandora.be> wrote: >>I don't think so. He is referring to a normal modem with an AT command >>set not responding >>to incoming call, which is probably a setup issue. > no. please read further on; i described another oddity in the same > bugreport. > >>I am referring to how the _hardware handshake_ signals from the guest >>environment are passed to the host. > you used a hardware scope. so you used real serial ports: one controlled by > the host, one by qemu. what is the difference? in either instance, there is > at least one native linux kernel involved in the handshake. > > disregard this if i'm talking nonsense. > > -- > 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 > -- 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
