> On Sat, 2016-08-20 at 14:14 +0200, Julio Guerra wrote:
>>>> Another example:
>>>>> 00 00 00 00 00 00 00 01
>>>> ...
>>>>> 01 00 00 00 00 00 00 00
>>>> ...
>>>>> 00 01 00 00 00 00 00 00
>>>> ...
>>>>> 00 00 01 00 00 00 00 00
>>>> after a random number of times, while usbmon shows the usb payload
>>>> "00 00 00 00 00 00 00 01".
>>>
>>> Hi, how many bytes does read() return?
>>>
>>
>> Exactly 8 bytes, always. I set the tty in raw non-canonical mode with
>> vmin = 8 and vtime = 0. I also tried with vmin = 1 and did the copy of
>> exactly 8 bytes by looping in userspace, without any improvement.
>>
>> I wrote a small workaround for now that detects this problem (because I
>> exactly know what the buffer is supposed to look like) to close() and
>> re-open() the device. The next read buffer is then correct.
>>
> 
> Please activate dynamic debugging for the tty and cdc_acm driver.
> We need to know where the corruption happens.
> 

I didn't find anything helpful in /sys/kernel/debug/dynamic_debug
regarging the tty module (I enabled tty_io debugs and it doesn't appear
in the logs), but I enabled cdc_acm debugs. Nothing is observable in the
logs when the bug appears. I logged everything as a comment of the gist:
https://gist.github.com/Julio-Guerra/b6529994f814771c825649bdb8d927c2#gistcomment-1875985

Note that re-running the script restarts the underlying kernel buffer
correctly, it does not restart from its previous bugged state.

Let me know if you want other debug traces enabled.

-- 
Julio Guerra

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to