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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
