On 19/12/2018 15:07, Mathias Nyman wrote:
On 19.12.2018 12:18, Richard van der Hoff wrote:
On 13/12/2018 10:29, Richard van der Hoff wrote:
Thanks for looking at it. I've attached a log from a 4.19.8 kernel
showing the problem with the dynamic debug flags you suggested. The
first instance of the problem seems to begin with:
Dec 13 09:32:56 fred kernel: [ 479.158038] xhci_hcd 0000:39:00.0:
Port Status Change Event for port 1
Dec 13 09:32:56 fred kernel: [ 479.158045] xhci_hcd 0000:39:00.0:
handle_port_status: starting port polling.
Dec 13 09:32:56 fred kernel: [ 479.158062] hub 3-0:1.0: state 7
ports 2 chg 0000 evt 0002
Dec 13 09:32:56 fred kernel: [ 479.158070] xhci_hcd 0000:39:00.0:
get port status, actual port 0 status = 0x202a0
Dec 13 09:32:56 fred kernel: [ 479.158071] xhci_hcd 0000:39:00.0:
Get port status returned 0x10100
Dec 13 09:32:56 fred kernel: [ 479.158083] xhci_hcd 0000:39:00.0:
clear port connect change, actual port 0 status = 0x2a0
Dec 13 09:32:56 fred kernel: [ 479.158087] usb usb3-port1: status
0100, change 0001, 12 Mb/s
Dec 13 09:32:56 fred kernel: [ 479.158095] usb 3-1: USB disconnect,
device number 2
Dec 13 09:32:56 fred kernel: [ 479.158097] usb 3-1.1: USB
disconnect, device number 3
Dec 13 09:32:56 fred kernel: [ 479.158098] usb 3-1.1.3: USB
disconnect, device number 8
Dec 13 09:32:56 fred kernel: [ 479.158100] usb 3-1.1.3:
unregistering device
Mika, Mathias: sorry to pester. I've been trying to decode this with
the help of the source. Any clues?
My impression is that "get port status, actual port 0 status =
0x202a0" means that the xhci controller is reporting a zero value for
the port status and control register - ie, that the dock is
disconnected. If that's the case, it presumably points fairly firmly
to a hardware issue of some kind.
It would be really helpful to get your thoughts on this.
Sorry about the late reply, you are right, xhci reports that something
happened on that port,
and when reading PORSC register it shows a device was disconnected.
When the last USB device connected to a Alpine Ridge xHC controller the
whole controller is
PCI hotplug removed from the PCI bus.
Details:
* Dec 13 09:32:56 fred kernel: [ 479.158038] xhci_hcd 0000:39:00.0:
Port Status Change Event for port 1
means xhci controller sent an interrupt because it something changes
on a port
* Dec 13 09:32:56 fred kernel: [ 479.158070] xhci_hcd 0000:39:00.0: get
port status, actual port 0 status = 0x202a0
Port Status: 0x202a0
Disconnected
Disabled
Link: Rx Detect
Powered
Unknown port speed
Connect Status Change
Connection changed to disconnect, this is what a port status should
look like when a SS USB 3 cable is unplugged.
The xHCI controller at 0000:39:00.0 creates two USB buses, a High Speed
(HS) bus named usb3,
and a SuperSpeed (SS) bus named usb4.
A SS hub will have both a HS and SS hub built into it. The internal
roothub in xHCI is shown
as a HS hub at the usb3 bus named named usb3-0, and a SS hub at usb4-0.
The dock device is seen as a HS hub at usb3-1, and SS hub at usb4-1.
All other devices in your dock are behind these hubs.
We see a sudden disconnect of the HS parts of the external hub, most
likely the SS hub part
would disconnect soon, but the Alpine ridge controller is very fast in
hotplug removing the
whole xHCI contoller from PCI bus once no usb devices are connected, so
next we see
PCI code calling the remove callback of the xHC PCI device:
* Dec 13 09:32:56 fred kernel: [ 479.260618] xhci_hcd 0000:39:00.0:
remove, state 1
And later xHC controller is removed from PCI bus:
*Dec 13 09:32:57 fred kernel: [ 479.609866] pci_bus 0000:39: busn_res:
[bus 39] is released
Until apparently a connected usb device is discovered afain, xHC
controller is added to pci bus,
xhci driver is loaded and so on.
So main cause here is a sudden disconnect of the dock.
Right, thanks very much for explaining all that. I'll take it up with
Plugable support.
Richard
