Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 171787 - USB serial port modules ftdi_sio / mct_u232 / usbserial not working in the same way as a standard /dev/ttyS0 does
USB serial port modules ftdi_sio / mct_u232 / usbserial not working in the sa...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-10-26 10:21 EDT by Tony McConnell
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-31 11:02:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tony McConnell 2005-10-26 10:21:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Description of problem:
Situation is this:

1. Main program creates two pipes: p1, and p2, using "pipe()"

2. Thread one opens a tty using h1=open("/dev/ttyS0", O_RDWR, O_NDELAY)
3. Thread one uses "select()" on the read side of p1 + serial port handle h1
4. Thread one leaves the select call when data arrives on either p1 or h1.
5. If data arrived from h1, use write to the write side of pipe p2.

6. Thread two opens a tty using h2=open("/dev/ttyS0", O_RDWR, O_NDELAY)
7. Thread two uses "select()" on the read side of p2 + serial port handle h2
8. Thread two leaves the select call when data arrives on either p2 or h2.
9. If data arrived from h2, use write to the write side of pipe p1.

This should cause both threads one + two to receive identical information regardless of which thread happens to read the information first. 

It does in fact work correctly.

Substitute "/dev/ttyUSB0" for "/dev/ttyS0" and it no longer works in the same way, the threads do not receive the same data.

So there could be a problem with the ftdi_sio USB serial module.

Oh, and the result is the same when using the mct_u232 module too.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
See description

Actual Results:  Funny behaviour from the USB serial ports

Expected Results:  USB serial port should work consistent with the way a tty works.

Additional info:
Comment 1 Tony McConnell 2005-10-31 11:02:38 EST
I'm closing this as it's not a bug. 

It is in fact a problem with my code which now works in a more sensible fashion
- only one thread reads the serial port handle, the rest sit on the read side of

Otherwise it's not possible to determine which data arrives first.

Note You need to log in before you can comment on or make changes to this bug.