Bug 241002 - USB2.0 hub disappears after overcurrent on another port
USB2.0 hub disappears after overcurrent on another port
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.5
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Feeney
Martin Jenner
:
Depends On:
Blocks: 246028
  Show dependency treegraph
 
Reported: 2007-05-23 12:22 EDT by Stuart Hayes
Modified: 2007-11-16 20:14 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2007-0791
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 11:27:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for rhel4.5 (2.6.9-55.EL) (4.36 KB, patch)
2007-05-23 12:22 EDT, Stuart Hayes
no flags Details | Diff

  None (edit)
Description Stuart Hayes 2007-05-23 12:22:01 EDT
Description of problem:

This problem is very similar to BZ231226--this was discovered while testing 
the fix that's in 231226.

When an empty USB port on the rear of a system has an overcurrent (I use a 
paper clip to briefly connect the power pin to the chassis), the front ports 
on this system quit working.  The front ports on this system are connected 
through an internal Cypress USB2.0 hub.

The problem is that the overcurrent causes the EHCI controller to get an error 
when it tries to talk to the hub, and hub_events() will see hub->error, and 
try to reset the controller by calling hub_reset().  The hub_reset() function 
calls __usb_reset_device, which refuses to reset a hub (see the FIXME in 
__usb_reset_device()), so hub_reset() fails, and the hub is gone.

This was fixed some time ago upstream, with this patch:
http://marc.info/?l=linux-usb-devel&m=109511190511780&w=2

It was trivial to port this patch to RHEL4.5 (2.6.9-55.EL).  I'll attach the 
patch for RHEL4.5.



Version-Release number of selected component (if applicable):
2.6.9-55.EL

How reproducible:
every time

Steps to Reproduce:
1. get system with internal cypress usb hub (many dell servers have this)
2. short power pin to chassis on unused rear USB port
3. observe that hub is no longer listed in "lsusb" output
  
Actual results:
hub disappears

Expected results:
hub should reappear after overcurrent error handling

Additional info:
Comment 1 Stuart Hayes 2007-05-23 12:22:01 EDT
Created attachment 155272 [details]
patch for rhel4.5 (2.6.9-55.EL)
Comment 2 RHEL Product and Program Management 2007-06-22 18:04:41 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 John Feeney 2007-07-02 15:13:39 EDT
Just for the record, I found the patch above did not compile cleanly in
RHEL-4 because usb_disconnect_nolock() was no longer called. I removed
this function, built rpms with Brew, and asked Stuart to test Brew-built 
release which he did successfully (thanks again). I could not find
usb_disconnect_nolock() upstream but it was added to RHEL-4 by another 
patch. 

Submitted to rhkernel-list so setting state to post.
Comment 4 Pete Zaitcev 2007-07-17 20:52:57 EDT
The usb_disconnect_nolock was added to fix bug 171220.
Comment 5 Stuart Hayes 2007-07-18 12:22:44 EDT
It looks like the code that calls usb_disconnnect_nolock() is 
hub_start_disconnect() in the -55 kernel (before the patch in comment #1 is 
applied).  After the patch from comment #1 is applied, that code is in 
hub_pre_reset().

So, to apply the patch from comment #1 AND keep the fix for bug 171220, I 
believe all you'd need to do is apply the patch from comment #1 and then 
modify hub_pre_reset() to call usb_disconnect_nolock() instead of 
usb_disconnect().
Comment 6 Pete Zaitcev 2007-07-18 18:16:02 EDT
I disagree with Stuart about the usb_disconnect_nolock. The code to disconnect
the hub itself (if reset fails) is removed completely by the patch in question.
The code to disconnect hub's children was moved from hub_reset to hub_pre_reset.
The deadlock in bug 171220 was caused by hub_start_disconnect, and thus cannot
happen if hub_start_disconnect is removed. I may be wrong, but it looks this way.

John, please always attach the patch to the bug as posted for review.
Don't make us guess later.
Comment 7 John Feeney 2007-07-18 18:37:20 EDT
Pete,
Sorry if there was confusion about the patch. I did attach the patch that
I created from Stuart's when I posted it to rhkernel-list. I wrote you an 
email recently where I tried to explain the code and it crossed my mind that I 
should include the new patch as well, but I didn't. Perhaps that is where I went
wrong.

 John 
Comment 8 Stuart Hayes 2007-07-19 09:55:48 EDT
I would assume Pete is correct in comment #6.  I didn't spend too much time 
looking at the code when I posted comment #5.  I'll look at it again today to 
convince myself.
Comment 9 Stuart Hayes 2007-07-19 11:22:02 EDT
OK, yeah, I agree with Pete.  With the patch from comment #1 applied to the -
55 kernel, the code in hub_pre_reset is disconnecting the hub's children.  The 
code that caused the deadlock in bug 171220 was trying to disconnect the hub 
itself.  With the patch from comment #1 applied to the -55 kernel, it doesn't 
look like the hub itself gets disconnected when there's a hub error--it will 
disconnect the children, and try to reset the hub, and spew an error message 
if it can't reset the hub, but I don't see it actually disconnecting the hub 
itself.

I'm sorry about the confusion I caused with comment #5.
Comment 10 Jason Baron 2007-07-25 10:29:56 EDT
committed in stream U6 build 55.22. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 14 errata-xmlrpc 2007-11-15 11:27:32 EST
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/RHBA-2007-0791.html

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