Red Hat Bugzilla – Bug 170490
usb serial module mct_u232 loses characters
Last modified: 2012-06-20 09:24:16 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
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.
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.
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.
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.