>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 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