Bug 138827 - (IT_52182) usb: raced timeout errors when using usb/serial adapter
usb: raced timeout errors when using usb/serial adapter
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
Blocks: 132991
  Show dependency treegraph
Reported: 2004-11-11 08:58 EST by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-18 09:28:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
looptest.cc (4.15 KB, text/plain)
2004-11-11 09:00 EST, Bastien Nocera
no flags Details
/proc/bus/usb/devices (4.54 KB, text/plain)
2004-11-11 11:44 EST, Bastien Nocera
no flags Details
looptest.cc (fixed: set port on reopen) (4.27 KB, text/plain)
2004-11-16 02:41 EST, Pete Zaitcev
no flags Details
Candidate #1 - main fix, usb-ohci (543 bytes, patch)
2004-11-16 18:29 EST, Pete Zaitcev
no flags Details | Diff
Candidate #1 - companion fix, ftdi messages (1.09 KB, patch)
2004-11-16 18:31 EST, Pete Zaitcev
no flags Details | Diff

  None (edit)
Description Bastien Nocera 2004-11-11 08:58:20 EST
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):

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:

Test case attached below.
Comment 1 Bastien Nocera 2004-11-11 09:00:39 EST
Created attachment 106497 [details]

After a while, you'd get errors like:
/dev/ttyUSB0 Read would block: loop 238
Comment 3 Pete Zaitcev 2004-11-11 11:25:07 EST
I need /proc/bus/usb/devices.
Comment 4 Bastien Nocera 2004-11-11 11:44:09 EST
Created attachment 106509 [details]
Comment 5 Pete Zaitcev 2004-11-12 00:34:16 EST
Regarding the original report, I do not understand its language.
Does 2.4.27 work (no hangs or input) or does it not?
Comment 6 Bastien Nocera 2004-11-12 04:01:07 EST
2.4.27 vanilla doesn't work, but throws a different error:
Error unlinking urb
Comment 7 Bastien Nocera 2004-11-15 05:43:15 EST
The customer also tried with RHEL 4 Beta on the Dell machine. It 
works flawlessly (kernel 2.6.8-1.528.10).
Comment 8 Pete Zaitcev 2004-11-16 02:37:54 EST
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

/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
/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.
Comment 9 Pete Zaitcev 2004-11-16 02:41:43 EST
Created attachment 106787 [details]
looptest.cc (fixed: set port on reopen)
Comment 11 Pete Zaitcev 2004-11-16 18:29:29 EST
Created attachment 106854 [details]
Candidate #1 - main fix, usb-ohci
Comment 12 Pete Zaitcev 2004-11-16 18:31:48 EST
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.
Comment 13 Peter Martuccelli 2004-11-23 14:31:39 EST
Fix is targeted for inclusion in U5.
Comment 14 Ernie Petrides 2005-01-14 19:24:47 EST
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).
Comment 15 Tim Powers 2005-05-18 09:28:30 EDT
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.


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