On 02.11.2017 16:31, Juan Simón wrote:
Hi,
This is the trace output: https://pastebin.com/apt56yGe
Thanks
xhci logs look pretty good to me. A interrupt transfer TRB is queued
asking for 32 bytes from the mouse, and mouse replies with 15 bytes.
After this and we immediately queue the next TRB.
Are you sure this generates the "WARN TRB for slot x ep with no TDs queued"?
can you check dmesg if those really appear?
In the logs we always have a TRB (TD) queued when we receive events.
The mouse is however constantly responding with 15 bytes of data,
as if it's constantly moving, sending data.
Not sure how HID devices normally behave, but my guess is that they would
respond with a NAK to the interrupt transfer if no data is pending.
git bisect would show when it stopped working, could be a change
somewhere else as well, hid maybe?
-Mathias
(leaving rest of message for reference)
I'm going to ask in Arch forums to see how I can get the differences
of the xhci_hcd module in both versions of the kernel.
Thanks.
Regards.
2017-11-01 12:11 GMT+01:00 Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>:
On 31.10.2017 16:45, Juan Simón wrote:
Hi,
Thanks but that patch doesn't work for me. The warnings in system log
aren't the problem. In my case, with 4.13.x kernels, the problem is
that the system continuously receives mouse signals.How do I detect
it? Because when I put a video on YouTube the bar with the controls
never disappears even though the mouse is still. The same goes for
Netflix videos. And when I run a command in a terminal emulator with a
long output and scroll to read the initial output I can't because the
terminal receives a signal from the mouse continuously that makes it
returns to the end.
At first I thought the problem was the type of mouse I was using:
Logitech MX Master. But I've tested with a simple wired mouse and it
also fails.
On the other hand, I bought this tower from an online store that is
specialized in selling computers with Linux compatible hardware. And
all its components are fully compatible with Linux but it turns out
that now I have this problem and I don't know how to fix it. Is Arch
Linux a problem? Is it a kernel problem? Is it a hardware problem?
With the exception of the network card, which is from Realtek, the
rest of the hardware is from Intel. Isn't Intel hardware supposed to
be Linux-friendly?
Thats why I'm here helping you debug this ;)
If the problem started when upgrading the kernel from 4.12.x to 4.13.x
then I'd start looking there. As Greg said, git bisect is the best way
to find which change caused this regression.
second best way is to show me xhci traces of the this.
xhci traces can be taken 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
< do whatever is needed to trigger issue>
then send me content of /sys/kernel/debug/tracing/trace
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
