RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 735048 - USB3 device attached to a USB3 hub, fail to unregister when USB3 hub plug out.
Summary: USB3 device attached to a USB3 hub, fail to unregister when USB3 hub plug out.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Don Zickus
QA Contact: WANG Chao
URL:
Whiteboard:
Depends On:
Blocks: 738147 738151 814315
TreeView+ depends on / blocked
 
Reported: 2011-09-01 09:56 UTC by WANG Chao
Modified: 2015-02-08 21:42 UTC (History)
4 users (show)

Fixed In Version: kernel-2.6.32-206.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 14:27:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1530 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Linux 6 kernel security, bug fix and enhancement update 2011-12-06 01:45:35 UTC

Description WANG Chao 2011-09-01 09:56:04 UTC 
Description of problem:
Attach a USB3 hub to USB3 root hub
# lsusb.py -u
...
usb8            1d6b:0002 09  2.00 480MBit/s   0mA 1IFs (xhci_hcd 0000:02:00.0) hub
usb9            1d6b:0003 09  3.005000MBit/s   0mA 1IFs (xhci_hcd 0000:02:00.0) hub

Plug a USB3 storage device into the USB3 hub.
# lsusb.py -u
...
usb8            1d6b:0002 09  2.00 480MBit/s   0mA 1IFs (xhci_hcd 0000:02:00.0) hub
usb9            1d6b:0003 09  3.005000MBit/s   0mA 1IFs (xhci_hcd 0000:02:00.0) hub
 9-2            2109:0810 09  3.005000MBit/s   2mA 1IFs (VIA Labs, Inc. 4-Port USB 3.0 Hub) hub
  9-2.1         0bc2:50a1 00  3.005000MBit/s   0mA 1IFs (Seagate FA GoFlex Desk NA0JRATK)

Plug out the USB3 hub.Now USB3 device still exits incorrectly.
# lsusb.py -u
...
usb9            1d6b:0003 09  3.005000MBit/s   0mA 1IFs (xhci_hcd 0000:02:00.0) hub
 9-2            2109:0810 09  3.005000MBit/s   2mA 1IFs (VIA Labs, Inc. 4-Port USB 3.0 Hub) hub
  9-2.1         0bc2:50a1 00  3.005000MBit/s   0mA 1IFs (Seagate FA GoFlex Desk NA0JRATK)

dmesg:
usb 8-1: new high speed USB device using xhci_hcd and address 3
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
usb 8-1: New USB device found, idVendor=2109, idProduct=3431
usb 8-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 8-1: Product: USB2.0 Hub
usb 8-1: configuration #1 chosen from 1 choice
hub 8-1:1.0: USB hub found
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
hub 8-1:1.0: 4 ports detected
usb 9-1: new SuperSpeed USB device using xhci_hcd and address 4
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
usb 9-1: New USB device found, idVendor=2109, idProduct=0810
usb 9-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 9-1: Product: 4-Port USB 3.0 Hub
usb 9-1: Manufacturer: VIA Labs, Inc.
usb 9-1: configuration #1 chosen from 1 choice
hub 9-1:1.0: USB hub found
hub 9-1:1.0: 4 ports detected
usb 9-1.4: new SuperSpeed USB device using xhci_hcd and address 5
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
xhci_hcd 0000:02:00.0: WARN: short transfer on control ep
usb 9-1.4: New USB device found, idVendor=0bc2, idProduct=50a1
usb 9-1.4: New USB device strings: Mfr=2, Product=3, SerialNumber=1
usb 9-1.4: Product: FA GoFlex Desk
usb 9-1.4: Manufacturer: Seagate
usb 9-1.4: SerialNumber: NA0JRATK
usb 9-1.4: configuration #1 chosen from 1 choice
scsi7 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 7:0:0:0: Direct-Access     Seagate  FA GoFlex Desk   0D0B PQ: 0 ANSI: 0
sd 7:0:0:0: Attached scsi generic sg2 type 0
sd 7:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
xhci_hcd 0000:02:00.0: WARN: Stalled endpoint
sd 7:0:0:0: [sdb] Write Protect is off
sd 7:0:0:0: [sdb] Mode Sense: 0f 00 00 00
sd 7:0:0:0: [sdb] Assuming drive cache: write through
sd 7:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
xhci_hcd 0000:02:00.0: WARN: Stalled endpoint
sd 7:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 7:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
xhci_hcd 0000:02:00.0: WARN: Stalled endpoint
sd 7:0:0:0: [sdb] Assuming drive cache: write through
sd 7:0:0:0: [sdb] Attached SCSI disk
sd 7:0:0:0: [sdb] Sense Key : Recovered Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
        72 01 04 1d 00 00 00 0a 09 0c 00 00 00 00 00 07
        00 00
