[Bug 222665] Cannot send anything if characters received ahead of first use of ftdi chip

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222665

            Bug ID: 222665
           Summary: Cannot send anything if characters received ahead of
                    first use of ftdi chip
           Product: Base System
           Version: 10.3-RELEASE
          Hardware: i386
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: usb
          Assignee: freebsd-usb at FreeBSD.org
          Reporter: nkoch at demig.de

In an embedded system we use an ftdi chip FT4232HL for serial communication.
Channels 1 and 2 are unused, channel 3 is RS485, channel 4 is RS232.

The system is a kind of terminal which responds to messages
coming in via serial communication.

We previously used FreeBSD 8.2 without any problems.
With FreeBSD 10.3 we found the following situation:

1. Turn on power.
2. Wait until BIOS finishes and boot loader starts.
3. Immediately begin transmitting messages via RS485 to this device.
4. Application starts and opens /dev/cuaU2.
5. Application sees message and posts answer, but answer is not being sent.
6. Close application and outstanding characters are being sent.
7. Reopen application and all works fine.

This problem seems to only occur with RS485 at cuaU2,
*not* with RS232 at cuaU3.

If nothing is being sent before step 4 all seems ok.

With hw.usb.ucom.debug=1 I can see that ucom_outwakeup()
seems never being called in error case. The first ucom_outwakeup()
I then see comes from close().

Having put additional debug messages in ucom_get_data() and
ucom_put_data() I can see that my application tries to send
the expected response.

ioctl(UFTDIIOC_RESET_IO) after open() seems to solve that problem for me.
But I am unsure if this is a fix of a chip problem or a workaround
for a kernel/driver/locking problem (which could also come from
the upper tty layer).

-- 
You are receiving this mail because:
You are the assignee for the bug.