Titan Ridge xHCI may stop to working after re-plugging the dock

Titan Ridge xHCI may stop to working after re-plugging the dock

[Kai-Heng Feng]

Hi Mika and Mathias,

I’ve filed a bug [1] which renders docking station unusable.

I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue to  
you both.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=203885

Kai-Heng

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Oliver Neukum]

Am Dienstag, den 09.07.2019, 21:10 +0800 schrieb Kai-Heng Feng:
> Hi Mika and Mathias,
> 
> I’ve filed a bug [1] which renders docking station unusable.
> 
> I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue to  
> you both.
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=203885
> 
> Kai-Heng
> 

The issue starts before you unplug. In fact it starts before
the dock is even detected the first time:

[   13.171167] rfkill: input handler disabled
[   19.781905] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
[   19.781909] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
[   20.109251] usb 4-1: new SuperSpeedPlus Gen 2 USB device number 2 using xhci_hcd
[   20.136000] usb 4-1: New USB device found, idVendor=0bda, idProduct=0487, bcdDevice= 1.47
[   20.136004] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   20.136007] usb 4-1: Product: Dell dock
[   20.136009] usb 4-1: Manufacturer: Dell Inc.
[   20.140607] hub 4-1:1.0: USB hub found
[   20.141004] hub 4-1:1.0: 4 ports detected
[   20.253025] usb 1-4: new high-speed USB device number 5 using xhci_hcd
[   20.403520] usb 1-4: New USB device found, idVendor=0bda, idProduct=5487, bcdDevice= 1.47
[   20.403521] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   20.403522] usb 1-4: Product: Dell dock
[   20.403522] usb 1-4: Manufacturer: Dell Inc.
[   20.404348] hub 1-4:1.0: USB hub found

This looks like a PCI issue.
In general, this kind of reporting sucks. We have to guess what you did at 19.781905

	Regards
		Oliver

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]


Hi,

Oliver Neukum <oneukum@suse.com> writes:
> Am Dienstag, den 09.07.2019, 21:10 +0800 schrieb Kai-Heng Feng:
>> Hi Mika and Mathias,
>> 
>> I’ve filed a bug [1] which renders docking station unusable.
>> 
>> I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue to  
>> you both.
>> 
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=203885
>> 
>> Kai-Heng
>> 
>
> The issue starts before you unplug. In fact it starts before
> the dock is even detected the first time:
>
> [   13.171167] rfkill: input handler disabled
> [   19.781905] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
> [   19.781909] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
> [   20.109251] usb 4-1: new SuperSpeedPlus Gen 2 USB device number 2 using xhci_hcd
> [   20.136000] usb 4-1: New USB device found, idVendor=0bda, idProduct=0487, bcdDevice= 1.47
> [   20.136004] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [   20.136007] usb 4-1: Product: Dell dock
> [   20.136009] usb 4-1: Manufacturer: Dell Inc.
> [   20.140607] hub 4-1:1.0: USB hub found
> [   20.141004] hub 4-1:1.0: 4 ports detected
> [   20.253025] usb 1-4: new high-speed USB device number 5 using xhci_hcd
> [   20.403520] usb 1-4: New USB device found, idVendor=0bda, idProduct=5487, bcdDevice= 1.47
> [   20.403521] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [   20.403522] usb 1-4: Product: Dell dock
> [   20.403522] usb 1-4: Manufacturer: Dell Inc.
> [   20.404348] hub 1-4:1.0: USB hub found
>
> This looks like a PCI issue.
> In general, this kind of reporting sucks. We have to guess what you did at 19.781905

It might be nice to know which device is generating that and why it's
not found. This may help:

diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index f38e6c19dd50..33285ef29362 100644
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -203,7 +203,7 @@ static void pcie_pme_handle_request(struct pci_dev *port, u16 req_id)
 
  out:
 	if (!found)