sd 7:0:0:0: [sdb] ASC=0x4 ASCQ=0x1d
usb 8-1: USB disconnect, address 3
xhci_hcd 0000:02:00.0: WARN: transfer error on endpoint
xhci_hcd 0000:02:00.0: WARN: transfer error on endpoint
xhci_hcd 0000:02:00.0: WARN: transfer error on endpoint


Version-Release number of selected component (if applicable):
2.6.32-191.el6.x86_64

How reproducible:
Almost every time

Steps to Reproduce:
1.Attach a USB3 hub to USB3 root hub
2.Plug a USB3 storage device into the USB3 hub.
3.Plug out the USB3 hub.
  
Actual results:
USB3 device still there

Expected results:
USB3 device should be gone.

Additional info:
USB3 root hub is a TI PCI-E card
# lspci
02:00.0 USB Controller: Texas Instruments Device 8241 (rev 02)
----
After a few minutes USB3 device unregister(lsusb shows nothing about it).But dmesg give some errors:
(continue with above)
xhci_hcd 0000:02:00.0: WARN: transfer error on endpoint
xhci_hcd 0000:02:00.0: WARN: transfer error on endpoint
xhci_hcd 0000:02:00.0: WARN: transfer error on endpoint
usb 9-1.4: USB disconnect, address 5
hub 9-1:1.0: hub_port_status failed (err = -19)
hub 9-1:1.0: hub_port_status failed (err = -19)
hub 9-1:1.0: hub_port_status failed (err = -19)
hub 9-1:1.0: hub_port_status failed (err = -19)
hub 9-1:1.0: activate --> -19
usb 9-1: USB disconnect, address 4
Comment 2 WANG Chao 2011-09-02 04:28:21 UTC 
Change topology to USB3 root hub -> USB3 hub -> USB2 device, works correctly.
And also test with USB3 root hub -> USB2 hub -> USB2/3 device, works correctly
Comment 3 Don Zickus 2011-09-12 18:58:00 UTC 
Hi Chao,

I put together a 6.2 kernel with about 18 upstream fixes that should help address this bz and a bunch of the others you have filed.

Can you try this when you get a chance to see if you are ok with it.  Most of these issues disappeared when I tried this kernel with my setup.

Not everything is perfect yet, but the scenarios you described in the bzs should at least be addressed now.

You can find the kernel here:

http://brewweb.devel.redhat.com/brew/taskinfo?taskID=3626343

