Bug 115121 - Thunderbolt 3 (Skylake / Alpine Ridge) hotplug does not work
Summary: Thunderbolt 3 (Skylake / Alpine Ridge) hotplug does not work
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: PCI (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_pci@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-22 08:24 UTC by Jack Coulter
Modified: 2017-12-14 20:47 UTC (History)
22 users (show)

See Also:
Kernel Version: 4.4.3
Tree: Mainline
Regression: No


Attachments
kernel config (116.18 KB, application/octet-stream)
2016-03-22 08:24 UTC, Jack Coulter
Details
lspci -vv when device is hotplugged (41.51 KB, text/x-log)
2016-03-22 08:24 UTC, Jack Coulter
Details
lspci -vv when device is present at boot (58.45 KB, text/x-log)
2016-03-22 08:25 UTC, Jack Coulter
Details
dmesg when device is present at boot (51.29 KB, text/x-log)
2016-03-22 08:25 UTC, Jack Coulter
Details
dmesg when device is hotplugged (53.09 KB, text/x-log)
2016-03-22 08:25 UTC, Jack Coulter
Details
acpidump (889.92 KB, application/octet-stream)
2016-03-24 07:23 UTC, Jack Coulter
Details
dmesg with acpiphp.dyndbg (53.80 KB, text/plain)
2016-03-24 07:28 UTC, Jack Coulter
Details

Description Jack Coulter 2016-03-22 08:24:31 UTC
Created attachment 210191 [details]
kernel config

I'm attempting to use the Thunderbolt 3 (which has a USB Type-C
connector) port on my laptop, a Dell XPS 15 (9550). The external device
I'm attempting to use is a gigabit ethernet + USB 3.0 hub, of an unknown
/ generic brand, but bears model number KY-688 if that's of any use.

When the device is present at system startup, everything works
correctly, and shows up in lspci as a USB controller, which lsusb shows
having a hub and ethernet NIC attached, which the r8152 driver binds and
uses without issue.

However, if the device is connected after the system boots (or
disconnected and reconnected), it is not detected at all. No messages
show up in dmesg upon connection and no additional devices show up in
the output of lspci & lsusb. Strangely enough, USB devices connected to
the external hub do still receive power.
Comment 1 Jack Coulter 2016-03-22 08:24:54 UTC
Created attachment 210201 [details]
lspci -vv when device is hotplugged
Comment 2 Jack Coulter 2016-03-22 08:25:12 UTC
Created attachment 210211 [details]
lspci -vv when device is present at boot
Comment 3 Jack Coulter 2016-03-22 08:25:30 UTC
Created attachment 210221 [details]
dmesg when device is present at boot
Comment 4 Jack Coulter 2016-03-22 08:25:45 UTC
Created attachment 210231 [details]
dmesg when device is hotplugged
Comment 5 Mika Westerberg 2016-03-22 10:14:17 UTC
Can you add "acpiphp.dyndbg" to the kernel command line and do hotplug/unplug? Then attach that dmesg to this bug.

You may need to set CONFIG_DYNAMIC_DEBUG=y from your kernel .config first.
Comment 6 Mika Westerberg 2016-03-22 10:37:25 UTC
Also please attach acpidump of that machine.
Comment 7 Lukas Wunner 2016-03-22 19:55:25 UTC
The Thunderbolt controller is device 06:00.0, connected to PCIe port 00:1d.6. Now if you compare the two lspci outputs of 00:1d.6 you'll notice the following (if hotplugged):

LnkCtl:	CommClk- (versus CommClk+ if plugged on boot)
SltSta:	Changed: LinkState+ (versus LinkState- if plugged on boot)

Also the Thunderbolt controller isn't visible if nothing is plugged in on boot. It looks like the controller is powered off until something is plugged in and then the PCIe port 00:1d.6 is supposed to get a hotplug interrupt and recognize the controller. Question is, does it get an interrupt at all? MSI is disabled.

Try booting with: pciehp.pciehp_poll_mode=1
Comment 8 Jack Coulter 2016-03-24 07:23:13 UTC
Created attachment 210541 [details]
acpidump
Comment 9 Jack Coulter 2016-03-24 07:28:03 UTC
Created attachment 210551 [details]
dmesg with acpiphp.dyndbg

Hi Mika,

I added acpiphp.dyndbg to my cmdline and set CONFIG_DYNAMIC_DEBUG=y. Attached is the dmesg output upon attaching the device. Unfortunately it still does not appear to show any new output.

My command line when this dmesg log was generated is, in full:

rd.auto rd.vconsole.font=ter-v32n rd.md=0 rd.dm=0 rd.luks.allow-discards root=/dev/mapper/volumes-btrfs rootfstype=btrfs rootflags=compress=lzo,acl,autodefrag resume=/dev/mapper/volumes-swap init=/usr/lib/systemd/systemd kvm-intel.nested=1 rw pciehp.pciehp_poll_mode=1 acpiphp.dyndbg crashkernel=192M 
Comment 10 Jack Coulter 2016-03-24 07:28:30 UTC
Also, I attached the acpidump as requested
Comment 11 Jack Coulter 2016-03-24 07:29:19 UTC
Hi Lukas,

