Currently these bits are not checked, only PLS & PLC which are in the right state. Actually in the xhci spec, "4.15.2.3 Wakeup Events", it is stated that the Current Connect Status (CCS, bit 0 of port status see 5.4.8) & PED Port Enabled/Disabled (PED, bit 1 of port status) are to be both to be set on a proper wake-up event. Do not enable "bus_state->port_remote_wakeup" if the port status is not right.
#Dell e series dockstation dead Patch
NOTE: I found a patch that fixed an issue with a similar outcome: "xhci: fix usb2 resume timing and races (f69115f)". This leads to runtime PM to busyloop as it should be able to suspend, creating easily 1000 suspend request per second. On the runtime PM side, the bus being idle, suspend operations are triggered but fail as "bus_state->port_remote_wakeup" is still enabled. This leads to the hub disconnecting all devices from the root hub, they never seem to come back up again (I have yet to look exacly why). In the meantime the hub work queue kicks in (summoned by xhci upon receiving the first port status change) which marks the device state as NOTATTACHED, seeing the faulty state. Which is to be expected given the weird state. The network device never sends the second port status change. The first part of the operation is run by the HCD. In the meantime, to avoid unwanted suspend operations it setsan internal mask: "bus_state->port_remote_wakeup". Then wait until a new port status change event shows up with PLS set to U0, which confirms the device as fully resumed.
#Dell e series dockstation dead driver
In xhci when handling a remote wake-up from a USB3 device the host controller driver has to set PLS, which is in resume state, to U0 state, and clear PLC. > xhci_hcd:xhci_hub_control: xhci_hcd 0000:3e:00.0: get port status, actual port 0 status = 0x13e3 PLC = 1 and PLS is in Resume state, but the device is neither Connected (bit 0) nor Enabled (bit 1) (see 5.4.8 in xhci spec).
> xhci_hcd:xhci_hub_control: xhci_hcd 0000:3e:00.0: get port status, actual port 0 status = 0x1e0 It comes up with a faulty port state (HW issue?): The failing case is triggered after a remote wake-up event triggered by the network interface. When WD15's network interface is idle, the whole HUB enters/exits suspend every 3-4s. It's a USB PM issue as noted by Cédric. Happens with upstream kernel (last time I checked). I'm running some tracing with the hopes of finding out who's triggering that.Ĭomment 9 Nicolas Patricio Saenz Julienne There was nothing before that in the log. > The best guess is that you ran into rtl8152_tx_timeout(). > (In reply to Nicolas Patricio Saenz Julienne from comment #4) (In reply to Oliver Neukum from comment #5) So I am not sure you are seeing the same issue.Ĭomment 6 Nicolas Patricio Saenz Julienne What was before that in the log?īut in your case the HC survived. But that does not tell us what triggered it.
The best guess is that you ran into rtl8152_tx_timeout(). > usb 4-1.4: reset SuperSpeed Gen 1 USB device number 4 using > usb 4-1.4: Disable of device-initiated U2 failed. > usb 4-1.4: Disable of device-initiated U1 failed. > usb 4-1.2: reset SuperSpeed Gen 1 USB device number 3 using > usb 4-1.2: Disable of device-initiated U2 failed. > usb 4-1.2: Disable of device-initiated U1 failed. > usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using > For the record I managed to reproduce it. (In reply to Nicolas Patricio Saenz Julienne from comment #4)
0 kommentar(er)