Cheers,
Don
Comment 4 WANG Chao 2011-09-14 03:26:20 UTC 
(In reply to comment #3)
> Hi Chao,
> 
> I put together a 6.2 kernel with about 18 upstream fixes that should help
> address this bz and a bunch of the others you have filed.
> 
> Can you try this when you get a chance to see if you are ok with it.  Most of
> these issues disappeared when I tried this kernel with my setup.
> 
> Not everything is perfect yet, but the scenarios you described in the bzs
> should at least be addressed now.
> 
> You can find the kernel here:
> 
> http://brewweb.devel.redhat.com/brew/taskinfo?taskID=3626343
> 
> Cheers,
> Don

Thanks, Don.
After times of try, this issue is no longer seen.I think these patches should fix this issue.
But this xhci driver still have some problems with usb3 hub.
#1.After times of detach/attach usb3 hub (always with usb3 device attached), usb3 device changed to usb2 mode (see it via lsusb -t).
#2.After times of detach/attach usb3 hub (always with usb3 device attached), xhci driver died.(means all operations to USB3 root hub is not responded).But usb2 driver still works good.
Comment 5 Caspar Zhang 2011-09-14 03:34:57 UTC 
(In reply to comment #4)

> #1.After times of detach/attach usb3 hub (always with usb3 device attached),
> usb3 device changed to usb2 mode (see it via lsusb -t).
> #2.After times of detach/attach usb3 hub (always with usb3 device attached),
> xhci driver died.(means all operations to USB3 root hub is not responded).But
> usb2 driver still works good.

Sounds like another issue we need to open. BTW, when XHCI driver died, did the USB device registered in USB2 mode *automatically*? If so, I suppose #1 and #2 are saying the same thing. Thoughts?
Comment 6 WANG Chao 2011-09-14 04:22:19 UTC 
(In reply to comment #5)
> (In reply to comment #4)
> 
> > #1.After times of detach/attach usb3 hub (always with usb3 device attached),
> > usb3 device changed to usb2 mode (see it via lsusb -t).
> > #2.After times of detach/attach usb3 hub (always with usb3 device attached),
> > xhci driver died.(means all operations to USB3 root hub is not responded).But
> > usb2 driver still works good.
> 
> Sounds like another issue we need to open. BTW, when XHCI driver died, did the
> USB device registered in USB2 mode *automatically*? If so, I suppose #1 and #2
> are saying the same thing. Thoughts?

I have to say, when xhci died, usb3 root hub is not working so that all usb hub/device attach to usb3 root hub will not be responded. So these are two different bugs. But I confirm that ehci/ohci drivers are still alive, and works fine both with usb2 and usb3 device or hub.

BTW, I am not sure if we need to open a new bug because these patches are not in our kernel tree yet, besides issues mentioned in comment #4 didn't happen in 193 kernel.
Comment 7 WANG Chao 2011-09-14 07:27:37 UTC 
Don and Caspar,
I opened bug 738147 and bug 738151 to track issues mentioned in comment #4
Have get you CCed.
Comment 8 Don Zickus 2011-09-14 13:46:26 UTC 
Ok thanks for the feedback Chao.

I'll post the patches I have now as they seem to solve a bunch of your bzs.  I'll poke at the two new bzs you filed (hopefully I can reproduce it).

Thanks,
Don
Comment 9 Don Zickus 2011-09-14 16:01:07 UTC 
Hi Chao,

What machine are you using? Is it a Panther Point?  There was a recent patch that fixed a warm reset status change problem.  It is a simple patch that might work for you.  My machine isn't exhibiting your problem.

Cheers,
Don
Comment 10 Don Zickus 2011-09-14 18:33:09 UTC 
Hi Chao,

I created another brew build that contains a posted upstream patch that adds warm reset to the list of status bits to clear.  This is known to fix problems on Panther Point where the xhci controller stops talking with a port because the port doesn't generate any more events due to the fact that the 'warm reset' bit was never cleared from the previous event.

http://brewweb.devel.redhat.com/brew/taskinfo?taskID=3635408

I couldn't duplicate your original problem on my end, so I can't vouch if this fix helps with non-Panther Point systems.  But it is worth a shot.

Cheers,
Don
Comment 11 WANG Chao 2011-09-15 08:43:02 UTC 
(In reply to comment #10)
> Hi Chao,
> 
> I created another brew build that contains a posted upstream patch that adds
> warm reset to the list of status bits to clear.  This is known to fix problems
> on Panther Point where the xhci controller stops talking with a port because
> the port doesn't generate any more events due to the fact that the 'warm reset'
> bit was never cleared from the previous event.
> 
> http://brewweb.devel.redhat.com/brew/taskinfo?taskID=3635408
> 
> I couldn't duplicate your original problem on my end, so I can't vouch if this
> fix helps with non-Panther Point systems.  But it is worth a shot.
> 
> Cheers,
> Don

Hi Don,
The machine I used is not Panther Point.
It's AMD platform, but USB3 root hub is a TI PCI-E card.
# lspci
...
02:00.0 USB Controller: Texas Instruments Device 8241 (rev 02)
...

And I will try the newly build kernel in a few days, since this machine is not available for now.Will give you feedback ASAP.
Comment 13 RHEL Program Management 2011-09-27 13:01:44 UTC 
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 14 Aristeu Rozanski 2011-10-05 15:33:16 UTC 
Patch(es) available on kernel-2.6.32-206.el6
Comment 19 errata-xmlrpc 2011-12-06 14:27:51 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1530.html
Note You need to log in before you can comment on or make changes to this bug.