[Lenovo ThinkPad X230 Tablet] USB devices in docking station no longer working after resuming from standby

It happens *not* always! Sorry for misspelling.

This change was made by a bot.

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.8 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc6-raring/

Did this issue start happening after an update/upgrade? Was there a kernel version where you were not having this particular problem? This will help determine if the problem you are seeing is the result of the introduction of a regression, and when this regression was introduced.

I've just installed ubuntu 12.10 on my new shiny x230 so I cannot say. So it might be regression or not.
I will checkout the upstream kernel and let you know.

i installed linux-image, but I couldn't linux-header. Despite of this I booted the kernel but usb wasn't working, eitherin dock or in the laptop itself and beside the ethernet was NO-CARRIER and wifi was not detected ;-]

Here's the log while installing linux-headers:

$ sudo dpkg -i linux-headers-3.8.0-030800rc6-generic_3.8.0-030800rc6.201301312135_amd64.deb
(Reading database ... 389503 files and directories currently installed.)
Preparing to replace linux-headers-3.8.0-030800rc6-generic 3.8.0-030800rc6.201301312135 (using linux-headers-3.8.0-030800rc6-generic_3.8.0-030800rc6.201301312135_amd64.deb) ...
Unpacking replacement linux-headers-3.8.0-030800rc6-generic ...
dpkg: dependency problems prevent configuration of linux-headers-3.8.0-030800rc6-generic:
 linux-headers-3.8.0-030800rc6-generic depends on linux-headers-3.8.0-030800rc6; however:
  Package linux-headers-3.8.0-030800rc6 is not installed.

dpkg: error processing linux-headers-3.8.0-030800rc6-generic (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-headers-3.8.0-030800rc6-generic

Figured I'd chime in on this thread - this phenomenon seems to affect Windows 7 as well.

All USB capability completely disappears on resume if the X230 is left in S3 mode for a "long" period of time (ie: overnight, but without entering S4 hibernate).

Leaving the X230 in sleep mode for shorter durations doesn't seem to trigger the bug.

The latest X230 BIOS (2.51) doesn't seem to fix this, either.

I just hit this or a very similar bug on a Latitude E5530 with 3.2.0-4-amd64 (debian wheezy), it was sleep over night undocked, and i put it back in the dock shortly before resuming:

[...]
usb 1-4.1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
usb 1-4.1: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
xhci_hcd 0000:00:14.0: Not enough bandwidth on HS bus for newly activated TT.

Reloading xhci_hcd fixed it for me (as root):
rmmod -f xhci_hcd; modprobe xhci_hcd

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Same here on Dell E6410 on latest Upstream Kernel 3.11.0

Never had an issue before. Since a few days (and after upgrading from 3.10 to 3.11) I experience a whole set of issues related to the docking station. One time the secondary monitor is not recognized. This morning none of the USB devices (keyboard/mouse) working, As Robert wrote: "All USB capability completely disappears on resume if the X230 is left in S3 mode for a "long" period of time"

I wonder if this might be rather a physical connection issue or really a software issue.

Anyone a hint about what bandwith the error message "Not enough bandwidth on HS bus for newly activated TT." is talking about?

Please do not mix in the same issue with complete different hardware. Rather open a new bug report for the Dell hardware.

Same issue here on Dell E6530 with kernel 3.11.0-13-generic, but it also occured with previous versions of the Kernel / Ubuntu. Messages from dmesg attached.

I've seen comment #12 but I still reported the issue here as it seems to be the same hardware involved (USB controller Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller):

00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 6 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04)
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio Controller (rev a1)
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)
0c:00.0 SD Host controller: O2 Micro, Inc. Device 8221 (rev 05)

Funny thing is that built-in port in the laptop are always working, only those in dock station are failing...

lol24h, as per http://download.lenovo.com/express/ddfm.html an update is available for your BIOS (2.54). If you update to this following https://help.ubuntu.com/community/BiosUpdate , does it change anything? If it doesn't, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful.

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Thank you for your understanding.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

I also get this on a machine running trusty. The BIOS ought to be fairly up to date:

