Red Hat Bugzilla – Bug 171787
USB serial port modules ftdi_sio / mct_u232 / usbserial not working in the same way as a standard /dev/ttyS0 does
Last modified: 2007-11-30 17:07:21 EST
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): kernel-smp-2.6.9-5.0.5.EL How reproducible: Always 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:
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 pipes. Otherwise it's not possible to determine which data arrives first.