I've added pciehp.pciehp_poll_mode=1 to my command line but unfortunately this results in no change in behaviour - my full command line is as per my comment to Mika above.


Kind regards,
Jack
Comment 12 Jodi Giordano 2016-03-25 01:40:56 UTC
I don't know if it's relevant but if the hardware has the model number KY-688 and is plugged in the thunderbolt/usb-c port of the Dell XPS 15 (9550), it's probably the "KY-688 Mini 3-Port USB 3.1 Type C to USB 3.0 HUB", which is USB 3.1 and NOT Thunderbolt 3.
Comment 13 Lukas Wunner 2016-03-25 12:24:50 UTC
@Jodi Giordano: That's a very good point. In the lspci output it can be seen that the USB hub appears behind the Thunderbolt controller, however there are no PCI bridges between the controller's downstream bridge and the USB hub. If the USB hub was a regular Thunderbolt device, there would be two PCI bridges between it and the controller's downstream bridge. So indeed it looks like this is not a Thunderbolt device, yet the Thunderbolt controller is needed to bridge to it. And that's the problem, the Thunderbolt controller is not there.
Comment 14 Mika Westerberg 2016-03-29 10:24:56 UTC
Since you do not seem to get ACPI hotplug event there might be something wrong with the firmware itself. Have you tried to upgrade that?

I found this:

http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=HCC25&fileId=3527700934&osCode=WT64A&productCode=xps-15-9550-laptop&languageCode=en&categoryId=CS

maybe it helps?
Comment 15 Jack Coulter 2016-03-30 04:13:42 UTC
@Mika: I will give the firmware update a try; I don't have Windows installed on the machine at the moment, so I'll need to set up a live USB or something similar.

Will report back as to whether it resolves the issue once I've managed to apply the update.
Comment 16 Jack Coulter 2016-03-30 11:22:33 UTC
I successfully got Windows to boot off an external drive and can confirm that hotplugging the device _does_ work correctly in Windows. This is without installing the Dell provided TB firmware update.

After installing the TB controller firmware update, hotplug still works fine under Windows, but there is no change in behavior under Linux - no dmesg output is generated upon connecting the device.
Comment 17 Mika Westerberg 2016-03-30 11:45:01 UTC
Ok, good to know that it works in Windows. Can you check /proc/interrupts if the "acpi" entry increases when you do hotplug?
Comment 18 Jack Coulter 2016-03-30 12:26:01 UTC
No change in the 'acpi' line of /proc/interrupts after connecting the device, unfortunately.
Comment 19 Mika Westerberg 2016-03-30 15:08:33 UTC
When you tried hotplug in Windows, did it ask you to authorize the device? I asked from our thunderbolt guys and they said that if that's the case then Linux does not currently support it but it may be possible to disable that functionality from BIOS by changing security level to "Legacy mode".
Comment 20 Jack Coulter 2016-03-31 00:41:35 UTC
No - upon connection the device started working without any interaction; the ethernet connection on it came up and the USB devices on the hub appeared.
Comment 21 Jack Coulter 2016-03-31 01:17:17 UTC
I checked in the BIOS on my machine and the Thunderbolt security mode is currently set to "Security level - No security".
Comment 22 Trevor Vaughan 2016-04-01 02:16:13 UTC
Hi All,

I have the Dell XPS 13 9350 and am experiencing the same issue on the 4.4.6 kernel.

No new results from what Jack posted but happy to try whatever proposed fixes come along.
Comment 23 Trevor Vaughan 2016-04-01 03:54:18 UTC
The issue exists in 4.6.0 as well. Unplugging the device, suspending the system, plugging in an external device, then coming back up from suspend re-registers the device with the system with the 4.6.0 kernel.
Comment 24 Jack Coulter 2016-04-04 09:02:54 UTC
Interestingly, on 4.5.0 suspending and resuming does _not_ result in the device being recognised.
Comment 25 Prarit Bhargava 2016-04-05 12:10:12 UTC
Everyone, please try 

http://marc.info/?l=linux-acpi&m=145929159015853&w=2

and let us know if it works.

Thanks,

P.
Comment 26 Jack Coulter 2016-04-05 12:59:59 UTC
Currently compiling a kernel with the above patch. Will report back with results when I've had a chance to try it.
Comment 27 maxim.kraev 2016-04-05 15:07:22 UTC
I can confirm the patch http://marc.info/?l=linux-acpi&m=145929159015853&w=2 solves the issue.
Comment 28 Jack Coulter 2016-04-06 01:43:07 UTC
Seconding that - I can confirm that applying the above patch on 4.5.0 now allows hotplug to work
Comment 29 Trevor Vaughan 2016-04-07 02:47:54 UTC
Since others got it to work on stock, I attempted in Fedora Core 23 on 4.4.6.

The patch needed to be slightly modified as below, but I can also confirm that this fixed the issue.

---
 drivers/acpi/acpica/dsmethod.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index bc32f31..8c4c234 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -417,6 +417,9 @@ acpi_ds_begin_method_execution(struct acpi_namespace_node *method_node,
        obj_desc->method.mutex->mutex.
            original_sync_level = 
            obj_desc->method.mutex->mutex.sync_level;
+
+        obj_desc->method.mutex->mutex.thread_id =
+            acpi_os_get_thread_id();
      } 
    } 
 
