>Number: 149675 >Category: usb >Synopsis: uftdi doesn't react to break properly >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 15 14:40:00 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Paul Thornton >Release: 8.1-RELEASE >Organization: >Environment: 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 >Description: 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 set. >How-To-Repeat: 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: http://www.prt.org/dmxrx2.c >Fix: >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
