[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1086745] Re: serial port data THRE comes too early
From: |
Kees Schoenmakers |
Subject: |
Re: [Qemu-devel] [Bug 1086745] Re: serial port data THRE comes too early |
Date: |
Sun, 09 Dec 2012 18:31:04 -0000 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |