What is wrong with FreeBSD and USB Support

[Hans Petter Selasky]

On 03/06/17 12:14, Markus Rechberger wrote:
> 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);
>>

Hi,

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

The job submitted above, does not match the footprint of 
libusb20_tr_setup_bulk(). You have submitted a USB BULK transfer using 
libusb20_tr_set_total_frames(xfer, 10). Have you mixed USB ISOC and USB 
BULK?

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

This line is correct for single-transfer BULK:
libusb20_tr_setup_bulk(xfer, tb, urb->buffer_length, 250);

>
> The only explanation for that problem is that freebsd is not reading
> the data fast enough and lets the chip overflow (=requiring to reset).

--HPS