Created attachment 750040 [details] output of lspci -k Description of problem: USB 2.0 and 3.0 are using same controller. Both are assigned xHCI. USB 2.0 does pass power but not data Version-Release number of selected component (if applicable): How reproducible:High Steps to Reproduce: 1.Install linux distro onto Sony Vaio laptop SVT13124CXS 2.Boot 3. Actual results: USB 3.0 functions USB 2.0 only passes power Expected results: Both ports completely function Additional info: Problem persists in Ubuntu, possibly others. Port 2.0 is recognized but does not have complete fuctionality.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Reposting this issue as it persists in Fedora 19. Here is a link to Ubuntu forum showing same problem across T series Sony laptops. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1172908
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
The bug still persists with 3.11.1-200.fc19
Found this post on ubuntu bug site. post # 32 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1210858 Possible fix? not sure how to implement on fedora kernel or if even possible.
The commit mentioned in the ubuntu bug landed in 3.12. Could you please test a 3.12 kernel from the rawhide nodebug repo (being kept on 3.12.y stable) and tell us if this resolves the issue for you? https://fedoraproject.org/wiki/RawhideKernelNodebug
Downloaded rawhide from repo. I am a little confused, I have never used rawhide releases. Must a kernel upgrade be performed when going from 19 to rawhide or can it be insalled from yum update like any other kernel update and chosen from grub menu?
(In reply to hxkhltr from comment #8) > Downloaded rawhide from repo. > > I am a little confused, I have never used rawhide releases. > > Must a kernel upgrade be performed when going from 19 to rawhide or can it > be insalled from yum update like any other kernel update and chosen from > grub menu? The latter. You should just be able to install it and pick it from the grub menu.
Installed latest rawhide from nodebug repo with secure boot disabled in bios, and also did an additional update upon reboot. Problem persists.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
The issue is still present.
Built kernel-3.9.5-301 with patch: --- pci-quirks.c~ 2013-08-06 07:25:47.000000000 -0400 +++ pci-quirks.c 2013-08-30 14:23:47.597891192 -0400 @@ -921,9 +921,10 @@ writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET); hc_init: + /* if (usb_is_intel_switchable_xhci(pdev)) usb_enable_xhci_ports(pdev); - + */ op_reg_base = base + XHCI_HC_LENGTH(readl(base)); /* Wait for the host controller to be ready before writing any USB 2.0 now works until first hibernate, then fails to wake up. Could only find kernel source at http://archive.fedoraproject.org/pub/, could not find more recent source.
Bult kernel-3.12.7-200 with patch: --- pci-quirks.c~ 2013-08-06 07:25:47.000000000 -0400 +++ pci-quirks.c 2013-08-30 14:23:47.597891192 -0400 @@ -921,9 +921,10 @@ writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET); hc_init: + /* if (usb_is_intel_switchable_xhci(pdev)) usb_enable_xhci_ports(pdev); - + */ op_reg_base = base + XHCI_HC_LENGTH(readl(base)); /* Wait for the host controller to be ready before writing any USB port functions until resume from hibernate or suspend.
Built kernel-3.12.7-200 with previous patch plus : diff -uNrp kernel-3.12.fc19.orig/linux-3.12.7-200.fc19.x86_64/drivers/usb/host/xhci-pci.c kernel-3.12.fc19.new/linux-3.12.7-200.fc19.x86_64/drivers/usb/host/xhci-pci.c --- linux-3.12.7-200.fc19.x86_64/drivers/usb/host/xhci-pci.c 2014-01-19 11:47:25.736703734 -0500 +++ linux-3.12.7-200.fc19.x86_64/drivers/usb/host/xhci-pci.c 2014-01-19 11:51:14.563535198 -0500 @@ -289,9 +289,10 @@ static int xhci_pci_resume(struct usb_hc * running again until after all the devices (including both EHCI and * xHCI host controllers) have been resumed. */ - + /* if (pdev->vendor == PCI_VENDOR_ID_INTEL) usb_enable_intel_xhci_ports(pdev); + */ retval = xhci_resume(xhci, hibernated); return retval; USB now works on boot and after resume. It seems that one brancing statement calling that particular function is hindering the port. Personally I don't know if this is the best way to handle the problem, but it does seem to work.
Had to compile new kernel with patch again for usb to work. Any thoughts on possible solutions for main line realease.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
updated to kernel-3.13.5-101 and problem still persists.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.14.4-100.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
Issue persists with kernel-3.14.4-100.fc19.x86_64.
Issue resolved with kernel-3.14.7-100.fc19.x86_64.
Thanks.