On 09.01.2017 16:23, Patrice Chotard wrote:
On 01/09/2017 01:30 PM, Mathias Nyman wrote:
On 09.01.2017 11:51, Patrice Chotard wrote:
Hi Mathias, Greg
Hi
I am working on ARM STi platform, since v4.10-rc1, when booting B2260 or B2120
STi boards platform
with nothing plugged on USB3 connector, i observed the following kernel logs :
....
[ 801.953836] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
That's odd, why does it try to reset the port if there's nothing there?
[ 801.960455] xhci-hcd xhci-hcd.0.auto: Cannot set link state.
This makes sense, nothing is connected, and we try to set link to U3 (PORT_PE
== 0)
[ 801.966611] usb usb6-port1: cannot disable (err = -32)
xhci reutns -EPIPE as we try to set link state to U3 while port is not enabled
(PORT_PE == 0)
[ 806.083772] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
Again, about 5 seconds later the same port is reset, while nothing is connected.
Odd
[ 806.090370] xhci-hcd xhci-hcd.0.auto: Cannot set link state.
[ 806.096494] usb usb6-port1: cannot disable (err = -32)
[ 810.208766] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
[ 810.215374] xhci-hcd xhci-hcd.0.auto: Cannot set link state.
[ 810.221478] usb usb6-port1: cannot disable (err = -32)
[ 814.333767] usb usb6-port1: Cannot enable. Maybe the USB cable is bad?
[ 814.340364] xhci-hcd xhci-hcd.0.auto: Cannot set link state.
.....
Another interesting thing is even if i plugged a device (a mass storage device
in my case) on the USB3 connector,
the above logs continue to appear.
This is due to commit 37be66767e3ca "usb: hub: Fix auto-remount of safely removed or
ejected USB-3 devices".
I don't know if STi platforms are the only impacted by this issue.
On v4.9 everything was ok.
Was there not a single "Cannot enable. Maybe USB cable is bad" message with 4.9?
There is no "Cannot enable. Maybe USB cable is bad" message with 4.9
Before commit 37be66767e3ca we forced the port to RxDetect state via Disabled
state,
and cleared port change flags when a usb3_port_disable() was called.
after we just set the port to U3. Maybe those STi platforms depend on that
cycle somehow?
I really don't know :-(
Could you take logs (dmesg) of both 4.9 and 4.10-rc1 with both usb core and
xhci debugging enabled:
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
You will find below the 2 requested logs, in both case , no USB cable are
plugged.
v4.9 dmesg logs :
.....
[ 31.368022] hub 6-0:1.0: hub_resume
[ 31.368064] xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status
= 0x400340
[ 31.368071] xhci-hcd xhci-hcd.0.auto: Get port status returned 0x400340
[ 31.368224] hub 6-0:1.0: state 7 ports 1 chg 0000 evt 0000
Looks like port is stuck in Compliance mode, this should only happen if a
connect was detected,
moving the port from RxDetect to Polling, and then timeout on polling to get to
compliance.
4.9 is then stuck in a hub_suspend/resume loop with a port in compliance mode.
v4.10-rc1 dmesg logs :
....
[ 269.436617] usb usb6-port1: cannot disable (err = -32)
[ 269.464728] hub 6-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 269.464756] xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status
= 0x340
I 4.10-rc1 we are again stuck in Compliance mode, but this time there was a
event (00002) visible, maybe because
the flags were not cleared or some other reason. Now are stuck in a port reset
loop with the
port in compliance mode.
So the real question is why is the port in compliance mode when there are no
devices connected.?
I'll continue looking at this more tomorrow
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
