>Number:         149675
>Category:       usb
>Synopsis:       uftdi doesn't react to break properly
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-usb
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 15 14:40:00 UTC 2010
>Originator:     Paul Thornton
>Release:        8.1-RELEASE
FreeBSD base01.local 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Sun Aug 15 09:38:55 
UTC 2010     r...@base01.local:/usr/src/sys/i386/compile/TEST2  i386

The same issue is seen with GENERIC kernel
When setting the BRKINT and ~IGNBRK options on a handle where the underlying 
hardware has an FTDI chipset driven by uftdi and ucom, the break condition is 
not correctly acted upon.  The underlying hardware is an FTDI FT232BL chip.

The expected behaviour is that the buffer be flushed on reception of a break 
when BRKINT is used, however the driver appears to behave as if BRKINT is 
clear, as an additional 0x00 byte is seen and the buffer isn't flushed.

FreeBSD 7.2 and 8.0 also exhibit the same behaviour.

Using the same test program, and same USB hardware, Linux behaves as per 
documentation and flushes the buffer on reception of the break when BRKINT is 

Connect two machines using ftdi-driven hardware.

Send a break followed by some data A.  Send another break, followed by some 
data B.

The correct response should be that on the receiver the buffer is flushed by 
both breaks, and a read will only return the data B.

What is likely to be read, however, is: 0x00 [A A A A A] 0x00 [B B B B B]

The code I was using which brought this issue to light can be downloaded from:

freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to