Hi, This is the same trace with kernel 4.12.9: https://pastebin.com/280Xeu8X I'll try to do a "git bisect" with kernel today. Thanks. Regards. 2017-11-02 18:18 GMT+01:00 Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>: > 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
