Bug 115121

Created attachment 210201 [details]
lspci -vv when device is hotplugged

Created attachment 210211 [details]
lspci -vv when device is present at boot

Created attachment 210221 [details]
dmesg when device is present at boot

Created attachment 210231 [details]
dmesg when device is hotplugged

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.

Also please attach acpidump of that machine.

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

Created attachment 210541 [details]
acpidump

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 

Also, I attached the acpidump as requested

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

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.

@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.

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?

@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.

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.

Ok, good to know that it works in Windows. Can you check /proc/interrupts if the "acpi" entry increases when you do hotplug?

No change in the 'acpi' line of /proc/interrupts after connecting the device, unfortunately.

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".

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.

I checked in the BIOS on my machine and the Thunderbolt security mode is currently set to "Security level - No security".

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.

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.

Interestingly, on 4.5.0 suspending and resuming does _not_ result in the device being recognised.

Everyone, please try 

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

and let us know if it works.

Thanks,

P.

Currently compiling a kernel with the above patch. Will report back with results when I've had a chance to try it.

I can confirm the patch http://marc.info/?l=linux-acpi&m=145929159015853&w=2 solves the issue.

Seconding that - I can confirm that applying the above patch on 4.5.0 now allows hotplug to work

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

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.

(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.

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.

@Jarod You're absolutely right. It's only the pci bridges. It seems the dock is still only detected when plugged in at boot.

(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.

(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.

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.

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.

(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.

@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.

Hi,

Could the following boot parameter work for you guys:
acpi_no_auto_serialize

Thanks and best regards
-Lv

(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.

(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.

(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

(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.

OK, we'll about to merge the patch via ACPICA upstream.

Thanks
-Lv

"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.

@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.

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

That's 4.6.0-rc7+, from today.

(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.

Ah that's right.  I'll grab my TB15 and double check there too.

(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.

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?

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

yes; my impression is that this problem is fixed. It turns out I was suffering a separate PEBKAC issue.

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?

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

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

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.

Hi Sampo,

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

Cheers,
Don

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.

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

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