-- 
2.5.5
Comment 30 Martin Andersson 2016-04-08 15:01:10 UTC
I have had some success with this patch as well with a Dell Thunderbolt 3 dock

https://bugzilla.kernel.org/show_bug.cgi?id=115931

The dock is not functional in Linux yet (pci-devices from the dock are detected but are not functional).

This patch allows the kernel to detect the, non fuctional, pci-devices when hotplugged.
Comment 31 Jarod Wilson 2016-04-12 18:32:57 UTC
(In reply to Martin Andersson from comment #30)
> I have had some success with this patch as well with a Dell Thunderbolt 3
> dock
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=115931
> 
> The dock is not functional in Linux yet (pci-devices from the dock are
> detected but are not functional).
> 
> This patch allows the kernel to detect the, non fuctional, pci-devices when
> hotplugged.

I don't think it's actually devices on the dock that you're seeing, but rather the four thunderbolt-provided pci bridges that come up. Unless your lspci output is considerably different from mine, anyway. When I plug the dock into a Precision 3510 with this patch, I suddenly see 4 new alpine ridge pci bridges and the alpine ridge nhi. Nothing on the dock itself.
Comment 32 Prarit Bhargava 2016-04-12 18:37:30 UTC
I've been talking with a Dell engineer about getting this to work and it looks like you need to re-install Windows, update the TB firmware, and then jump back to Linux [+ my kernel patch] to get the devices to work.

I'm going to try this on one of our Dell laptops to see if it actually works or not.

P.
Comment 33 Martin Andersson 2016-04-13 08:26:45 UTC
@Jarod You're absolutely right. It's only the pci bridges. It seems the dock is still only detected when plugged in at boot.
Comment 34 Trevor Vaughan 2016-04-13 09:45:19 UTC
(In reply to Prarit Bhargava from comment #32)
> I've been talking with a Dell engineer about getting this to work and it
> looks like you need to re-install Windows, update the TB firmware, and then
> jump back to Linux [+ my kernel patch] to get the devices to work.
> 
> I'm going to try this on one of our Dell laptops to see if it actually works
> or not.
> 
> P.

@Prarit,

Did they have any advice for those that purchased a laptop with native Linux?

I attempted to update the drivers via FreeDOS but, though the website indicated that it should work, the actual executable refused to run.

Unless they're going to supply a copy of Windows for firmware updates, they really should be putting them out in a form that runs on their provides OS loads.
Comment 35 Prarit Bhargava 2016-04-13 10:08:07 UTC
(In reply to Trevor Vaughan from comment #34)

> @Prarit,
> 
> Did they have any advice for those that purchased a laptop with native Linux?
> 

IIUC they are working on a solution.  Hopefully that will be released publicly soon. 


> I attempted to update the drivers via FreeDOS but, though the website
> indicated that it should work, the actual executable refused to run.

Interesting.  I'm going to try that today or tomorrow (before reinstalling
Windows & updating).  If that is -ENOWORKY then I'll push that back over to Dell.

> 
> Unless they're going to supply a copy of Windows for firmware updates, they
> really should be putting them out in a form that runs on their provides OS
> loads.

I agree _completely_.

P.
Comment 36 Jack Coulter 2016-04-13 10:09:08 UTC
Some further feedback regarding the dsmethod patch. While the patch does allow my  non-Thunderbolt device (the KY-688 USB hub + ethernet NIC) to be detected when hotplugged using the TB3/USB-C port on initial boot, if the system is suspended and resumed, hotplug of the device will no longer work.
Comment 37 Martin Andersson 2016-04-13 11:06:48 UTC
A tip to all of you who need to update your firmware:

I was able to create a Windows To Go usb stick from a trial iso of Windows 10. It took some tries and I don't remember all the steps but google is your friend.

That way you don't have to install Windows on your computer and you don't have to buy a license.
Comment 38 Prarit Bhargava 2016-04-13 11:35:15 UTC
(In reply to Jack Coulter from comment #36)
> Some further feedback regarding the dsmethod patch. While the patch does
> allow my  non-Thunderbolt device (the KY-688 USB hub + ethernet NIC) to be
> detected when hotplugged using the TB3/USB-C port on initial boot, if the
> system is suspended and resumed, hotplug of the device will no longer work.

How did it ever work without the 2 line patch?

P.
Comment 39 Jack Coulter 2016-04-13 13:08:32 UTC
@Prarit: It didn't work at all (even hotplugged after an initial cold boot) without the patch, hence me logging this bug in the first place.

The patch allows hotplug to work if the device is connected to the system after a _cold_ boot. It does not however, solve the issue of the device not being detected when it is connected to the system when the system has been suspended & resumed at least once.
Comment 40 Lv Zheng 2016-04-14 07:17:38 UTC
Hi,

Could the following boot parameter work for you guys:
acpi_no_auto_serialize

Thanks and best regards
-Lv
Comment 41 Prarit Bhargava 2016-04-14 11:34:31 UTC
(In reply to Lv Zheng from comment #40)
> Hi,
> 
> Could the following boot parameter work for you guys:
> acpi_no_auto_serialize
> 
> Thanks and best regards
> -Lv

When acpi_no_auto_serialize is specified as a kernel parameter, and a device is plugged into the TB port, the system hangs.

P.
Comment 42 Prarit Bhargava 2016-04-14 11:48:32 UTC
(In reply to Prarit Bhargava from comment #41)
> (In reply to Lv Zheng from comment #40)
> > Hi,
> > 
> > Could the following boot parameter work for you guys:
> > acpi_no_auto_serialize
> > 
> > Thanks and best regards
> > -Lv
> 
> When acpi_no_auto_serialize is specified as a kernel parameter, and a device
> is plugged into the TB port, the system hangs.
> 
> P.

Actually -- I take that last statement on the hang back.  The system does come back after a while but no device (in my case an ethernet device) is found.

P.
Comment 43 Lv Zheng 2016-04-15 05:24:23 UTC
(In reply to Prarit Bhargava from comment #42)
> (In reply to Prarit Bhargava from comment #41)
> > (In reply to Lv Zheng from comment #40)
> > > Hi,
> > > 
> > > Could the following boot parameter work for you guys:
> > > acpi_no_auto_serialize
> > > 
> > > Thanks and best regards
> > > -Lv
> > 
> > When acpi_no_auto_serialize is specified as a kernel parameter, and a
> device
> > is plugged into the TB port, the system hangs.
> > 
> > P.
> 
> Actually -- I take that last statement on the hang back.  The system does
> come back after a while but no device (in my case an ethernet device) is
> found.
> 
> P.

Can the device be found if the patch is applied and the acpi_no_auto_serialize is not used.

Thanks
-Lv
Comment 44 Prarit Bhargava 2016-04-15 09:57:13 UTC
(In reply to Lv Zheng from comment #43)

> Can the device be found if the patch is applied and the
> acpi_no_auto_serialize is not used.
> 

Yes, the patch works.  And there are several other reports in this BZ of the patch working for other users.

P.
Comment 45 Lv Zheng 2016-04-18 07:54:38 UTC
OK, we'll about to merge the patch via ACPICA upstream.

Thanks
-Lv
Comment 46 Greg White 2016-05-12 20:48:53 UTC
"The patch allows hotplug to work if the device is connected to the system after a _cold_ boot. It does not however, solve the issue of the device not being detected when it is connected to the system when the system has been suspended & resumed at least once."

Exactly so.  Works perfectly until system is suspended/resumed.  Then nothing.
Comment 47 Mario Limonciello 2016-05-12 20:56:42 UTC
@Greg
Are you sure about that?  I just tested on an XPS 9350 4.4 kernel with that patch backported on top of it.

WD15 Type-C dock.  Booted with it plugged, in saw everything in lsusb.
Suspended, resumed, all still there.
Hotplugged, took about 30 seconds for everything to show up, but it did again.
Comment 48 Greg White 2016-05-12 20:59:59 UTC
Absolutely certain.  Here's a hotplug, a remove, and a resume followed by a hotplug.

[ 4168.354930] ACPI Error: [SPRT] Namespace lookup failure, AE_ALREADY_EXISTS (20160108/dswload2-330)
[ 4168.354943] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160108/psobject-227)
[ 4168.354949] ACPI Error: Method parse/execution failed [\_GPE._E42] (Node ffff88089d0dec30), AE_ALREADY_EXISTS (20160108/psparse-542)
[ 4168.354959] ACPI Error: Method parse/execution failed [\_GPE._E42] (Node ffff88089d0dec30), AE_ALREADY_EXISTS (20160108/psparse-542)
[ 4168.354972] ACPI Exception: AE_ALREADY_EXISTS, while evaluating GPE method [_E42] (20160108/evgpe-592)
[ 4168.401290] pci 0000:05:00.0: [8086:1576] type 01 class 0x060400
[ 4168.401473] pci 0000:05:00.0: supports D1 D2
[ 4168.401475] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 4168.401614] pci 0000:05:00.0: System wakeup disabled by ACPI
[ 4168.409168] pci 0000:06:00.0: [8086:1576] type 01 class 0x060400
[ 4168.409623] pci 0000:06:00.0: supports D1 D2
[ 4168.409626] pci 0000:06:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 4168.409883] pci 0000:06:01.0: [8086:1576] type 01 class 0x060400
[ 4168.410345] pci 0000:06:01.0: supports D1 D2
[ 4168.410347] pci 0000:06:01.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 4168.410599] pci 0000:06:02.0: [8086:1576] type 01 class 0x060400
[ 4168.411047] pci 0000:06:02.0: supports D1 D2
[ 4168.411050] pci 0000:06:02.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 4168.411382] pci 0000:05:00.0: PCI bridge to [bus 06-3d]
[ 4168.411400] pci 0000:05:00.0:   bridge window [mem 0xc4000000-0xda0fffff]
[ 4168.411413] pci 0000:05:00.0:   bridge window [mem 0x80000000-0xa1ffffff 64bit pref]
[ 4168.411566] pci 0000:06:00.0: PCI bridge to [bus 07]
[ 4168.411599] pci 0000:06:00.0:   bridge window [mem 0xda000000-0xda0fffff]
[ 4168.411772] pci 0000:06:01.0: PCI bridge to [bus 08-3c]
[ 4168.411802] pci 0000:06:01.0:   bridge window [mem 0xc4000000-0xd9efffff]
[ 4168.411821] pci 0000:06:01.0:   bridge window [mem 0x80000000-0xa1ffffff 64bit pref]
[ 4168.412024] pci 0000:3d:00.0: [8086:15b5] type 00 class 0x0c0330
[ 4168.412097] pci 0000:3d:00.0: reg 0x10: [mem 0xd9f00000-0xd9f0ffff]
[ 4168.412695] pci 0000:3d:00.0: supports D1 D2
[ 4168.412698] pci 0000:3d:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 4168.413018] pci 0000:06:02.0: PCI bridge to [bus 3d]
[ 4168.413048] pci 0000:06:02.0:   bridge window [mem 0xd9f00000-0xd9ffffff]
[ 4168.413147] pci_bus 0000:06: Allocating resources
[ 4168.413253] pci 0000:06:01.0: bridge window [io  0x1000-0x0fff] to [bus 08-3c] add_size 1000
[ 4168.413302] pci 0000:06:01.0: res[13]=[io  0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000
[ 4168.413304] pci 0000:05:00.0: bridge window [io  0x1000-0x0fff] to [bus 06-3d] add_size 1000
[ 4168.413307] pci 0000:05:00.0: res[13]=[io  0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000
[ 4168.413309] pci 0000:05:00.0: res[13]=[io  0x1000-0x1fff] res_to_dev_res add_size 1000 min_align 1000
[ 4168.413312] pci 0000:05:00.0: BAR 13: assigned [io  0x2000-0x2fff]
[ 4168.413315] pci 0000:06:01.0: res[13]=[io  0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000
[ 4168.413316] pci 0000:06:01.0: res[13]=[io  0x1000-0x1fff] res_to_dev_res add_size 1000 min_align 1000
[ 4168.413318] pci 0000:06:01.0: BAR 13: assigned [io  0x2000-0x2fff]
[ 4168.413321] pci 0000:06:00.0: PCI bridge to [bus 07]
[ 4168.413342] pci 0000:06:00.0:   bridge window [mem 0xda000000-0xda0fffff]
[ 4168.413371] pci 0000:06:01.0: PCI bridge to [bus 08-3c]
[ 4168.413379] pci 0000:06:01.0:   bridge window [io  0x2000-0x2fff]
[ 4168.413396] pci 0000:06:01.0:   bridge window [mem 0xc4000000-0xd9efffff]
[ 4168.413404] pci 0000:06:01.0:   bridge window [mem 0x80000000-0xa1ffffff 64bit pref]
[ 4168.413423] pci 0000:06:02.0: PCI bridge to [bus 3d]
[ 4168.413437] pci 0000:06:02.0:   bridge window [mem 0xd9f00000-0xd9ffffff]
[ 4168.413465] pci 0000:05:00.0: PCI bridge to [bus 06-3d]
[ 4168.413471] pci 0000:05:00.0:   bridge window [io  0x2000-0x2fff]
[ 4168.413483] pci 0000:05:00.0:   bridge window [mem 0xc4000000-0xda0fffff]
[ 4168.413492] pci 0000:05:00.0:   bridge window [mem 0x80000000-0xa1ffffff 64bit pref]
[ 4168.413641] pcieport 0000:05:00.0: enabling device (0006 -> 0007)
[ 4168.414446] pcieport 0000:06:01.0: enabling device (0006 -> 0007)
[ 4168.415718] xhci_hcd 0000:3d:00.0: xHCI Host Controller
[ 4168.415726] xhci_hcd 0000:3d:00.0: new USB bus registered, assigned bus number 3
[ 4168.417308] xhci_hcd 0000:3d:00.0: hcc params 0x200077c1 hci version 0x110 quirks 0x00009810
[ 4168.417553] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[ 4168.417555] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4168.417557] usb usb3: Product: xHCI Host Controller
[ 4168.417558] usb usb3: Manufacturer: Linux 4.6.0-rc7-GTW2+ xhci-hcd
[ 4168.417559] usb usb3: SerialNumber: 0000:3d:00.0
[ 4168.417690] hub 3-0:1.0: USB hub found
[ 4168.417718] hub 3-0:1.0: 2 ports detected
[ 4168.417822] xhci_hcd 0000:3d:00.0: xHCI Host Controller
[ 4168.417825] xhci_hcd 0000:3d:00.0: new USB bus registered, assigned bus number 4
[ 4168.417872] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[ 4168.417874] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4168.417875] usb usb4: Product: xHCI Host Controller
[ 4168.417876] usb usb4: Manufacturer: Linux 4.6.0-rc7-GTW2+ xhci-hcd
[ 4168.417877] usb usb4: SerialNumber: 0000:3d:00.0
[ 4168.418001] hub 4-0:1.0: USB hub found
[ 4168.418028] hub 4-0:1.0: 2 ports detected
[ 4168.757410] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 4168.774479] usb 4-1: New USB device found, idVendor=0bda, idProduct=8153
[ 4168.774488] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 4168.774492] usb 4-1: Product: USB 10/100/1000 LAN
[ 4168.774496] usb 4-1: Manufacturer: Realtek
[ 4168.774499] usb 4-1: SerialNumber: 000001000000
[ 4168.889936] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd
[ 4168.939303] r8152 4-1:1.0 eth0: v1.08.3
[ 4169.464178] r8152 4-1:1.0 enp61s0u1: renamed from eth0
[ 4174.025084] xhci_hcd 0000:3d:00.0: WARN: xHC CMD_RUN timeout
[ 4174.025096] suspend_common(): xhci_pci_suspend+0x0/0xc0 returns -110
[ 4174.025102] xhci_hcd 0000:3d:00.0: can't suspend (hcd_pci_runtime_suspend returned -110)
[ 4174.026267] xhci_hcd 0000:3d:00.0: remove, state 4
[ 4174.026275] usb usb4: USB disconnect, device number 1
[ 4174.026278] usb 4-1: USB disconnect, device number 2
[ 4174.109421] xhci_hcd 0000:3d:00.0: Host not halted after 16000 microseconds.
[ 4174.110587] xhci_hcd 0000:3d:00.0: USB bus 4 deregistered
[ 4174.110600] xhci_hcd 0000:3d:00.0: remove, state 4
[ 4174.110611] usb usb3: USB disconnect, device number 1
[ 4174.110910] xhci_hcd 0000:3d:00.0: USB bus 3 deregistered
[ 4174.112107] pci_bus 0000:07: busn_res: [bus 07] is released
[ 4174.112290] pci_bus 0000:08: busn_res: [bus 08-3c] is released
[ 4174.118559] pci_bus 0000:3d: busn_res: [bus 3d] is released
[ 4174.118675] pci_bus 0000:06: busn_res: [bus 06-3d] is released
[ 4177.857817] wlp2s0: deauthenticating from 46:d9:e7:92:54:00 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 4177.948478] PM: Syncing filesystems ... done.
[ 4177.968706] PM: Preparing system for sleep (mem)
[ 4177.969766] Freezing user space processes ... (elapsed 0.007 seconds) done.
[ 4177.977154] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 4177.978345] PM: Suspending system (mem)
[ 4177.978363] Suspending console(s) (use no_console_suspend to debug)
[ 4178.307945] PM: suspend of devices complete after 329.429 msecs
[ 4178.321204] PM: late suspend of devices complete after 13.252 msecs
[ 4178.323425] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 4178.338113] PM: noirq suspend of devices complete after 16.904 msecs
[ 4178.339100] ACPI: Preparing to enter system sleep state S3
[ 4178.361380] ACPI : EC: EC stopped
[ 4178.361382] PM: Saving platform NVS memory
[ 4178.361398] Disabling non-boot CPUs ...
[ 4178.363880] smpboot: CPU 1 is now offline
[ 4178.375600] smpboot: CPU 2 is now offline
[ 4178.415622] smpboot: CPU 3 is now offline
[ 4178.440476] smpboot: CPU 4 is now offline
[ 4178.455339] smpboot: CPU 5 is now offline
[ 4178.479169] smpboot: CPU 6 is now offline
[ 4178.503064] smpboot: CPU 7 is now offline
[ 4178.516659] ACPI: Low-level resume complete
[ 4178.516758] ACPI : EC: EC started
[ 4178.516759] PM: Restoring platform NVS memory
[ 4178.517558] Enabling non-boot CPUs ...
[ 4178.537004] x86: Booting SMP configuration:
[ 4178.537005] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 4178.539536]  cache: parent cpu1 should not be sleeping
[ 4178.539629] CPU1 is up
[ 4178.557259] smpboot: Booting Node 0 Processor 2 APIC 0x4
[ 4178.560246]  cache: parent cpu2 should not be sleeping
[ 4178.560405] CPU2 is up
[ 4178.577368] smpboot: Booting Node 0 Processor 3 APIC 0x6
[ 4178.580535]  cache: parent cpu3 should not be sleeping
[ 4178.580702] CPU3 is up
[ 4178.593437] smpboot: Booting Node 0 Processor 4 APIC 0x1
[ 4178.596504]  cache: parent cpu4 should not be sleeping
[ 4178.596670] CPU4 is up
[ 4178.625494] smpboot: Booting Node 0 Processor 5 APIC 0x3
[ 4178.628574]  cache: parent cpu5 should not be sleeping
[ 4178.628736] CPU5 is up
[ 4178.657499] smpboot: Booting Node 0 Processor 6 APIC 0x5
[ 4178.660617]  cache: parent cpu6 should not be sleeping
[ 4178.660774] CPU6 is up
[ 4178.677671] smpboot: Booting Node 0 Processor 7 APIC 0x7
[ 4178.680993]  cache: parent cpu7 should not be sleeping
[ 4178.681179] CPU7 is up
[ 4178.700393] ACPI: Waking up from system sleep state S3
[ 4178.709282] ACPI Error: [\_SB_.PCI0.SAT0.TFGF] Namespace lookup failure, AE_NOT_FOUND (20160108/psargs-359)
[ 4178.709290] ACPI Error: Method parse/execution failed [\RWAK] (Node ffff88089d0de258), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.709297] ACPI Error: Method parse/execution failed [\_WAK] (Node ffff88089d0cfbb8), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.710632] acpi LNXPOWER:1b: Turning OFF
[ 4178.717004] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160108/psargs-359)
[ 4178.717010] ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff88089d119ed8), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.717018] ACPI Error: Method parse/execution failed [\_TZ.FN04._OFF] (Node ffff88089d119e10), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.717052] acpi LNXPOWER:1a: Turning OFF
[ 4178.724993] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160108/psargs-359)
[ 4178.724998] ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff88089d119ed8), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.725005] ACPI Error: Method parse/execution failed [\_TZ.FN03._OFF] (Node ffff88089d119cd0), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.725039] acpi LNXPOWER:19: Turning OFF
[ 4178.732993] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160108/psargs-359)
[ 4178.732997] ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff88089d119ed8), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.733004] ACPI Error: Method parse/execution failed [\_TZ.FN02._OFF] (Node ffff88089d119b90), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.733037] acpi LNXPOWER:18: Turning OFF
[ 4178.740990] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160108/psargs-359)
[ 4178.740995] ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff88089d119ed8), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.741002] ACPI Error: Method parse/execution failed [\_TZ.FN01._OFF] (Node ffff88089d119a50), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.741034] acpi LNXPOWER:17: Turning OFF
[ 4178.748991] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECAV] Namespace lookup failure, AE_NOT_FOUND (20160108/psargs-359)
[ 4178.748996] ACPI Error: Method parse/execution failed [\_TZ.FNCL] (Node ffff88089d119ed8), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.749003] ACPI Error: Method parse/execution failed [\_TZ.FN00._OFF] (Node ffff88089d119910), AE_NOT_FOUND (20160108/psparse-542)
[ 4178.751084] pci 0000:01:00.0: Refused to change power state, currently in D3
[ 4178.751923] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 4178.765929] PM: noirq resume of devices complete after 15.644 msecs
[ 4178.773213] PM: early resume of devices complete after 7.236 msecs
[ 4178.847135] rtc_cmos 00:02: System wakeup disabled by ACPI
[ 4179.338952] PM: resume of devices complete after 565.735 msecs
[ 4179.339612] PM: Finishing wakeup.
[ 4179.339615] Restarting tasks ... done.
[ 4179.933151] [drm] RC6 on
[ 4179.946780] thermal thermal_zone10: failed to read out thermal zone (-5)
[ 4180.172456] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 4180.173131] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 4180.303376] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 4180.303670] iwlwifi 0000:02:00.0: L1 Enabled - LTR Disabled
[ 4180.314174] psmouse serio1: synaptics: queried max coordinates: x [..5664], y [..4646]
[ 4180.350500] psmouse serio1: synaptics: queried min coordinates: x [1278..], y [1206..]
[ 4183.719520] wlp2s0: authenticate with 46:d9:e7:92:54:00
[ 4183.725054] wlp2s0: send auth to 46:d9:e7:92:54:00 (try 1/3)
[ 4183.730232] wlp2s0: authenticated
[ 4183.732786] wlp2s0: associate with 46:d9:e7:92:54:00 (try 1/3)
[ 4183.734092] wlp2s0: RX AssocResp from 46:d9:e7:92:54:00 (capab=0x411 status=0 aid=6)
[ 4183.735930] wlp2s0: associated
Comment 49 Greg White 2016-05-12 21:00:35 UTC
That's 4.6.0-rc7+, from today.
Comment 50 Ivan Koptiev 2016-05-12 21:03:45 UTC
(In reply to Mario Limonciello from comment #47)
> @Greg
> Are you sure about that?  I just tested on an XPS 9350 4.4 kernel with that
> patch backported on top of it.
> 
> WD15 Type-C dock.  Booted with it plugged, in saw everything in lsusb.
> Suspended, resumed, all still there.
> Hotplugged, took about 30 seconds for everything to show up, but it did
> again.

WD15 is not Thunderbolt 3. It's using DisplayPort over USB Type C.
Comment 51 Mario Limonciello 2016-05-12 21:05:02 UTC
Ah that's right.  I'll grab my TB15 and double check there too.
Comment 52 Prarit Bhargava 2016-05-12 22:52:12 UTC
(In reply to Jack Coulter from comment #39)
> @Prarit: It didn't work at all (even hotplugged after an initial cold boot)
> without the patch, hence me logging this bug in the first place.
> 
> The patch allows hotplug to work if the device is connected to the system
> after a _cold_ boot. It does not however, solve the issue of the device not
> being detected when it is connected to the system when the system has been
> suspended & resumed at least once.

Okay, a few questions here:

1.  What device are you using?  The TB15 dock is known not to be functional yet.

2.  This sounds like a separate issue from the initial connection issue.  What you're reporting is a failure with suspend resume.

P.
Comment 53 Richard van der Hoff 2016-08-23 22:04:25 UTC
I'm a bit confused about the status of this bug. Is it considered fixed? The patch mentioned at comment #25 seems to have fixed the problem for a lot of people, and the patch has landed in 4.7.

On the other hand, I'm seeing similar problems with a usb 3.1 dock (it is correctly detected at startup, but is not detected after a hotplug). I assumed, not being thunderbolt, that it was unrelated, so reported it at https://bugzilla.kernel.org/show_bug.cgi?id=151261, but is there a more general problem with support of the Alpine Ridge PCI devices?
Comment 54 Don Zickus 2016-08-24 17:34:51 UTC
Hi Richard,

I have been using a Dell 7510 with the TB15 dock station (which connects via a Thunderbolt cable).  Ever since Dell's July Bios update and a 4.7 kernel, hotplug and suspend/resume have worked very well for me.  I get the occasional missed hotplug event.  Not sure if that is a BIOS or kernel issue but an extra unplug/replug every 20th hotplug or so isn't so bad.

Cheers,
Don
Comment 55 Richard van der Hoff 2016-08-25 12:24:34 UTC
yes; my impression is that this problem is fixed. It turns out I was suffering a separate PEBKAC issue.
Comment 56 Sampo 2016-12-13 14:41:53 UTC
Hi everyone,

I'm still running into this issue on kernel 4.8.0-30 (Ubuntu)

To be more specific I have Dell Precision 5510 (mostly same as XPS15 9550) and two different USB-C devices with mostly similar problems.

The first device is Dell DA200 USB-C dongle that has gigabit LAN, HDMI, VGA and one USB3 port. The dongle (expect the HDMI) and hot-plug work fine but after sleep/resume only the VGA works. lsusb does not show anything to be detected. That problem seems to be precisely the same as described here. If the dongle has been attached at any point of time the OS will hang on the shutdown. At least I cannot find anything too useful from the logs.

Then I have Dell WD15 USB-C dock. The hot plugging here works fine too but same story after seelp/resume cycle. Only DisplayPort on the dock works. Here is also a dangerous point: if I close the lid while the dock is plugged into the USB-C and unrecognized (besides the DisplayPort) the whole OS will hang and the computer starts to get hot. If I leave it at this state it will probably continue to damage itself as it got to ~60C before I noticed it. I did that because I couldn't bother to restart the computer because the DisplayPort was enough for me that day.  

Also there is this. If I first do sleep/resume cycle and then plug in the USB-C dock and then try to shutdown the computer I will get kernel panic. Nothing too interesting can be found from the logs at this point and the kernel panic is pointing to somewhere around acpi. Here is picture of the panic but I probably need to report it somewhere else: https://goo.gl/photos/2MKaVYxnocyUWHrk6


So should this be fixed in the 4.8.0-30 and if this is deemed as a regression, how to I proceed with this?
Comment 57 Don Zickus 2016-12-13 15:19:27 UTC
Hi Sampo,

I have the same laptop running a Fedora 4.8 kernel with pretty good results.  Occassionally a hotplug event is missed and I have to retry a couple of times.

Do you have the latest BIOS update from June this year?  That fixed a whole bunch of issues for me.  The WD15 dock is junk and is being recalled in a month or two, but the laptop works fine for me.

Cheers,
Don
Comment 58 Sampo 2016-12-13 15:48:30 UTC
Hi Don,

I have the latest BIOS (or UEFI or what ever it is called nowadays). I got this machine from Dell just month a go and verified that I'm running the current BIOS.

I thought that the WD15 was better than the TB15?

Everything else is working like a charm but the sleep/resume cycle seems to play havoc with this thing. Event the WD15 works with a clean boot.

Brgs,
Sampo
Comment 59 Mario Limonciello 2016-12-13 15:54:38 UTC
To avoid misinformation being spread on this issue:

The WD15 is the *non* Thunderbolt Dell dock. It's the smaller dock.
The TB15 is the thunderbolt Dell dock.  Comparatively it's a "fatter" dock.


I believe this particular issue should actually be closed now.
This issue was that TBT hotplug wasn't working, which was actually a BIOS problem with Thunderbolt security settings on the Dell system in question.

Thunderbolt security levels above "no security" are not yet supported on Linux.  So anyone who has the OP's issue of TBT hotplug not working needs to update their BIOS and set the BIOS to "No Security" for TBT hotplug.


Intel will be supporting other security levels later.
Comment 60 Don Zickus 2016-12-13 15:58:55 UTC
Hi Sampo,

Ah yes, I meant TB15.  I don't know about the WD15.  Sorry for the misinformation. :-(

Cheers,
Don
Comment 61 Mario Limonciello 2016-12-13 16:01:37 UTC
No worry.  I should have also added @Sampo - you should file a separate issue for your bug.  Feel free to reference this bug though.
As @Don Zickus said, please make sure you update to the latest BIOS, as there are definitely firmware related pieces of code that are affected here.
Comment 62 Sampo 2016-12-13 16:03:46 UTC
Thanks @Mario

I'll file a separate bug but first I try to see if the BIOS setting helps me. It seems to me that someone tried it but reported it not working. 

Also I probably should go on to file the Kernel panic anyways because what ever happens, that should not.

Regards,
Sampo
Comment 63 Sampo 2016-12-13 16:13:30 UTC
Ok,

Thanks @Mario!

The BIOS setting really made it work. I have Googled this issue like 1000+ times and thought about reporting this and then again tries to find people with same problems but I did something wrong (obviously) for not finding the solution. Also I have called Dell like 10 times to Pro Support and nobody there was aware of the BIOS setting. 

Really really much thanks, I'll report the Panic next time I'm on my dock and if I still manage to reproduce it.

Brgs.
Sampo

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