What is wrong with FreeBSD and USB Support

[Markus Rechberger]

On Mon, Mar 6, 2017 at 12:04 PM, Hans Petter Selasky <hps at selasky.org> wrote:
> Hi,
>
> Issue 2:
>
> Looking at the log you sent I observe the following:
>
>> 11:39:43.395110 usbus1.2
>> SUBM-BULK-EP=00000081,SPD=HIGH,NFR=10,SLEN=0,IVAL=0
>>  frame[0] READ 0 bytes
>>  frame[1] READ 0 bytes
>>  frame[2] READ 0 bytes
>>  frame[3] READ 0 bytes
>>  frame[4] READ 0 bytes
>>  frame[5] READ 0 bytes
>>  frame[6] READ 0 bytes
>>  frame[7] READ 0 bytes
>>  frame[8] READ 0 bytes
>>  frame[9] READ 0 bytes
>>  flags 0x10 <PROXY_BUFFER|0>
>>  status 0x6a023
>> <OPEN|TRANSFERRING|STARTED|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|0>
>> 11:39:43.395115 usbus1.2
>> DONE-BULK-EP=00000081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0,ERR=STALLED
>>  frame[0] READ 0 bytes
>>  flags 0x10 <PROXY_BUFFER|0>
>>  status 0x8a025
>> <OPEN|DID_DMA_DELAY|STARTED|BDMA_ENABLE|BDMA_SETUP|DOING_CALLBACK|0>
>
>
> The first multi-BULK transfer that STALLs is programmed to only receive
> zero-length USB packets. Is that intentional?
>
> In the case above there is a missing code fragment like this, I suspect:
>
> for (x = 0; x != 10; x++)
>      libusb20_tr_set_length(xfer, buffer_size, x);
>

seems to be intentional.
in the LIBUSB20_START_... section it will do a
libusb20_tr_setup_bulk(xfer, tb, urb->buffer_length, 250);

that should also set the length (otherwise it shouldn't work at all I guess)

The only explanation for that problem is that freebsd is not reading
the data fast enough and lets the chip overflow (=requiring to reset).
I don't think that this can be solved with libusb20, I really think
this is a USB stack kernel problem.

Markus