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

[Kees Schoenmakers]

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 <address@hidden> 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