Hello Friend, 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.
I am referring to how the _hardware handshake_ signals from the guest environment are passed to the host. best regards Kees On 12/9/12, Koen Hendrix <koen.hend...@pandora.be> wrote: > could this be related? https://bugs.launchpad.net/ubuntu/+bug/1087519 > > -- > 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