Description of problem: When using a simple read/write testcase, using /dev/ttyUSBx as a terminal, the kernel throws these errors: kernel: usb: raced timeout, pipe 0x80000300 status 0 time left 0 and it's not possible to read the data back from the serial port. Version-Release number of selected component (if applicable): 2.4.21-23.ELsmp How reproducible: Every time Steps to Reproduce: 1. Connect a VSCOM USB/serial adapter 2. Launch 3 instances of the testcase on 3 different /dev/ttyUSBx 3. Wait for the error messages in the kernel Actual results: Errors in the kernel logs, data that cannot be read back Expected results: No errors, and no data dropped Additional info: Only happens on OHCI equipped machines (only the "ServerWorks OSB4/CSB5 OHCI USB Controller" was tested), UHCI machines work perfectly. Tested with a vanilla 2.4.27 kernel, the only error message appearing is "Error unlinking urb" from this patch, along with data dropped: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg21320.html Test case attached below.
Created attachment 106497 [details] looptest.cc After a while, you'd get errors like: /dev/ttyUSB0 Read would block: loop 238 FED UP NOT GETTING A RESPONSE - ATTEMPTING TO RESET PORT
I need /proc/bus/usb/devices.
Created attachment 106509 [details] /proc/bus/usb/devices
Regarding the original report, I do not understand its language. Does 2.4.27 work (no hangs or input) or does it not?
2.4.27 vanilla doesn't work, but throws a different error: Error unlinking urb
The customer also tried with RHEL 4 Beta on the Dell machine. It works flawlessly (kernel 2.6.8-1.528.10).
I worked on this a bit today. Here's the deal. #1. The test program is buggy. It forgets to set the port for raw mode when it is reopened. Therefore, it is unable to recover from a lost character. With my fix (to be attached), the test program recovers and continues indefinitely. However... #2. The kernel 2.4.21-25.EL continues to throw hangs, although there are no messages about any raced timeouts. Here's how it looks at the test: /dev/ttyUSB1 Successful write: loop 251 chars 8 /dev/ttyUSB1 - RESPONSE: loop 251 read chars 8 TEST OK /dev/ttyUSB1 Successful write: loop 252 chars 8 /dev/ttyUSB1 Read would block: loop 252 /dev/ttyUSB1 Successful write: loop 253 chars 8 /dev/ttyUSB1 Read would block: loop 253 /dev/ttyUSB1 Successful write: loop 254 chars 8 /dev/ttyUSB1 Read would block: loop 254 FED UP NOT GETTING A RESPONSE - ATTEMPTING TO RESET PORT /dev/ttyUSB1 Successful write: loop 255 chars 8 /dev/ttyUSB1 - RESPONSE: loop 255 read chars 32 TEST OK TEST OK TEST OK TEST OK /dev/ttyUSB1 Successful write: loop 256 chars 8 /dev/ttyUSB1 - RESPONSE: loop 256 read chars 8 TEST OK Obviously, there's no lost character: simply data stop being delivered by the driver; they sit in the device queue and get fetched after reopening. This is what actually is a bug here, not any raced timeouts.
Created attachment 106787 [details] looptest.cc (fixed: set port on reopen)
Created attachment 106854 [details] Candidate #1 - main fix, usb-ohci
Created attachment 106855 [details] Candidate #1 - companion fix, ftdi messages The ftdi needs the upstream fix, although this user did not step on the oops. If we apply the fix, the message also appears on close. Thus, this is a desirable part, but not a vital one.
Fix is targeted for inclusion in U5.
A fix for this problem has just been committed to the RHEL3 U5 patch pool this evening (in kernel version 2.4.21-27.8.EL).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-294.html