Bug 138827 (IT_52182)

Summary: usb: raced timeout errors when using usb/serial adapter
Product: Red Hat Enterprise Linux 3 Reporter: Bastien Nocera <bnocera>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: petrides, riel, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-18 13:28:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 132991    
Attachments:
Description Flags
looptest.cc
none
/proc/bus/usb/devices
none
looptest.cc (fixed: set port on reopen)
none
Candidate #1 - main fix, usb-ohci
none
Candidate #1 - companion fix, ftdi messages none

Description Bastien Nocera 2004-11-11 13:58:20 UTC
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.

Comment 1 Bastien Nocera 2004-11-11 14:00:39 UTC
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

Comment 3 Pete Zaitcev 2004-11-11 16:25:07 UTC
I need /proc/bus/usb/devices.


Comment 4 Bastien Nocera 2004-11-11 16:44:09 UTC
Created attachment 106509 [details]
/proc/bus/usb/devices

Comment 5 Pete Zaitcev 2004-11-12 05:34:16 UTC
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 09:01:07 UTC
2.4.27 vanilla doesn't work, but throws a different error:
Error unlinking urb

Comment 7 Bastien Nocera 2004-11-15 10:43:15 UTC
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 07:37:54 UTC
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.


Comment 9 Pete Zaitcev 2004-11-16 07:41:43 UTC
Created attachment 106787 [details]
looptest.cc (fixed: set port on reopen)

Comment 11 Pete Zaitcev 2004-11-16 23:29:29 UTC
Created attachment 106854 [details]
Candidate #1 - main fix, usb-ohci

Comment 12 Pete Zaitcev 2004-11-16 23:31:48 UTC
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 19:31:39 UTC
Fix is targeted for inclusion in U5.

Comment 14 Ernie Petrides 2005-01-15 00:24:47 UTC
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 13:28:30 UTC
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