On 25/10/18 4:45 PM, Mathias Nyman wrote:
Reproducing the issue with a recent kernel with xhci traces enabled should show
the reason for EPROTO error.
Add xhci traces before triggering the issue with:
mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
after issue is triggered save and send the trace at
/sys/kernel/debug/tracing/trace
Note that it might be huge
Thanks for the suggestion.
Here[1] is (part of) the trace starting about 250 lines before the EPROTO
happens.
[1]:
https://gist.githubusercontent.com/angelsl/fdd04d2bded3a41029122b0536c00944/raw/b8e9f7d2695ac030b7f3dd53a1a9c3f37da7b7a0/trace
The first error happens at line 243 (timestamp 8144.248398) coinciding with the
start of errors spewed into dmesg:
[ 8144.245359] r8152 2-2:1.0 enp0s20f0u2: Rx status -71
[ 8144.248837] r8152 2-2:1.0 enp0s20f0u2: Rx status -71
[ 8144.252392] r8152 2-2:1.0 enp0s20f0u2: Rx status -71
[ 8144.255987] r8152 2-2:1.0 enp0s20f0u2: Stop submitting intr, status -71
...
It doesn't seem to point to anything in particular, but I'm not really familiar
with USB. I'll do some digging in any case...
Thanks!
--
Hao Wei
