Re: xhci_hcd WARN Event TRB for slot ep with no TDs queued?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux