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,
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