root@pareto:/sys# dmidecode -s bios-version && dmidecode -s bios-release-date
G2ET99WW (2.59 )
12/04/2013

I looked into the code behind the "Not enough bandwidth on HS bus for newly activated TT" kernel message a little. It's in a software check that enough bandwidth is available for new USB devices, which is currently only performed for Intel Pantherpoint chipsets like the X230's. This failure appears to be enough to prevent the new USB device from working. Hence I suspect a problem with the kernel's xhci code, very possibily in the bandwidth check code. You can see the patch set that added the bandwidth checking code at http://thread.gmane.org/gmane.linux.usb.general/51765/focus=51993

$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
GCET98WW (2.58 )
03/12/2014

I will try newer.

But what I have seen at your link ... do these patches were applied finalyl at mainstream or not ?

unfortunately for my model the 2.58 is the newest I can get

I think you've misunderstood me: I've got a newer version but still have the problem, and those patches don't solve it, but introduced the code which does the bandwidth checking.

Johannes, please do not add stray bug tasks. If you have a bug in Arch, report it to their bug tracker directly -> https://bugs.archlinux.org/ .

Status changed to 'Confirmed' because the bug affects multiple users.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

I recently upgraded 14.10 and this bug still persists. Its a Lenovo Thinkpad x230t with an Ultrabase series 3.

$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
GCET99WW (2.59 )
05/28/2014

$ uname -r
3.16.0-23-generic
Package is: 3.16.0.23.24

Just to confirm here is the relevent parts of my dmesg after I run into this issue:
[143413.038373] usb 3-3.4: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[143413.038379] usb 3-3.4: ep 0x82 - rounding interval to 64 microframes, ep desc says 80 microframes
[143413.038387] xhci_hcd 0000:00:14.0: Not enough bandwidth on HS bus for newly activated TT.
[143413.038392] xhci_hcd 0000:00:14.0: Not enough bandwidth
[143413.038398] usb 3-3.4: can't set config #1, error -12
[143428.402487] ACPI: \_SB_.GDCK: undocking
[143428.403740] ata2: exception Emask 0x50 SAct 0x0 SErr 0x4090800 action 0xe frozen
[143428.403743] ata2: irq_stat 0x00400040, connection status changed
[143428.403745] ata2: SError: { HostInt PHYRdyChg 10B8B DevExch }

Behaviour is exactly the same as has already been reported

I will test the current upstream kernel 3.17 from the Kernel PPA soon but as it tends to take a few days before I run into this issue it might be a while before I report the details.

@penalvch Should I follow your instructions in post #22?

Adam Lyall, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into the default Ubuntu kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

As well, please do not announce in this report you created a new bug report.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

A couple of months ago I submitted a patch upstream to fix this (http://article.gmane.org/gmane.linux.usb.general/128350), which is now appearing in the Ubuntu kernels. In particular, I received a kernel update for trusty yesterday which includes it, 3.13.0-65, and I think that vivid and wily should have it too. Before closing the bug I'd appreciate it if other people who have experienced the problem (especially the original reporter, lol24h) could confirm whether the new kernels solve the issue for them.

At this point i use kernel:

Linux slice 3.19.0-28-generic #30-Ubuntu SMP Mon Aug 31 15:52:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Shall I check this one ? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-vivid/

You should be able to get 3.19.0-30 for vivid through the normal security updates. According to the changelog it includes the patch (unlike -28).

The problem persist. the usb soundcard does not wake up, even when reattached. Beside I can't suspend at least this time after being waken up once. There's some stacktrace in dmesg. I made another bug report

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1503822

From the log messages that looks like a different problem. Am I right in thinking that the trouble with suspending started later than the trouble with USB devices disappearing? Does suspend and resume work reliably without devices disappearing if you don't have the USB soundcard attached?

lol24h, could you please test the latest upstream kernel available from the very top line at the top of the page from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D (the release names are irrelevant for testing, and please do not test the daily folder)? Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds . This will allow additional upstream developers to examine the issue.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, Y, and Z are numbers corresponding to the kernel version.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the latest upstream kernel is complete, please mark this report's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]