Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
* Titan Ridge xHCI may stop to working after re-plugging the dock
@ 2019-07-09 13:10 Kai-Heng Feng
  2019-07-10 11:49 ` Oliver Neukum
  0 siblings, 1 reply; 10+ messages in thread
From: Kai-Heng Feng @ 2019-07-09 13:10 UTC (permalink / raw)
  To: Mika Westerberg, Mathias Nyman; +Cc: Kent Lin, Linux PCI, Linux USB List

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-07-09 13:10 Titan Ridge xHCI may stop to working after re-plugging the dock Kai-Heng Feng
@ 2019-07-10 11:49 ` Oliver Neukum
  2019-07-19  7:23   ` Felipe Balbi
  0 siblings, 1 reply; 10+ messages in thread
From: Oliver Neukum @ 2019-07-10 11:49 UTC (permalink / raw)
  To: Kai-Heng Feng, Mathias Nyman, Mika Westerberg
  Cc: Kent Lin, Linux PCI, Linux USB List

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-07-10 11:49 ` Oliver Neukum
@ 2019-07-19  7:23   ` Felipe Balbi
  2019-07-19 10:29     ` Kai Heng Feng
  0 siblings, 1 reply; 10+ messages in thread
From: Felipe Balbi @ 2019-07-19  7:23 UTC (permalink / raw)
  To: Oliver Neukum, Kai-Heng Feng, Mathias Nyman, Mika Westerberg
  Cc: Kent Lin, Linux PCI, Linux USB List

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-07-19  7:23   ` Felipe Balbi
@ 2019-07-19 10:29     ` Kai Heng Feng
  2019-07-19 10:51       ` Felipe Balbi
  0 siblings, 1 reply; 10+ messages in thread
From: Kai Heng Feng @ 2019-07-19 10:29 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Oliver Neukum, Mathias Nyman, Mika Westerberg, Kent Lin,
	Linux PCI, Linux USB List

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-07-19 10:29     ` Kai Heng Feng
@ 2019-07-19 10:51       ` Felipe Balbi
  2019-07-22  9:44         ` Kai-Heng Feng
  0 siblings, 1 reply; 10+ messages in thread
From: Felipe Balbi @ 2019-07-19 10:51 UTC (permalink / raw)
  To: Kai Heng Feng
  Cc: Oliver Neukum, Mathias Nyman, Mika Westerberg, Kent Lin,
	Linux PCI, Linux USB List

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-07-19 10:51       ` Felipe Balbi
@ 2019-07-22  9:44         ` Kai-Heng Feng
  2019-07-24 14:45           ` Mathias Nyman
  0 siblings, 1 reply; 10+ messages in thread
From: Kai-Heng Feng @ 2019-07-22  9:44 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Oliver Neukum, Mathias Nyman, Mika Westerberg, Kent Lin,
	Linux PCI, Linux USB List

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-07-22  9:44         ` Kai-Heng Feng
@ 2019-07-24 14:45           ` Mathias Nyman
  2019-07-25 13:24             ` Kai-Heng Feng
  0 siblings, 1 reply; 10+ messages in thread
From: Mathias Nyman @ 2019-07-24 14:45 UTC (permalink / raw)
  To: Kai-Heng Feng, Felipe Balbi
  Cc: Oliver Neukum, Mika Westerberg, Kent Lin, Linux PCI, Linux USB List

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-07-24 14:45           ` Mathias Nyman
@ 2019-07-25 13:24             ` Kai-Heng Feng
  2019-08-13  6:50               ` Kai-Heng Feng
  0 siblings, 1 reply; 10+ messages in thread
From: Kai-Heng Feng @ 2019-07-25 13:24 UTC (permalink / raw)
  To: Mathias Nyman
  Cc: Felipe Balbi, Oliver Neukum, Mika Westerberg, Kent Lin,
	Linux PCI, Linux USB List

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-07-25 13:24             ` Kai-Heng Feng
@ 2019-08-13  6:50               ` Kai-Heng Feng
  2019-08-14 13:34                 ` Mathias Nyman
  0 siblings, 1 reply; 10+ messages in thread
From: Kai-Heng Feng @ 2019-08-13  6:50 UTC (permalink / raw)
  To: Mathias Nyman
  Cc: Felipe Balbi, Oliver Neukum, Mika Westerberg, Kent Lin,
	Linux PCI, Linux USB List

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Titan Ridge xHCI may stop to working after re-plugging the dock
  2019-08-13  6:50               ` Kai-Heng Feng
@ 2019-08-14 13:34                 ` Mathias Nyman
  0 siblings, 0 replies; 10+ messages in thread
From: Mathias Nyman @ 2019-08-14 13:34 UTC (permalink / raw)
  To: Kai-Heng Feng
  Cc: Felipe Balbi, Oliver Neukum, Mika Westerberg, Kent Lin,
	Linux PCI, Linux USB List

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-09 13:10 Titan Ridge xHCI may stop to working after re-plugging the dock Kai-Heng Feng
2019-07-10 11:49 ` Oliver Neukum
2019-07-19  7:23   ` Felipe Balbi
2019-07-19 10:29     ` Kai Heng Feng
2019-07-19 10:51       ` Felipe Balbi
2019-07-22  9:44         ` Kai-Heng Feng
2019-07-24 14:45           ` Mathias Nyman
2019-07-25 13:24             ` Kai-Heng Feng
2019-08-13  6:50               ` Kai-Heng Feng
2019-08-14 13:34                 ` Mathias Nyman

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org linux-usb@archiver.kernel.org
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/ public-inbox