-		pci_info(port, "Spurious native interrupt!\n");
+		pci_info(port, "Spurious native interrupt! (Bus# %d DevFn %d)\n", busnr, devfn);
 }
 
 /**


Also, according to what Kai-Heng said, xHCI stops working even after
repluggin the Dock. We could be dealing with two bugs here:

1. Spurious PME event being generated by an unexistent device
2. xHCI not handling hot-plug very well

Kai-Heng,

please run your tests again and make note of when you unplugged the dock
and when you replugged it so we can correlate the time stampts with what
you have done otherwise we will never be able to pin-point what's going
on.

cheers

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Kai Heng Feng]

Hi Felipe,

at 3:23 PM, Felipe Balbi <felipe.balbi@linux.intel.com> wrote:

>
> Hi,
>
> Oliver Neukum <oneukum@suse.com> writes:
>> Am Dienstag, den 09.07.2019, 21:10 +0800 schrieb Kai-Heng Feng:
>>> Hi Mika and Mathias,
>>>
>>> I’ve filed a bug [1] which renders docking station unusable.
>>>
>>> I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue  
>>> to
>>> you both.
>>>
>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=203885
>>>
>>> Kai-Heng
>>
>> The issue starts before you unplug. In fact it starts before
>> the dock is even detected the first time:
>>
>> [   13.171167] rfkill: input handler disabled
>> [   19.781905] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
>> [   19.781909] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
>> [   20.109251] usb 4-1: new SuperSpeedPlus Gen 2 USB device number 2  
>> using xhci_hcd
>> [   20.136000] usb 4-1: New USB device found, idVendor=0bda,  
>> idProduct=0487, bcdDevice= 1.47
>> [   20.136004] usb 4-1: New USB device strings: Mfr=1, Product=2,  
>> SerialNumber=0
>> [   20.136007] usb 4-1: Product: Dell dock
>> [   20.136009] usb 4-1: Manufacturer: Dell Inc.
>> [   20.140607] hub 4-1:1.0: USB hub found
>> [   20.141004] hub 4-1:1.0: 4 ports detected
>> [   20.253025] usb 1-4: new high-speed USB device number 5 using xhci_hcd
>> [   20.403520] usb 1-4: New USB device found, idVendor=0bda,  
>> idProduct=5487, bcdDevice= 1.47
>> [   20.403521] usb 1-4: New USB device strings: Mfr=1, Product=2,  
>> SerialNumber=0
>> [   20.403522] usb 1-4: Product: Dell dock
>> [   20.403522] usb 1-4: Manufacturer: Dell Inc.
>> [   20.404348] hub 1-4:1.0: USB hub found
>>
>> This looks like a PCI issue.
>> In general, this kind of reporting sucks. We have to guess what you did  
>> at 19.781905
>
> It might be nice to know which device is generating that and why it's
> not found. This may help:
>
> diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
> index f38e6c19dd50..33285ef29362 100644
> --- a/drivers/pci/pcie/pme.c
> +++ b/drivers/pci/pcie/pme.c
> @@ -203,7 +203,7 @@ static void pcie_pme_handle_request(struct pci_dev  
> *port, u16 req_id)
>
>   out:
>  	if (!found)
> -		pci_info(port, "Spurious native interrupt!\n");
> +		pci_info(port, "Spurious native interrupt! (Bus# %d DevFn  
> %d)\n", busnr, devfn);
>  }
>
>  /**
>
>
> Also, according to what Kai-Heng said, xHCI stops working even after
> repluggin the Dock. We could be dealing with two bugs here:
>
> 1. Spurious PME event being generated by an unexistent device
> 2. xHCI not handling hot-plug very well
>
> Kai-Heng,
>
> please run your tests again and make note of when you unplugged the dock
> and when you replugged it so we can correlate the time stampts with what
> you have done otherwise we will never be able to pin-point what's going
> on.

I upgraded the system firmware, TBT firmware and docking station firmware  
to latest, and used latest mainline kernel.
Now the issue can be reproduced at the very first time I plugged the  
docking station.

Attach dmesg to BKO since there are lots of message after XHCI dyndbg is  
enabled.

Kai-Heng

>
> cheers
>
> -- 
> balbi

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3827 bytes --]


Hi,

Kai Heng Feng <kai.heng.feng@canonical.com> writes:
>> Oliver Neukum <oneukum@suse.com> writes:
>>> Am Dienstag, den 09.07.2019, 21:10 +0800 schrieb Kai-Heng Feng:
>>>> Hi Mika and Mathias,
>>>>
>>>> I’ve filed a bug [1] which renders docking station unusable.
>>>>
>>>> I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue  
>>>> to
>>>> you both.
>>>>
>>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=203885
>>>>
>>>> Kai-Heng
>>>
>>> The issue starts before you unplug. In fact it starts before
>>> the dock is even detected the first time:
>>>
>>> [   13.171167] rfkill: input handler disabled
>>> [   19.781905] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
>>> [   19.781909] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
>>> [   20.109251] usb 4-1: new SuperSpeedPlus Gen 2 USB device number 2  
>>> using xhci_hcd
>>> [   20.136000] usb 4-1: New USB device found, idVendor=0bda,  
>>> idProduct=0487, bcdDevice= 1.47
>>> [   20.136004] usb 4-1: New USB device strings: Mfr=1, Product=2,  
>>> SerialNumber=0
>>> [   20.136007] usb 4-1: Product: Dell dock
>>> [   20.136009] usb 4-1: Manufacturer: Dell Inc.
>>> [   20.140607] hub 4-1:1.0: USB hub found
>>> [   20.141004] hub 4-1:1.0: 4 ports detected
>>> [   20.253025] usb 1-4: new high-speed USB device number 5 using xhci_hcd
>>> [   20.403520] usb 1-4: New USB device found, idVendor=0bda,  
>>> idProduct=5487, bcdDevice= 1.47
>>> [   20.403521] usb 1-4: New USB device strings: Mfr=1, Product=2,  
>>> SerialNumber=0
>>> [   20.403522] usb 1-4: Product: Dell dock
>>> [   20.403522] usb 1-4: Manufacturer: Dell Inc.
>>> [   20.404348] hub 1-4:1.0: USB hub found
>>>
>>> This looks like a PCI issue.
>>> In general, this kind of reporting sucks. We have to guess what you did  
>>> at 19.781905
>>
>> It might be nice to know which device is generating that and why it's
>> not found. This may help:
>>
>> diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
>> index f38e6c19dd50..33285ef29362 100644
>> --- a/drivers/pci/pcie/pme.c
>> +++ b/drivers/pci/pcie/pme.c
>> @@ -203,7 +203,7 @@ static void pcie_pme_handle_request(struct pci_dev  
>> *port, u16 req_id)
>>
>>   out:
>>  	if (!found)
>> -		pci_info(port, "Spurious native interrupt!\n");
>> +		pci_info(port, "Spurious native interrupt! (Bus# %d DevFn  
>> %d)\n", busnr, devfn);
>>  }
>>
>>  /**
>>
>>
>> Also, according to what Kai-Heng said, xHCI stops working even after
>> repluggin the Dock. We could be dealing with two bugs here:
>>
>> 1. Spurious PME event being generated by an unexistent device
>> 2. xHCI not handling hot-plug very well
>>
>> Kai-Heng,
>>
>> please run your tests again and make note of when you unplugged the dock
>> and when you replugged it so we can correlate the time stampts with what
>> you have done otherwise we will never be able to pin-point what's going
>> on.
>
> I upgraded the system firmware, TBT firmware and docking station firmware  
> to latest, and used latest mainline kernel.
> Now the issue can be reproduced at the very first time I plugged the  
> docking station.
>
> Attach dmesg to BKO since there are lots of message after XHCI dyndbg is  
> enabled.

I saw that you annotated the plug, but not the unplug. Where does the
unplug start? There are many places where it could be, but I need to be
sure.

Also, wasn't it so that the problem is when you *replug* the dock? So
can you better describe what you're doing? Are you booting with dock
connected then disconnect and reconnect or are you booting without dock
and it fails on first plug?

What are you consider a fail here? Can't you see the xhci bus? USB
Devices don't show? What do you have on lsusb -t?

Best regards

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Kai-Heng Feng]

Hi Felipe,

at 18:51, Felipe Balbi <felipe.balbi@linux.intel.com> wrote:

>
> Hi,
>
> Kai Heng Feng <kai.heng.feng@canonical.com> writes:
>>> Oliver Neukum <oneukum@suse.com> writes:
>>>> Am Dienstag, den 09.07.2019, 21:10 +0800 schrieb Kai-Heng Feng:
>>>>> Hi Mika and Mathias,
>>>>>
>>>>> I’ve filed a bug [1] which renders docking station unusable.
>>>>>
>>>>> I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue
>>>>> to
>>>>> you both.
>>>>>
>>>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=203885
>>>>>
>>>>> Kai-Heng
>>>>
>>>> The issue starts before you unplug. In fact it starts before
>>>> the dock is even detected the first time:
>>>>
>>>> [   13.171167] rfkill: input handler disabled
>>>> [   19.781905] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
>>>> [   19.781909] pcieport 0000:00:1c.0: PME: Spurious native interrupt!
>>>> [   20.109251] usb 4-1: new SuperSpeedPlus Gen 2 USB device number 2
>>>> using xhci_hcd
>>>> [   20.136000] usb 4-1: New USB device found, idVendor=0bda,
>>>> idProduct=0487, bcdDevice= 1.47
>>>> [   20.136004] usb 4-1: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=0
>>>> [   20.136007] usb 4-1: Product: Dell dock
>>>> [   20.136009] usb 4-1: Manufacturer: Dell Inc.
>>>> [   20.140607] hub 4-1:1.0: USB hub found
>>>> [   20.141004] hub 4-1:1.0: 4 ports detected
>>>> [   20.253025] usb 1-4: new high-speed USB device number 5 using  
>>>> xhci_hcd
>>>> [   20.403520] usb 1-4: New USB device found, idVendor=0bda,
>>>> idProduct=5487, bcdDevice= 1.47
>>>> [   20.403521] usb 1-4: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=0
>>>> [   20.403522] usb 1-4: Product: Dell dock
>>>> [   20.403522] usb 1-4: Manufacturer: Dell Inc.
>>>> [   20.404348] hub 1-4:1.0: USB hub found
>>>>
>>>> This looks like a PCI issue.
>>>> In general, this kind of reporting sucks. We have to guess what you did
>>>> at 19.781905
>>>
>>> It might be nice to know which device is generating that and why it's
>>> not found. This may help:
>>>
>>> diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
>>> index f38e6c19dd50..33285ef29362 100644
>>> --- a/drivers/pci/pcie/pme.c
>>> +++ b/drivers/pci/pcie/pme.c
>>> @@ -203,7 +203,7 @@ static void pcie_pme_handle_request(struct pci_dev
>>> *port, u16 req_id)
>>>
>>>   out:
>>>  	if (!found)
>>> -		pci_info(port, "Spurious native interrupt!\n");
>>> +		pci_info(port, "Spurious native interrupt! (Bus# %d DevFn
>>> %d)\n", busnr, devfn);
>>>  }
>>>
>>>  /**
>>>
>>>
>>> Also, according to what Kai-Heng said, xHCI stops working even after
>>> repluggin the Dock. We could be dealing with two bugs here:
>>>
>>> 1. Spurious PME event being generated by an unexistent device
>>> 2. xHCI not handling hot-plug very well
>>>
>>> Kai-Heng,
>>>
>>> please run your tests again and make note of when you unplugged the dock
>>> and when you replugged it so we can correlate the time stampts with what
>>> you have done otherwise we will never be able to pin-point what's going
>>> on.
>>
>> I upgraded the system firmware, TBT firmware and docking station firmware
>> to latest, and used latest mainline kernel.
>> Now the issue can be reproduced at the very first time I plugged the
>> docking station.
>>
>> Attach dmesg to BKO since there are lots of message after XHCI dyndbg is
>> enabled.
>
> I saw that you annotated the plug, but not the unplug. Where does the
> unplug start? There are many places where it could be, but I need to be
> sure.

Request log attached to Bugzilla.

>
> Also, wasn't it so that the problem is when you *replug* the dock? So
> can you better describe what you're doing? Are you booting with dock
> connected then disconnect and reconnect or are you booting without dock
> and it fails on first plug?

The weird behavior I described in my previous replay is because the devices  
need to be fully power cycled after firmware upgrade.
So it’s false alarm.

The only issue now is the original bug.

>
> What are you consider a fail here? Can't you see the xhci bus? USB
> Devices don't show? What do you have on lsusb -t?

The 0000:39:00.0 xHCI stops working, so the USB ethernet (r8152) connects  
to it doesn’t work anymore.

Normal case:
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
         |__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
         |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
     |__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
         |__ Port 5: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 480M
         |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/6p, 480M
             |__ Port 4: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 480M
             |__ Port 4: Dev 7, If 3, Class=Audio, Driver=snd-usb-audio, 480M
             |__ Port 4: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 480M
             |__ Port 4: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 480M
             |__ Port 5: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 480M
     |__ Port 9: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
     |__ Port 10: Dev 5, If 2, Class=Chip/SmartCard, Driver=, 480M
     |__ Port 10: Dev 5, If 0, Class=Application Specific Interface, Driver=, 480M
     |__ Port 10: Dev 5, If 3, Class=Vendor Specific Class, Driver=, 480M
     |__ Port 10: Dev 5, If 1, Class=Chip/SmartCard, Driver=, 480M
     |__ Port 11: Dev 8, If 0, Class=Video, Driver=uvcvideo, 480M
     |__ Port 11: Dev 8, If 1, Class=Video, Driver=uvcvideo, 480M
     |__ Port 14: Dev 10, If 0, Class=Wireless, Driver=btusb, 12M
     |__ Port 14: Dev 10, If 1, Class=Wireless, Driver=btusb, 12M

Once the issue occurs:
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
     |__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
         |__ Port 5: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 480M
         |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/6p, 480M
             |__ Port 4: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 480M
             |__ Port 4: Dev 7, If 3, Class=Audio, Driver=snd-usb-audio, 480M
             |__ Port 4: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 480M
             |__ Port 4: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 480M
             |__ Port 5: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 480M
     |__ Port 9: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
     |__ Port 10: Dev 5, If 2, Class=Chip/SmartCard, Driver=, 480M
     |__ Port 10: Dev 5, If 0, Class=Application Specific Interface, Driver=, 480M
     |__ Port 10: Dev 5, If 3, Class=Vendor Specific Class, Driver=, 480M
     |__ Port 10: Dev 5, If 1, Class=Chip/SmartCard, Driver=, 480M
     |__ Port 11: Dev 8, If 0, Class=Video, Driver=uvcvideo, 480M
     |__ Port 11: Dev 8, If 1, Class=Video, Driver=uvcvideo, 480M
     |__ Port 14: Dev 10, If 0, Class=Wireless, Driver=btusb, 12M
     |__ Port 14: Dev 10, If 1, Class=Wireless, Driver=btusb, 12M

So we don’t have USB ethernet anymore.

Kai-Heng

>
> Best regards
>
> -- 
> balbi

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Mathias Nyman]

On 22.7.2019 12.44, Kai-Heng Feng wrote:
>>>>>> Hi Mika and Mathias,
>>>>>>
>>>>>> I’ve filed a bug [1] which renders docking station unusable.
>>>>>>
>>>>>> I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue
>>>>>> to
>>>>>> you both.
>>>>>>
>>>>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=203885
>>>>>>
>>>>>> Kai-Heng
>>>>>
>>>
>>> I upgraded the system firmware, TBT firmware and docking station firmware
>>> to latest, and used latest mainline kernel.
>>> Now the issue can be reproduced at the very first time I plugged the
>>> docking station.
>>>
> 
> Request log attached to Bugzilla.
> 

After docking station unplug we see Transfer errors from
devices connected to Titan Ridge xHC, driver tries to recover, fails,
usb devices are disconnected.

After this xhci driver runtime suspends xHC controller as runtime pm is allowed
by default for Titan Ridge xHC controllers.

Interesting parts from log:

>>> Unplug Docking Station <<<

[  328.102279] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on endpoint
[  328.118279] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on endpoint
[  328.134291] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on endpoint
[  328.150355] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on endpoint
[  328.166342] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on endpoint
[  332.178710] usb usb4-port2: Cannot enable. Maybe the USB cable is bad?
[  332.178765] usb 4-2: USB disconnect, device number 35
[  332.178769] usb 4-2.3: USB disconnect, device number 36
[  332.179973] usb 4-2.4: USB disconnect, device number 37
[  332.414618] xhci_hcd 0000:39:00.0: set port remote wake mask, actual port 0 status  = 0xe0002a0
[  332.414639] xhci_hcd 0000:39:00.0: set port remote wake mask, actual port 1 status  = 0xe0002b0
[  332.414693] xhci_hcd 0000:39:00.0: xhci_hub_status_data: stopping port polling.
[  332.414703] xhci_hcd 0000:39:00.0: xhci_suspend: stopping port polling.
[  332.414719] xhci_hcd 0000:39:00.0: // Setting command ring address to 0x487da9001

>>> Plug Docking Station <<<

[  346.455568] pci_raw_set_power_state: 25 callbacks suppressed
[  346.455574] xhci_hcd 0000:39:00.0: Refused to change power state, currently in D3
[  346.539451] xhci_hcd 0000:39:00.0: enabling device (0000 -> 0002)
[  346.539482] xhci_hcd 0000:39:00.0: // Setting command ring address to 0x487da903f
[  346.539487] xhci_hcd 0000:39:00.0: WARN: xHC restore state timeout
[  346.539489] xhci_hcd 0000:39:00.0: PCI post-resume error -110!
[  346.539490] xhci_hcd 0000:39:00.0: HC died; cleaning up

>>> We don't have 0000:39:00 anymore <<<

When docking station is plugged back we try to resume Titan Ridge xHC,
PCI log shows that changing power state to D0 failed, xHC is still in D3.
Resume process continues anyway, and xhci driver tries to restore state, but fails.
Usb core will assume HC died if the pci resume callback failed

Does disabling runtime PM for Titan Ridge xHC help?

-Mathias

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Kai-Heng Feng]

at 22:45, Mathias Nyman <mathias.nyman@linux.intel.com> wrote:

> On 22.7.2019 12.44, Kai-Heng Feng wrote:
>>>>>>> Hi Mika and Mathias,
>>>>>>>
>>>>>>> I’ve filed a bug [1] which renders docking station unusable.
>>>>>>>
>>>>>>> I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the  
>>>>>>> issue
>>>>>>> to
>>>>>>> you both.
>>>>>>>
>>>>>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=203885
>>>>>>>
>>>>>>> Kai-Heng
>>>>
>>>> I upgraded the system firmware, TBT firmware and docking station  
>>>> firmware
>>>> to latest, and used latest mainline kernel.
>>>> Now the issue can be reproduced at the very first time I plugged the
>>>> docking station.
>> Request log attached to Bugzilla.
>
> After docking station unplug we see Transfer errors from
> devices connected to Titan Ridge xHC, driver tries to recover, fails,
> usb devices are disconnected.
>
> After this xhci driver runtime suspends xHC controller as runtime pm is  
> allowed
> by default for Titan Ridge xHC controllers.
>
> Interesting parts from log:
>
>>>> Unplug Docking Station <<<
>
> [  328.102279] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on  
> endpoint
> [  328.118279] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on  
> endpoint
> [  328.134291] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on  
> endpoint
> [  328.150355] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on  
> endpoint
> [  328.166342] xhci_hcd 0000:39:00.0: Transfer error for slot 36 ep 6 on  
> endpoint
> [  332.178710] usb usb4-port2: Cannot enable. Maybe the USB cable is bad?
> [  332.178765] usb 4-2: USB disconnect, device number 35
> [  332.178769] usb 4-2.3: USB disconnect, device number 36
> [  332.179973] usb 4-2.4: USB disconnect, device number 37
> [  332.414618] xhci_hcd 0000:39:00.0: set port remote wake mask, actual  
> port 0 status  = 0xe0002a0
> [  332.414639] xhci_hcd 0000:39:00.0: set port remote wake mask, actual  
> port 1 status  = 0xe0002b0
> [  332.414693] xhci_hcd 0000:39:00.0: xhci_hub_status_data: stopping port  
> polling.
> [  332.414703] xhci_hcd 0000:39:00.0: xhci_suspend: stopping port polling.
> [  332.414719] xhci_hcd 0000:39:00.0: // Setting command ring address to  
> 0x487da9001
>
>>>> Plug Docking Station <<<
>
> [  346.455568] pci_raw_set_power_state: 25 callbacks suppressed
> [  346.455574] xhci_hcd 0000:39:00.0: Refused to change power state,  
> currently in D3
> [  346.539451] xhci_hcd 0000:39:00.0: enabling device (0000 -> 0002)
> [  346.539482] xhci_hcd 0000:39:00.0: // Setting command ring address to  
> 0x487da903f
> [  346.539487] xhci_hcd 0000:39:00.0: WARN: xHC restore state timeout
> [  346.539489] xhci_hcd 0000:39:00.0: PCI post-resume error -110!
> [  346.539490] xhci_hcd 0000:39:00.0: HC died; cleaning up
>
>>>> We don't have 0000:39:00 anymore <<<
>
> When docking station is plugged back we try to resume Titan Ridge xHC,
> PCI log shows that changing power state to D0 failed, xHC is still in D3.
> Resume process continues anyway, and xhci driver tries to restore state,  
> but fails.
> Usb core will assume HC died if the pci resume callback failed
>
> Does disabling runtime PM for Titan Ridge xHC help?

Yes, disabling runtime PM can workaround this issue.

Kai-Heng

>
> -Mathias

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Kai-Heng Feng]

Hi Mathias,

at 21:24, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:

> at 22:45, Mathias Nyman <mathias.nyman@linux.intel.com> wrote:

[snipped]

> Yes, disabling runtime PM can workaround this issue.

What’s next step here? Is it a firmware bug?

Kai-Heng

>
> Kai-Heng
>
>> -Mathias

Re: Titan Ridge xHCI may stop to working after re-plugging the dock

[Mathias Nyman]

On 13.8.2019 9.50, Kai-Heng Feng wrote:
> Hi Mathias,
> 
> at 21:24, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> 
>> at 22:45, Mathias Nyman <mathias.nyman@linux.intel.com> wrote:
> 
> [snipped]
> 
>> Yes, disabling runtime PM can workaround this issue.
> 
> What’s next step here? Is it a firmware bug?
> 

Can't say.
 From xhci driver point of view the 39:00.0 xHC controller isn't accessible after dock
is plugged back in. Looks like PCI side has issues getting the controller back to D3
after it was runtime suspended to D0 at dock unplug:

[  346.455568] pci_raw_set_power_state: 25 callbacks suppressed
[  346.455574] xhci_hcd 0000:39:00.0: Refused to change power state, currently in D3

As Mika suggested in the bug take a look at PCI side, especially the PCI status before
a failing dock replug.

-Mathias