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

[Kees Schoenmakers]

Hello,

I have attached 2 scope shots, SCR0002.BMP shows a failing
communication cycle, the upper trace is the RTS signal on the port,
the lower trace shows the databytes wriiten.
SCR00004.BMP show how it had to be, RTS is active during the whole databytes.

In general an application will issue ioctl(<fdn>,TOICSERGETLSR,
&<bits>) and continue as soon as the 'bits' are set. Thus for this to
work the ioctl call should _only_ return 'bits' set if the _real
hardware_ has written the bytes.

Kees


On 12/5/12, Lei Li <address@hidden> wrote:
> Could you please give more details, like the steps to reproduce this
> problems.
>
> Thanks.
>
> --
> 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
>


** Attachment added: "SCR00002.BMP"
   
https://bugs.launchpad.net/bugs/1086745/+attachment/3452879/+files/SCR00002.BMP

** Attachment added: "SCR00004.BMP"
   
https://bugs.launchpad.net/bugs/1086745/+attachment/3452880/+files/SCR00004.BMP

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