From: Behalf Of Evan Langlois
> Sorry if this is answered somewhere, but I couldn't find anything
> specific on Google as far as how to determine if this quirk is needed
> or if its configurable at boot/run-time. Its an HP laptop, and it
> looks like other HP models have the problem.
>
> I most often get this when turning on a USB TV Tuner, which is also HP
> branded but shows up as a Hauppage device. I get glitches on the TV
> output, less with tvtime than other viewers, and these glitches go
> away if I transcode a DVD while watching TV .. yeah, I know that makes
> no sense. Not sure if the glitches are related to the dmesg warnings.
>
> I'll attach the lspci to the message in case anyone needs it. Please
> advise on the next step to proceed.
>
> I'm running a Ubuntu kernel, but I imagine a stock kernel would react
> the same. uname -a ...
> Linux Taro 3.13.0-32-lowlatency #57-Ubuntu SMP PREEMPT Tue Jul 15
> 04:08:59 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> dmesg output .... (all the repeats deleted) ...
> [270905.416782] xhci_hcd 0000:00:10.0: WARN Successful completion on
> short TX: needs XHCI_TRUST_TX_LENGTH quirk?
Given that the code always checks the receive transfer length (in order
to output the message), maybe the code should be refactored to always
use the receive transfer length and the quirk removed.
I doubt there are any controllers that write a non-zero 'residual'
byte count at the end of a full transfer.
David
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
