Bug 170490 - usb serial module mct_u232 loses characters
usb serial module mct_u232 loses characters
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-10-12 06:12 EDT by Tony McConnell
Modified: 2012-06-20 09:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 09:24:16 EDT
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-12 06:12:13 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:
When I plug-in a Magic Control Technology device ID 0711:0230 it appears as
/dev/ttyUSB0 as expected, loading the mct_u232 and usbserial modules.

I have a program that reads information from the serial port, at 9600bps, no parity, no flow control.

When I first execute the program and send characters into the usb serial port, the program receives the characters correctly.

By design the program times out after detecting no characters for 10 seconds. It then closes and reopens the serial port.

At this point, sending information results in the first character being lost.

I also have a Perle multiport USB serial device (ID 0403:f0c0).

If I remove the Magic USB, reboot the machine, wait until I login at run level 5, then plug in the Perle multiport device, several /dev/ttyUSBxx devices appear as expected.

Checking the modules shows that ftdi_sio and usbserial modules are loaded.

Running the same program, in the same way, results in no character loss.

So the mct_u232 module appears to be "up the creek".

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

How reproducible:

Steps to Reproduce:
1. Plugin in USB to serial device (ID 0711:0230) to load mct_u232 module.
2. Execute a program that periodically opens/closes the appropriate /dev/ttyUSBxx
3. Send characters into the serial port after a close/open cycle.

Actual Results:  After close/open, mct_u232 loses first character transmitted into the usb to serial device.

Expected Results:  No character loss - it should function in the same way as the ftdi_sio module.

Additional info:
Comment 1 Pete Zaitcev 2006-01-10 20:15:20 EST
My tests seem to work fine here, on the same device.
May I see an strace of the program which receives?
A short self-contained test would be even better.
Of course it's not hard for me to write a program which does open() and close(),
but there seems to be a certain subtlety to it.
Comment 2 Pete Zaitcev 2006-05-18 19:02:40 EDT
The problem is two-fold.

First, the device reports success before it has completed the transmission.
Killing of the interrupt URBs aborts it. Since the driver is reverse-engineered,
there is no way to know if we can poll the device. However, inserting a 2ms
delay into the close() method takes care of the problem.

Second, the driver appears to be vulnerable to the old cooked mode problem
where two characters are sent down (RN (CR), LF (NL)), even if the driver
shrinks the available space between the write calls.
Comment 3 Jiri Pallich 2012-06-20 09:24:16 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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