What is wrong with FreeBSD and USB Support
mrechberger at gmail.com
Mon Mar 6 08:53:49 UTC 2017
Just to clarify this issue it's hardware and software related.
In the linux libusb20 wrapper there's some code in it in the bulk
if (xfer == xfer0)
xfer = xfer1
xfer = xfer0
why should someone toggle the other transfer and not the same one that
is returning or required to set up?
I would like to set up multiple requests at the same time and not only
2 of them (since 2 of them are not fast enough in our case).
This is about resolving an active bug and misconception of the freebsd
userspace usb API usage.
Some hardware just need a lower latency.
On Mon, Mar 6, 2017 at 7:05 AM, Markus Rechberger <mrechberger at gmail.com> wrote:
> libusb20_dev_open() opens an USB device so that setting up USB
> transfers becomes possible. The number of USB transfers can be zero
> which means only control transfers are allowed. This function returns
> zero on success else a LIBUSB20_ERROR value is returned. A return
> value of LIBUSB20_ERROR_BUSY means that the device is already opened.
> libusb20_tr_get_pointer() will return a pointer to the allocated USB
> transfer according to the pdev and tr_index arguments. This function
> returns NULL in case of failure.
> what is the definition of a "tr_index"? The documentation does not
> cover that anywhere, someone can only copy it from the sample sources.
> Please don't expect that anyone reading the manpage will have an idea
> how the FreeBSD API works, because all those items simply do not exist
> with other operating systems, neither is the ep_index calculation
> needed with other systems.
> uint8_t ep_index = (((addr & 0x80) / 0x40) | (addr * 4)) % (16 * 4);
> uhe->bsd_xfer = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 0);
> uhe->bsd_xfer = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 1);
> So my guess is that the examples are just using 2 urb transfers and
> freebsd just cannot catch up. However it is still unclear how to
> correctly initiate more than 2 urb transfers by reading the
> On Mon, Mar 6, 2017 at 6:50 AM, Markus Rechberger <mrechberger at gmail.com> wrote:
>> I got one step further it turns out that the problem is indeed the
>> FreeBSD Stack, the latency is terrible causing an overflow on the
>> chipside. Once that happens the transfer has to be restarted (which
>> requires to toggle a register).
>> Is there any way to do low latency transfers with FreeBSD?
>> On Mon, Mar 6, 2017 at 6:19 AM, Markus Rechberger <mrechberger at gmail.com> wrote:
>>> I have been trying to port a driver to freebsd for a day now and the
>>> result is quite negative.
>>> So my feedback about libusb20 and the FreeBSD USB Kernel Stack:
>>> 1. the documentation is not clear how to set up asynchronous bulk
>>> transfers (please explain the architecture of this API)
>>> 2. the errors returned by libusb20 (and probably from the kernel) are
>>> not detailed enough (in certain cases I'm able to get libusb20 unknown
>>> error, to my understanding every error should have some meaning).
>>> 3. the FreeBSD USB Stack messes around with the transfer itself
>>> damaging the entire result (eg resulting in stalled USB bulk
>>> 4. The FreeBSD data transfer implementation itself is a disaster, I'm
>>> able to transfer data at a rate of 2 MB/sec, anything higher results
>>> in a stalled usb transfer?!
>>> 5. USB Control messages are 100% slower than with other operating
>>> systems (eg. it took 14 seconds to load a driver with FreeBSD while it
>>> only takes 7 seconds on other systems).
>>> Since I have been using USB stacks with Linux, Mac and some other
>>> systems I can say that FreeBSD has the most irritating implementation
>>> of all.
>>> So finally I wonder what is wrong with FreeBSD's USB support?
>>> Best Regards,
More information about the freebsd-multimedia