[Qemu-devel] [Bug 1086745] Re: serial port data THRE comes too early

[Koen Hendrix]

>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