Hi, I have followed the guide https://wiki.archlinux.org/index.php/Bisecting_bugs : $ git clone https://github.com/torvalds/linux $ git bisect good v4.12 $ git bisect bad v4.13 Bisecting: 7028 revisions left to test after this (roughly 13 steps) [ac7b75966c9c86426b55fe1c50ae148aa4571075] Merge tag 'pinctrl-v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl And now? How can I see/send the changes between 2 versions? 2017-11-06 8:50 GMT+01:00 Juan Simón <decedion@xxxxxxxxx>: > 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
