From owner-freebsd-multimedia@freebsd.org Mon Mar 6 05:19:47 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEDB8CFA8C7 for ; Mon, 6 Mar 2017 05:19:47 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92D551DFC for ; Mon, 6 Mar 2017 05:19:47 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x22f.google.com with SMTP id p64so18282473qke.1 for ; Sun, 05 Mar 2017 21:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1p6LslJvHTz9/nECpaxOFJL7rm4Fx9U3WD7EetR9OQU=; b=HDP7qNf1Oh0p20FVAqmXSwsvuFPQKA9zG19DNZw/QnkDXsYZWpL0r31PCgBLJV0Zmz 00zPqd5MenGSd0Ta9DT+VTjkgWzstb8ttTjxiSSvhVqF3i1h7OaCOhfKEFKiqCDrLwRl rbm8VV3kvjUQ0qiI3xyxlcTfls8JzlU9sdt+bBla37pxMtWDoPTZ+bruAspFhhUpShN8 UUCSsxfk9sXXm1mSGce6ggwpCaN9DXLMgZvjXtbQM2wzF+Qoal6xRkMKNZIJvesio0Qy 6Sbjt0YBmmO1ps1HZbJosBwEjcJ2ePbV6RXJ5P4X/pZPvFjWFkTRH5NeqoiL9MMO0acC eg7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1p6LslJvHTz9/nECpaxOFJL7rm4Fx9U3WD7EetR9OQU=; b=OBLDhh6cWOlgjs63tRze4JQgcxSykir4WDD8O9WqrJqEFtQ9EaODXX6kDWxJCth7yK Fx+II1kuI55iAZDb6dYORyJa7PJfNj/eNsrlH1WSmd+Nncshae7XxdEhfZ43a9YHtYS2 DtIo4pM7ZJplFAMBS9zL0qDcj3yrk6EQ9T1mznarANTaEuQcrZFY9z9YwoxK8ntby92Y oFyTWKD898+m7jeG2F5oV6z5VSlXjStDQ1V7nHfUg0J8qj/2n6b+zuu/fnoTGKuu3bmD R8vzOxIZJybEdMClWpnzmOl8n3zwYVrUNpqboteE1QC9oUF419ZUB1Bbk9tQVVWKqarV Z1+Q== X-Gm-Message-State: AMke39mgDyKBAtR/Op5d56CEd0/VRMNNyfAZPfITj5Zc0RkjtUV0J5syR6hFjekJqqj0/Y7xIHbWL7fMPgf+FA== X-Received: by 10.237.35.164 with SMTP id j33mr15233131qtc.194.1488777586501; Sun, 05 Mar 2017 21:19:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Sun, 5 Mar 2017 21:19:46 -0800 (PST) From: Markus Rechberger Date: Mon, 6 Mar 2017 06:19:46 +0100 Message-ID: Subject: What is wrong with FreeBSD and USB Support To: freebsd-multimedia@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 05:19:47 -0000 Hi, 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 transfers). 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, Markus From owner-freebsd-multimedia@freebsd.org Mon Mar 6 05:50:09 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF94ECFC5F1 for ; Mon, 6 Mar 2017 05:50:09 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D5511299 for ; Mon, 6 Mar 2017 05:50:09 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id 1so137559144qkl.3 for ; Sun, 05 Mar 2017 21:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=6nVmMLh9+VEmApjY+Wdy2QA8N2nAvJtgnXpflL9VLf4=; b=PWkBmx8JzojHWdc6LqyT3ChEgZJ8RraayAFcd6qNOSwdnivW66vi2Rv06brHY12/VC ooMtNFWPxWYaYkQLgw55GbsNazsUt6GPUQAjajS6PeBwKYCc8o17Tnpn3u3bm42lDtUZ UeCQHsxPDQvaydaZ2Ng3ZC5hRa543KLuYzD7jCc+Qgp1EFeXLvGKMUd0ICShxjmYiEit MmJjFDQHAOoYxAf//AVVxwtgCmW9IdXGmQpMEVS0P/9cdQwHCxggkB+ioP4QYpvI8kNk N+9YAmnewCLyjemJv0TnwjFkw31LjfyM8aEeUeel5e1aMBiEHhUIh6KVEgVoCQUKkCvP wDyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=6nVmMLh9+VEmApjY+Wdy2QA8N2nAvJtgnXpflL9VLf4=; b=W6fsUAZiy8Csm6rRVADj8aFy/StUPQRubUPv488ya9K8IX9HDWE9Tlb/xMbKCJKSyw NaPbuF5kJmkctBG2TENmhU1MDgreOogpYToFA6CNkPbbkv7VhAeJ6xD3eICbgNbr2LJ/ eXIB4RVz1Q+O04qj1eBUW/sSGhjTYH7/FjrcYYZR0yrlGOIdjWu/tPcQSH485XRnzPf+ z8aCy0bUp9n6JmOyLeOfq0CQiOMje5lJkU920kaBtBkzfTlSh6WCpWn2efFxsjDNXtle kYvL8Kq/E9DKUPucBSaHBhvQs3KtJ7pnY33NP7/w3Co8LPUgTIvERXvEkaY9oRu+Sssc XT4A== X-Gm-Message-State: AMke39mykTesAUTsC3w16IPRApsnVFBjN8Sln01UMulRGRvDDoxaewfxmAt7bnqZMj4l3dvhBEUGbMotFNGvCA== X-Received: by 10.55.47.4 with SMTP id v4mr13698288qkh.77.1488779408553; Sun, 05 Mar 2017 21:50:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Sun, 5 Mar 2017 21:50:08 -0800 (PST) In-Reply-To: References: From: Markus Rechberger Date: Mon, 6 Mar 2017 06:50:08 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: freebsd-multimedia@freebsd.org, Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 05:50:09 -0000 Hi, 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? Markus On Mon, Mar 6, 2017 at 6:19 AM, Markus Rechberger wrote: > Hi, > > 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 > transfers). > > 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, > Markus From owner-freebsd-multimedia@freebsd.org Mon Mar 6 06:05:23 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AB9FCFB02B for ; Mon, 6 Mar 2017 06:05:23 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 480781BA2 for ; Mon, 6 Mar 2017 06:05:23 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x231.google.com with SMTP id v125so76832457qkh.2 for ; Sun, 05 Mar 2017 22:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VBak5ZGZczjQPVnl1XyB/QvlExi/rE0AUZiMpoN7cpc=; b=DhY6YbJQk8biXdu59JjNEkhW7gNM3WIjRQIiTBMzPqQwBjWD+H1zuydYriLBlmCfJg Ufg3FWE7GWnwIAXP8pdcTdoKXBu8T5nk86oxC6ED0E/c3NKq4TECl0EGxYsidUjGWY7r /NmyAILVaQH/dCj/ofhMsAs1tsKGdS7O8REc9jHe2lqaXaLLJaWbEjJzNRMPTtub3H11 PSJOC8mmblE/sTrEWoBVLFIqIIL1AJsmp//XSsxhI5UsanU1A/bK4Yk2WioozddUUVOC AT+DZbLpa+FBPCTogKN0nzc7tUGK7m0hdBbceFF5e8TbZTxLysFLdklioBHhMGK3v5ss KA3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VBak5ZGZczjQPVnl1XyB/QvlExi/rE0AUZiMpoN7cpc=; b=kghdju/mCeK598O4dLIoSysdh+o8cDvDy5gznRYtxMOYTYnyQwDGJWiKc+uw2yr+rk zEtQskbtSna6tDic+aO73XM2eKaWcSUKVf5evqlHug2MURmLNB0vqxQ3dpzKAoFHKIYv ZEkQSH4uAk3XzsVSore74Tcz7QJ9XnMebx1v/G8S+41CogoYSyNGTzgm0ElKS16jxvNG To1AdC/cW9hgU2yL4RoFz1i5b9jC4Jx8htKfilQIKpWO5v7CVhT8GsV43OrJGhk1BIba ha7mcKZfWI9GNcEd4w4XckwSAGb/DtLj138zafpWIew/ckmAVKneOSevbuaF9v3JyoNB 2Mcg== X-Gm-Message-State: AMke39m1bwyMMn06Wwl7pLPe8WfHltL7rRENoUlwa003VHMRCsiwWebUdg1Nm46KrURy460PPTV6ex/Xr/+fMw== X-Received: by 10.237.41.229 with SMTP id o92mr13585579qtd.223.1488780322405; Sun, 05 Mar 2017 22:05:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Sun, 5 Mar 2017 22:05:22 -0800 (PST) In-Reply-To: References: From: Markus Rechberger Date: Mon, 6 Mar 2017 07:05:22 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: freebsd-multimedia@freebsd.org, Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 06:05:23 -0000 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[0] = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 0); uhe->bsd_xfer[1] = 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 documentation. Markus On Mon, Mar 6, 2017 at 6:50 AM, Markus Rechberger wrote: > Hi, > > 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? > > Markus > > On Mon, Mar 6, 2017 at 6:19 AM, Markus Rechberger wrote: >> Hi, >> >> 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 >> transfers). >> >> 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, >> Markus From owner-freebsd-multimedia@freebsd.org Mon Mar 6 08:53:49 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 705F6CFB4C6 for ; Mon, 6 Mar 2017 08:53:49 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CA2811A4 for ; Mon, 6 Mar 2017 08:53:49 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x230.google.com with SMTP id y76so11445203qkb.0 for ; Mon, 06 Mar 2017 00:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/jtFLFOoeqEOlZcdaJZ94vF1ODWXI6m2YyRCGj5I9dY=; b=XOgQ2PLsV77+8nIOIpLvu7g+5kPpoVISa29ROztZRIYv0d9Mpgg11LxAhYsollWS4O OOpt/QtZ4qQgoQ6Yn+ZXjANZAN+Qz6Sm+8PCjzXWF12jAFkG1VbqJsDiFGqv1jZv11iM oQjxjYK1IxoRyn3wGIIAxG16WOA1wl39jPNikoAF3zZK84RH/BA98VMgMsA7mdKEgyne hvern3dkj9vQV6uDGEpOhWbyTo0QljXgZKm/1OeF7DncdCOouFcFJH+2x7GlUJfiIRlP W0xJGbJ3I4jFxWB6uA7ft565HWqxiXI1pakZi4ld3ysOo3WfocXt1AcvF7YNCSJY7mhn 7QHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/jtFLFOoeqEOlZcdaJZ94vF1ODWXI6m2YyRCGj5I9dY=; b=bRLXfu+ICzOITsMy3RMINC5H5L0czRuyb2EmnYDLSjxGY0f8D3WxV5D7ARzavFoi+S LnOis2owa0F/HQUfblYUClW2oMllb7jJ2AdrqW+NQZaE98f54Qv6SA5Sw7Pk4GiaTP69 tNRST1VdLKA/Qwee2oyxEAZY1S5PglTWlHDaNeBp4IiYPokds2rM98PCw+MmAAWRicFV qqUikNBq93mhS7g2W60Qs1N/64xchBBVTrEmnhPQ45i1GtzVwmU5TaxapOCcJlhxh/DH ZD3fw7yExsRiOM4qW0ypnIFty+m4TM+GCC0av+doOELtDP8VBKrHQQxXNJMLKckssVoN DR2Q== X-Gm-Message-State: AMke39mfM54cHLwbBo+ZmAY/8209Vz+r/CN1cCkqAl1LJCsazk7yM0ezBKK69Hlxd/fiwCJpevhulpACBdnzbA== X-Received: by 10.237.50.6 with SMTP id y6mr14688248qtd.115.1488790428386; Mon, 06 Mar 2017 00:53:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Mon, 6 Mar 2017 00:53:48 -0800 (PST) In-Reply-To: References: From: Markus Rechberger Date: Mon, 6 Mar 2017 09:53:48 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: freebsd-multimedia@freebsd.org, Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 08:53:49 -0000 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 callback function libusb20_tr_submit(xfer) if (xfer == xfer0) xfer = xfer1 else xfer = xfer0 libusb20_tr_start(xfer) 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 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[0] = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 0); > uhe->bsd_xfer[1] = 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 > documentation. > > Markus > > On Mon, Mar 6, 2017 at 6:50 AM, Markus Rechberger wrote: >> Hi, >> >> 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? >> >> Markus >> >> On Mon, Mar 6, 2017 at 6:19 AM, Markus Rechberger wrote: >>> Hi, >>> >>> 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 >>> transfers). >>> >>> 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, >>> Markus From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:00:35 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BD71CFAB5B for ; Mon, 6 Mar 2017 10:00:35 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA94415F5 for ; Mon, 6 Mar 2017 10:00:34 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id 1so144817368qkl.3 for ; Mon, 06 Mar 2017 02:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EBAZvgEMKchikTE3mOP4BpmRJoqVHHsWfTb8Y/NYGZU=; b=bS4aQMiSrPLbUqtpDoi7jGgU9gtm8QVuI3Ssk4P3TYZZLKGiDcguT7uB3QeifvlHU8 YT807ctVp63pCkSxxH4ZCHQv8h1AAmr4b9Xvx2zfjA83L54N+EMyoWyrcMKZMdEvFbEF Ev/nQBvIKqtXFJnTl5DVA+U5v27ieDcNF6AmZ3/CpD08gsTnMz7q2xytCy18ksQn2pvG IBdgLzAMRN3fzOj0amNFK8pRVHsEFA3f3GdTqGaqXaKNzKSjjip0ytzswMtLMagD7YuE gG9zkcZ+oM2qqrQKIfV71NCzdVAzmKUMnj4tSFErRT9SbqPvgqCzG7BGlgn3JX88bg7F phZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EBAZvgEMKchikTE3mOP4BpmRJoqVHHsWfTb8Y/NYGZU=; b=ilXVsjfYKzELUxSGA0WCQDDrFOJX7WE7ykEue/ge3H9KBrtGseMO+zGVPu7cG5gN34 qbG8jSnKcNLmJuoQfnIVQ9oeF6QoAhk2YQF5vvO+9bVZ8wSfBI58tVgxHpYQNbi8fYGF SNon3pD4r/0lVyG1NKqMITgTRE9FLkFYmpbXhENIPSUqHo+a7JMfqMlAJNoGDaNFB9Bi od7nD1Xc3PAak82HIW/GakUXbCv/kNdHlHhkRch8zmnD36nWsxzjpDR0c0ZB50WSdCIT q///jT9CIU/Bmh/WrWeBBjWomq6JYt1VNxBoERW1MvXg8shYFSYipUho1UTfrbR7Dn+k H3vA== X-Gm-Message-State: AMke39kY7qBKV4kGd3oiHq1tKLMlWIBOMIQ4mee8bdAb0oQWLUlVxI2g6be7Ip3SLNrDFCo5752xSYjt/kmJgg== X-Received: by 10.237.41.229 with SMTP id o92mr14172323qtd.223.1488794433783; Mon, 06 Mar 2017 02:00:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Mon, 6 Mar 2017 02:00:33 -0800 (PST) In-Reply-To: References: From: Markus Rechberger Date: Mon, 6 Mar 2017 11:00:33 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: freebsd-multimedia@freebsd.org, Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:00:35 -0000 DVB-C: [2017-03-06 10:53:50] Data recovery within: 2981 milliseconds [2017-03-06 10:53:50] 40960 bytes | 40.00 kb | 0.04 mb transferred [2017-03-06 10:53:51] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:53:52] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:53:54] Data recovery within: 3009 milliseconds [2017-03-06 10:53:54] 30720 bytes | 30.00 kb | 0.03 mb transferred [2017-03-06 10:53:55] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:53:56] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:53:57] Data recovery within: 2004 milliseconds [2017-03-06 10:53:57] 30720 bytes | 30.00 kb | 0.03 mb transferred [2017-03-06 10:53:58] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:53:59] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:00] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:02] Data recovery within: 4009 milliseconds [2017-03-06 10:54:02] 30720 bytes | 30.00 kb | 0.03 mb transferred [2017-03-06 10:54:03] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:04] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:06] Data recovery within: 3027 milliseconds [2017-03-06 10:54:06] 30720 bytes | 30.00 kb | 0.03 mb transferred [2017-03-06 10:54:07] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:08] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:10] Data recovery within: 2988 milliseconds [2017-03-06 10:54:10] 30720 bytes | 30.00 kb | 0.03 mb transferred [2017-03-06 10:54:11] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:12] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:14] Data recovery within: 3018 milliseconds [2017-03-06 10:54:14] 30720 bytes | 30.00 kb | 0.03 mb transferred [2017-03-06 10:54:15] 0 bytes | 0.00 kb | 0.00 mb transferred [2017-03-06 10:54:16] 0 bytes | 0.00 kb | 0.00 mb transferred DVB-T: [2017-03-06 10:55:11] 983040 bytes | 960.00 kb | 0.94 mb transferred [2017-03-06 10:55:12] 1812480 bytes | 1770.00 kb | 1.73 mb transferred [2017-03-06 10:55:13] 1085440 bytes | 1060.00 kb | 1.04 mb transferred [2017-03-06 10:55:15] 1474560 bytes | 1440.00 kb | 1.41 mb transferred [2017-03-06 10:55:16] 1812480 bytes | 1770.00 kb | 1.73 mb transferred [2017-03-06 10:55:17] 972800 bytes | 950.00 kb | 0.93 mb transferred [2017-03-06 10:55:18] 1812480 bytes | 1770.00 kb | 1.73 mb transferred [2017-03-06 10:55:19] 1024000 bytes | 1000.00 kb | 0.98 mb transferred [2017-03-06 10:55:20] 1812480 bytes | 1770.00 kb | 1.73 mb transferred [2017-03-06 10:55:21] 1003520 bytes | 980.00 kb | 0.96 mb transferred [2017-03-06 10:55:22] 1495040 bytes | 1460.00 kb | 1.43 mb transferred even though it's going up and down DVB-T is okay due to the lower bandwidth so something's obviously wrong with the freebsd USB Support. On Mon, Mar 6, 2017 at 9:53 AM, Markus Rechberger wrote: > 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 > callback function > > libusb20_tr_submit(xfer) > if (xfer == xfer0) > xfer = xfer1 > else > xfer = xfer0 > > libusb20_tr_start(xfer) > > 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 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[0] = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 0); >> uhe->bsd_xfer[1] = 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 >> documentation. >> >> Markus >> >> On Mon, Mar 6, 2017 at 6:50 AM, Markus Rechberger wrote: >>> Hi, >>> >>> 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? >>> >>> Markus >>> >>> On Mon, Mar 6, 2017 at 6:19 AM, Markus Rechberger wrote: >>>> Hi, >>>> >>>> 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 >>>> transfers). >>>> >>>> 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, >>>> Markus From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:23:52 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CB18CFA4C0 for ; Mon, 6 Mar 2017 10:23:52 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC3C21689 for ; Mon, 6 Mar 2017 10:23:51 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4391A1FE086; Mon, 6 Mar 2017 11:23:19 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger , freebsd-multimedia@freebsd.org References: From: Hans Petter Selasky Message-ID: <43ec60ca-57ce-faf9-32da-524454e1ac4a@selasky.org> Date: Mon, 6 Mar 2017 11:23:01 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:23:52 -0000 On 03/06/17 07:05, Markus Rechberger 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. Hi, When you open a USB device you need to specify how many USB transfer structures you plan to use. Then you can bind each individual USB transfer by tr_index to an endpoint (bEndpointAddress). > > uint8_t ep_index = (((addr & 0x80) / 0x40) | (addr * 4)) % (16 * 4); > uhe->bsd_xfer[0] = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 0); > uhe->bsd_xfer[1] = 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 > documentation. dev = libusb20_dev_open(xxx, 4); xfer[0] = libusb20_tr_get_pointer(dev, 0); libusb20_tr_open(xfer, max_buf_size, max_frame_count, ep_no); xfer[1] = libusb20_tr_get_pointer(dev, 1); libusb20_tr_open(xfer, max_buf_size, max_frame_count, ep_no); xfer[2] = libusb20_tr_get_pointer(dev, 2); libusb20_tr_open(xfer, max_buf_size, max_frame_count, ep_no); xfer[3] = libusb20_tr_get_pointer(dev, 3); libusb20_tr_open(xfer, max_buf_size, max_frame_count, ep_no); Now you have four USB transfers index 0..3 inclusivly bound to USB Endpoint with bEndpointAddress ep_no. NOTE: FreeBSD will only hardware buffer the two first transfers you submit. That's why most drivers and examples only do double buffering. If you try to submit 32 x 512bytes as individual USB transfers, you will receive a penalty. Instead, submit one USB transfer having 32 so-called frames, which each has a length of 512 bytes. --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:26:05 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4254CFA583 for ; Mon, 6 Mar 2017 10:26:05 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70D741723 for ; Mon, 6 Mar 2017 10:26:05 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 631F61FE086; Mon, 6 Mar 2017 11:25:34 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger , freebsd-multimedia@freebsd.org References: From: Hans Petter Selasky Message-ID: <89e2eac5-5b95-ab42-a0ae-2ccb0b7483af@selasky.org> Date: Mon, 6 Mar 2017 11:25:17 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:26:05 -0000 On 03/06/17 06:19, Markus Rechberger wrote: > Hi, > > 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 > transfers). > > 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? Hi, Can you share some code and/or USB traces from "usbdump" for the slow traffic pattern. I'm pretty sure this isn't a FreeBSD problem, but how you use the APIs in FreeBSD's USB stack improperly. Further, which version of FreeBSD is this? Last but not least, if you are not observing 100% CPU usage on a CPU core during testing, it is for sure not a problem with the USB stack and/or IOCTL APIs. --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:31:22 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFE88CFA84E for ; Mon, 6 Mar 2017 10:31:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8BE2194D for ; Mon, 6 Mar 2017 10:31:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3810D1FE086; Mon, 6 Mar 2017 11:30:44 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger , freebsd-multimedia@freebsd.org References: From: Hans Petter Selasky Message-ID: <17db8b5b-9983-2ead-5c1d-960022afb1f6@selasky.org> Date: Mon, 6 Mar 2017 11:30:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:31:23 -0000 On 03/06/17 09:53, Markus Rechberger wrote: > 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 > callback function > > libusb20_tr_submit(xfer) > if (xfer == xfer0) > xfer = xfer1 > else > xfer = xfer0 > > libusb20_tr_start(xfer) > > why should someone toggle the other transfer and not the same one that > is returning or required to set up? Hi, This is to be able to setup double-buffering of USB transfers. > 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). Do do this correctly for a BULK endpoint, allocate two USB transfers, and then subdivide these two using the FreeBSD USB frames feature. Divide 1x USB transfers into 32x frames which then equals 32 transfers in one completion event. Linux/MacOS/Windows doesn't have this feature and instead they allow setting up a bunch of wMaxPacketSize sized jobs which then in turn generate an enormous completion event traffic, which is not very intelligent. > This is about resolving an active bug and misconception of the freebsd > userspace usb API usage. > Some hardware just need a lower latency. --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:35:40 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB7D3CFA9CF for ; Mon, 6 Mar 2017 10:35:40 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92E4D1E15 for ; Mon, 6 Mar 2017 10:35:40 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5B71D1FE086; Mon, 6 Mar 2017 11:35:09 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger , freebsd-multimedia@freebsd.org References: From: Hans Petter Selasky Message-ID: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> Date: Mon, 6 Mar 2017 11:34:51 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:35:40 -0000 On 03/06/17 11:00, Markus Rechberger wrote: > even though it's going up and down DVB-T is okay due to the lower > bandwidth so something's obviously wrong with the freebsd USB Support. Hi, Can you provide a usbdump trace and send it to me off-list? usbdump -i usbusX -f Y -s65536 -w usb_capture.pcap X and Y are number after ugenX.Y If you are using ISOCHRONOUS high-speed transfers with an XHCI USB controller, the XHCI is much less forgiving about the USB PIDs of the multi-data payloads coming from the USB device than the EHCI. I have seen at least one DVB-T USB adapter which is totally broken with XHCI and works just fine with EHCI. This has been verified with a USB wire analyzer. --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:37:24 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7226BCFAAC7 for ; Mon, 6 Mar 2017 10:37:24 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D4C81F0F for ; Mon, 6 Mar 2017 10:37:24 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id n141so19160935qke.3 for ; Mon, 06 Mar 2017 02:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tAm/94F5LA5omGWwGK70WF203UcVQnEcXr+SuRPFGc0=; b=HepZcbahteXQLg5XBy6hl6Y66KEAAbRR6kw4kU1gPmQ6it+gOiFjE3J98nLvlpkMt9 1qUEF5UkR1xa/EwINJI3FqoClcy1Yhawx8cuZuc4vsqnXJWiCIeaWaY5XrMWRhKMdsHt 5oBSFJ5nR/Ba1WBfPW0PV8H5XNbfq+rDAurU65zRVCjmqfTgk3siNbwEo5ZD+fO2nCTr B2MCU4MwKcCfsbBy3w/ZQ8WzgLgLL1yP3XLT+Bh1Fp4lmjgjvLfQH0sK7EUnSTcF7sBc 3TwVjggonM2XlFjz2xV4+l98fEnFRPUogr3PLF1yvAJikp5IukS/BP+hLUoW4Fyc+2/h ntlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tAm/94F5LA5omGWwGK70WF203UcVQnEcXr+SuRPFGc0=; b=ZE5rtDe5x5oQRCE114UaFk6kix10S+oDXNAZ9a2wWNuRB6+J79K0ZMIfWQDMlkxNTL CDrAsMsHKORlryxAL0U9ihjEh4E4VD5yoU5UpuJz5Q+OOeBF14casipgjD3qvIibJNmF NwbSOfjShsNrog9KMQ53EQ3WRa3wOaxbS5y01RBdDiaEDvH94UNsHDmIiljoSDyGsfEN q+f+0n932Jhvwg0LzpFt2X+G949LEsF/TgBOKR6xDmZH6sqiEjAIe2kS219S9sv3XuR+ mtGux/ETNRQIxWIR0cWGZNxu0a/9KwXi3ikMnNcWyImTHa3MMkJ39xm4Ll2t0vvDTE8U yU4A== X-Gm-Message-State: AMke39lJ0jM8kT50qWLRRWslI/YeNG4ZdJvdWC+6xanSR9kWi1HZb7fm4CJWN0NXn8AemngOxIyGArAHAFKwew== X-Received: by 10.200.52.135 with SMTP id w7mr15556372qtb.136.1488796643371; Mon, 06 Mar 2017 02:37:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Mon, 6 Mar 2017 02:37:22 -0800 (PST) In-Reply-To: <17db8b5b-9983-2ead-5c1d-960022afb1f6@selasky.org> References: <17db8b5b-9983-2ead-5c1d-960022afb1f6@selasky.org> From: Markus Rechberger Date: Mon, 6 Mar 2017 11:37:22 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: Hans Petter Selasky Cc: freebsd-multimedia@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:37:24 -0000 On Mon, Mar 6, 2017 at 11:30 AM, Hans Petter Selasky wrote: > On 03/06/17 09:53, Markus Rechberger wrote: >> >> 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 >> callback function >> >> libusb20_tr_submit(xfer) >> if (xfer == xfer0) >> xfer = xfer1 >> else >> xfer = xfer0 >> >> libusb20_tr_start(xfer) >> >> why should someone toggle the other transfer and not the same one that >> is returning or required to set up? > > > Hi, > > This is to be able to setup double-buffering of USB transfers. > >> 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). > > > Do do this correctly for a BULK endpoint, allocate two USB transfers, and > then subdivide these two using the FreeBSD USB frames feature. > > Divide 1x USB transfers into 32x frames which then equals 32 transfers in > one completion event. Linux/MacOS/Windows doesn't have this feature and > instead they allow setting up a bunch of wMaxPacketSize sized jobs which > then in turn generate an enormous completion event traffic, which is not > very intelligent. Are you sure? As from some of my signal analyzer dumps I do think that all those systems support multiple transfers within one completion event. I always request multiple frames within one request on those systems and they complete at once. And they only complete once all the buffers are filled. > > >> This is about resolving an active bug and misconception of the freebsd >> userspace usb API usage. >> Some hardware just need a lower latency. > > > --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:42:32 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EDE9CFAD5F for ; Mon, 6 Mar 2017 10:42:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5390A12FF for ; Mon, 6 Mar 2017 10:42:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E058D1FE086; Mon, 6 Mar 2017 11:41:59 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger References: <17db8b5b-9983-2ead-5c1d-960022afb1f6@selasky.org> Cc: freebsd-multimedia@freebsd.org From: Hans Petter Selasky Message-ID: <9f51e1b1-d5df-afd3-f289-3bc55e417b5a@selasky.org> Date: Mon, 6 Mar 2017 11:41:42 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:42:32 -0000 On 03/06/17 11:37, Markus Rechberger wrote: > Are you sure? As from some of my signal analyzer dumps I do think that > all those systems support > multiple transfers within one completion event. I always request > multiple frames within one request on those systems and they complete > at once. And they only complete once all the buffers are filled. Yes, I'm 100% sure. If you look at their APIs you will have to submit individual jobs as a URB in Linux. If you want to send 128 x 333 bytes as 333 byte sized USB HighSpeed BULK packets, then Linux/MacOS and Windows force you to generate 128 URBs/Jobs to send the 128 packets. In FreeBSD a single USB transfers can send 128x 333 bytes. Only in the case where you send full-sized packets having an optional short-sized packet in the end, Linux/MacOS and Windows allows you to accumulate them into a single completion event. --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:48:00 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83DA8CFAE69 for ; Mon, 6 Mar 2017 10:48:00 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DC7315F0 for ; Mon, 6 Mar 2017 10:48:00 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x233.google.com with SMTP id v125so85131685qkh.2 for ; Mon, 06 Mar 2017 02:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=thJ+0n3q/VybDUP8qvDmBPkEBm6RCmP9ZXGyRqkgdAs=; b=Gms2sVp3MBAHfBHn5h7Cye0zchpHmUZxcl67AJ/XQrtWE80qgdR7BIc2e1j5Z9a/Gi pnbh6y9Sfwh1g1OKsNbw/9GCMS5SqFGDZ2VNz4ShRhb/hAD38WnjNCcr4pL4nWf4lAS2 8vj2/pu/h5JLGC9OPj4AkNISWhhalP7ObpB4GlafJo7z2h9gyAQtoPPB3Bxfu2wiZkI9 rTzxlLwD79QmCpeoQCEPsaLhmKEUAEplkJBxWkRJM61Mg3xJjJnjRC3l1sZbzXpkntpJ bgcSbVmUIk/DMKQzOexHa8fPzhe1J4xUa/H3VEwmW0NHWsqi7zbPYjX5OgMDzGFFOn4/ MlUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=thJ+0n3q/VybDUP8qvDmBPkEBm6RCmP9ZXGyRqkgdAs=; b=QuJAKn7frPTyNJKIuD++KvOuG0szJKe5RvCZ3vjvyKuR2Wiftc7sO9BBiavBM+Y28g IRKErfUo9MFM8XOxABPUzV0Hgp79R7RiV3queQmwUK8nu0DkTuOI96bI9hESdjj1ifKx LYwyZwP77uNJqBFt4CCLLcPWQArL14b0yhy4g6+rMRZQTYZze3dNfFAl0hHlJJKsTFUS DjtF45r+2qJ/YrDdzGJ2zlasnyV59t3goFp1ccrT8CWvb8e39GLUB02+JYNYCPdbt/+M gKFu1+cDlmSGKMUHDaJhFv+cXdLQkMxxfZCPI4rgctj93wy7W+HvQiss6a3pnPuIdurK ioIQ== X-Gm-Message-State: AMke39kDsCa5qHZpYZldtxW+hypnTYQHsC9hw4lgePbgnQDeHJZ6AjMaTAiVekYh/BxvLH5Cu/pFyoQwoNtXjQ== X-Received: by 10.55.175.195 with SMTP id y186mr14387151qke.26.1488797279472; Mon, 06 Mar 2017 02:47:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Mon, 6 Mar 2017 02:47:59 -0800 (PST) In-Reply-To: <9f51e1b1-d5df-afd3-f289-3bc55e417b5a@selasky.org> References: <17db8b5b-9983-2ead-5c1d-960022afb1f6@selasky.org> <9f51e1b1-d5df-afd3-f289-3bc55e417b5a@selasky.org> From: Markus Rechberger Date: Mon, 6 Mar 2017 11:47:59 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: Hans Petter Selasky Cc: freebsd-multimedia@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:48:00 -0000 On Mon, Mar 6, 2017 at 11:41 AM, Hans Petter Selasky wrote: > On 03/06/17 11:37, Markus Rechberger wrote: >> >> Are you sure? As from some of my signal analyzer dumps I do think that >> all those systems support >> multiple transfers within one completion event. I always request >> multiple frames within one request on those systems and they complete >> at once. And they only complete once all the buffers are filled. > > > Yes, I'm 100% sure. If you look at their APIs you will have to submit > individual jobs as a URB in Linux. If you want to send 128 x 333 bytes as > 333 byte sized USB HighSpeed BULK packets, then Linux/MacOS and Windows > force you to generate 128 URBs/Jobs to send the 128 packets. In FreeBSD a > single USB transfers can send 128x 333 bytes. Only in the case where you > send full-sized packets having an optional short-sized packet in the end, > Linux/MacOS and Windows allows you to accumulate them into a single > completion event. > Unless we're talking about something different here I'm always generating single 15k (or bigger) requests with Linux and request them at once. I do not have to generate N 512byte URBs to request 15k. And the 15k (or bigger) only complete once they're fully filled. > --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:53:31 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B191CFB18E for ; Mon, 6 Mar 2017 10:53:31 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14F751C01 for ; Mon, 6 Mar 2017 10:53:31 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id p64so27982814qke.1 for ; Mon, 06 Mar 2017 02:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HcsuUl1wO3wdJp41My7dPYilw7k2R7oraH9QsvMYRk0=; b=IYJyagbUhEiW9Fxkwx45sf8wwRMGH5yC0haSH0XropUNJq9K/QvyL9H7JIcCk/n+Yg uVWTEcZDA4gtS79/5mPcTsJMF1ApDlKyWkWQZqQgGgX2AfIWmkDA5psHyefzhsEGnv33 zQmCQCBzCoPe3fqdf8lbRI31jitNemfxBf2iDK+UNcWxW4GwerjiN3Q/fNOnS40FqfGB rByNgs/8IYhuORbYUMfu4Rly1sPqF3wJUBdiiZbimmP34zWcr7zsdWDTvg/oQGK0QYrM URseW3qTodYA32MXGeJcST2fMySUNIeCdD+AEGimrAa8oUFSUwJQRoSUY1HiH/SleAkO MVAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HcsuUl1wO3wdJp41My7dPYilw7k2R7oraH9QsvMYRk0=; b=mnZ0DAQrvdgGjssmSDzMGyhjTnu9W+uZpHLxIIhGJdF/8jawKrCeriFFnkzqMs1cgU Cvb2HOdd7SoKfTUaV13dk4FGVsqEG9pivW83WMyWVDm4iq7RUxWzfwSlJZOMeytC7Sty +4cOg25fW5ZPA9NnUgYFj2byRGPzMxyYYxY2Da8SU9idL2XqbbDfsXTR4HhgrZm+4rPV LFxUTnVDFZtP3geTo3gH+2DpZORHWzO5dbBsMUDLiv9fV+zj74Ou8vX7qf7CepEsgyb9 Hy1Mt3zpJ5F9rob+KkOeucesuR42oVoPA43yywK7Xut/fV/aT+PMqFPp8Hpkd74+bPrU eBgg== X-Gm-Message-State: AMke39nWYpO/z/QoyDPQymy+1qQ3ZQrqidBwonRPQNfSdAwuORVtHIab5RMazVYjsKRfon/Ejz5l2otDBgw5nw== X-Received: by 10.237.41.229 with SMTP id o92mr14329983qtd.223.1488797610356; Mon, 06 Mar 2017 02:53:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.164.1 with HTTP; Mon, 6 Mar 2017 02:53:29 -0800 (PST) In-Reply-To: References: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> From: Markus Rechberger Date: Mon, 6 Mar 2017 11:53:29 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: Hans Petter Selasky Cc: freebsd-multimedia@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:53:31 -0000 On Mon, Mar 6, 2017 at 11:49 AM, Markus Rechberger wrote: > On Mon, Mar 6, 2017 at 11:34 AM, Hans Petter Selasky wrote: >> On 03/06/17 11:00, Markus Rechberger wrote: >>> >>> even though it's going up and down DVB-T is okay due to the lower >>> bandwidth so something's obviously wrong with the freebsd USB Support. >> >> >> Hi, >> >> Can you provide a usbdump trace and send it to me off-list? >> >> usbdump -i usbusX -f Y -s65536 -w usb_capture.pcap >> >> X and Y are number after ugenX.Y >> >> If you are using ISOCHRONOUS high-speed transfers with an XHCI USB >> controller, the XHCI is much less forgiving about the USB PIDs of the >> multi-data payloads coming from the USB device than the EHCI. I have seen at >> least one DVB-T USB adapter which is totally broken with XHCI and works just >> fine with EHCI. This has been verified with a USB wire analyzer. >> > > I'm using EHCI only. > > Attached you can find the pcap file. > > Please note that DVB-T is okay due to the low bandwidth, only high > bandwidth kicks in immediately with stalled transfers > We have 2 issues so far 1. slow usb control messages - did you already noticed that? 2. high latency bulk requests (I have seen this issue with Linux and MacOSX too if we don't request enough urbs at once) Seems like that double buffering strategy with FreeBSD is a real problem now - of course you cannot have all the hardware out there so that issue might be new for you. From owner-freebsd-multimedia@freebsd.org Mon Mar 6 10:53:54 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D10BFCFB1B3 for ; Mon, 6 Mar 2017 10:53:54 +0000 (UTC) (envelope-from s-4z5b2t25ijp6iqh27g1memwo1g1t832tb0vt9v20r22de99q0l19ub09@bounce.linkedin.com) Received: from maila-da.linkedin.com (maila-da.linkedin.com [IPv6:2620:109:c003:104::137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.linkedin.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C8601C3B for ; Mon, 6 Mar 2017 10:53:51 +0000 (UTC) (envelope-from s-4z5b2t25ijp6iqh27g1memwo1g1t832tb0vt9v20r22de99q0l19ub09@bounce.linkedin.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1488797563; bh=qQLiXaj3/nqJuSOnO8E7w1dcJFJdDCPhz+6zEMWl2lA=; h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class: X-LinkedIn-Template:X-LinkedIn-fbl; b=g9Ur5e4TsWmCW4THT7FbiJjiKoELWMxXkou2JEqHHdULlPJxPRhZ2RsOVvRWaXk14 xXujY5bDPAJHxx4JhShVHrZGMmTvMWuOdlTmJGnKptgKZp5kshjRGkQWs5GwCw9uK7 YK6V+d1jb/hHuFAXLypPzEMJCdfSsU7ZPp441DY0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maila.linkedin.com; s=proddkim1024; t=1488797563; bh=qQLiXaj3/nqJuSOnO8E7w1dcJFJdDCPhz+6zEMWl2lA=; h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class: X-LinkedIn-Template:X-LinkedIn-fbl; b=uMNOG5mywCQBDNLVCnBUaXOFjktuapIHQRX/XKS8UgQ/MGYob+9LsI3GI967YDZmv kCwdhO4GO8Rjdmwxbr4mZJbHbS2ZL6UAroDcFjF1Ms2+F4nt6yJoOEM5MGCekciyoe sJTaXJ59DjRnwx0hb2s667+giYSJYzJeSEMvXRiM= From: LinkedIn Security Message-ID: <524513716.643793.1488797563285.JavaMail.app@lor1-app15086.prod.linkedin.com> Subject: =?UTF-8?Q?Micha=C5=82, _a_new_email_address_was_added_to_your_account?= MIME-Version: 1.0 To: =?UTF-8?Q?Micha=C5=82_Hendzel?= Date: Mon, 6 Mar 2017 10:52:43 +0000 (UTC) X-LinkedIn-Class: ACCT-ADMIN X-LinkedIn-Template: security_add_email_notification X-LinkedIn-fbl: m2-clvfng4hstwb41e2lnslnsbrz6pigp712861jq1se790zmsa4of6jvtol0mlz48r1bhi0nh8gt37bsv0s0rwacyqbdb7i6z2b3c34hm0a1be7d6f8crfaybvdm9km30ea4pmqe6l X-LinkedIn-Id: 4zmfs-izxzmkjj-gf Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 10:53:54 -0000 Hi Micha=C5=82, The email address castorek@vimpsoft.com was recently added to your LinkedIn= account. If you don't want that email associated with your account after all, he= re's how to remove it: Type https://www.linkedin.com/e/v2?e=3D4zmfs-izxzmkjj-gf&lipi=3Durn%3Al= i%3Apage%3Aemail_security_add_email_notification%3Bv4aod%2BaZSm%2BUpisHjAWi= aw%3D%3D&t=3Dnas&midToken=3DAQHLzWiv-C-enw&ek=3Dsecurity_add_em= ail_notification into your browser Sign in with your email address and password Find Primary email in the upper left and click Change/Add Click Remove next to the email address you're removing. Thanks for using LinkedIn and for helping us to keep your account secure. The LinkedIn Team When and where this happened: Date:March 6, 2017, 10:52 AM (GMT) Browser:IE Operating System:Windows Approximate Location:Unknown Didn't do this? Be sure to change your password right away: https://www.lin= kedin.com/e/v2?e=3D4zmfs-izxzmkjj-gf&lipi=3Durn%3Ali%3Apage%3Aemail_securit= y_add_email_notification%3Bv4aod%2BaZSm%2BUpisHjAWiaw%3D%3D&a=3Duas-request= -password-reset&midToken=3DAQHLzWiv-C-enw&ek=3Dsecurity_add_email_notificat= ion =C2=A9 2017 LinkedIn Ireland Unlimited Company. LinkedIn, the LinkedIn logo= , and InMail are registered trademarks of LinkedIn Corporation in the Unite= d States and/or other countries. All rights reserved. This email was intended for Micha=C5=82 Hendzel (System & Software Engineer= at Karl Storz Endoskope GmbH).=20 Learn why we included this: https://www.linkedin.com/e/v2?e=3D4zmfs-izxzmkj= j-gf&lipi=3Durn%3Ali%3Apage%3Aemail_security_add_email_notification%3Bv4aod= %2BaZSm%2BUpisHjAWiaw%3D%3D&a=3DcustomerServiceUrl&midToken=3DAQHLzWiv-C-en= w&ek=3Dsecurity_add_email_notification&articleId=3D4788 If you need assistance or have questions, please contact LinkedIn Customer = Service: https://www.linkedin.com/e/v2?e=3D4zmfs-izxzmkjj-gf&lipi=3Durn%3Al= i%3Apage%3Aemail_security_add_email_notification%3Bv4aod%2BaZSm%2BUpisHjAWi= aw%3D%3D&a=3DcustomerServiceUrl&midToken=3DAQHLzWiv-C-enw&ek=3Dsecurity_add= _email_notification LinkedIn is a registered business name of LinkedIn Ireland Unlimited Compan= y. Registered in Ireland as a private unlimited company, Company Number 477441 Registered Office: Wilton Plaza, Wilton Place, Dublin 2, Ireland From owner-freebsd-multimedia@freebsd.org Mon Mar 6 11:05:09 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EFF8CFB50D for ; Mon, 6 Mar 2017 11:05:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22819127D for ; Mon, 6 Mar 2017 11:05:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 612351FE086; Mon, 6 Mar 2017 12:04:37 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger References: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> Cc: freebsd-multimedia@freebsd.org From: Hans Petter Selasky Message-ID: <9d940886-5021-7208-fc19-477dcd573c7a@selasky.org> Date: Mon, 6 Mar 2017 12:04:19 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:05:09 -0000 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 > status 0x6a023 > 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 > status 0x8a025 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); --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 11:14:13 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C02EFCFB906 for ; Mon, 6 Mar 2017 11:14:13 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7951516CF for ; Mon, 6 Mar 2017 11:14:13 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x22d.google.com with SMTP id p64so28727687qke.1 for ; Mon, 06 Mar 2017 03:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ai0oj2C/9aieTHHKPT2djplwyIA3GQgsFoXlJH6t/I0=; b=c/CrxSWq/dV1pCgV/537f/4f9gJ4/VvtOIpd0FfDON3+enl2gkmVk4+L98c6rxsG+O 7lEwSSm15oSrOIbjrwYTB+nLP0DD5mHa4qGgT+gKThRZwvHx0IA318RKnbBPYSa2G6st 4JVOk+5uneT0YUHRbMUGJE7nXHm84x9NHdywfGWSLRwgoeVIuDhoOUjzx85YDNo9gO3F i9CgRCi/jlCQNqSw5h++6Uq+KRCF0dx3kix99MZ1+9bP1kV1njh+3eVDFPmIkByeyq2U wzDziqxhYhGOiIvobH0bFM7s8d/AdSv2nny3nY2K+wIKd37oTM/Q7wjFeijXttgpt1/9 fpMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ai0oj2C/9aieTHHKPT2djplwyIA3GQgsFoXlJH6t/I0=; b=BkHtfEfBBEdp1YPrsYm1D/bGGfFq0ZS/RgmahKm1X5O3GiLedwcqh0jmdufUtmURH4 Gr6WVfh8pxWXwnAfl2ZcPTr3FsRFyJroHuIh6xrhLWem8vnS9/HmcHmt6CF81NOwnSt/ 70qYsjqxmJv7an8hnYHdmorbADWYierw/jTUpQ4F49VrBCriVXNPB7PSRSimfRPUPvM4 BhnHz7PMDojqKOgOKwoE8uVeVrpE2o908dvb5b9VJSu1S2zc3DkxVyk7rhaFws64Bpif j1sA2TjTgGLXQOaZS1sQb2UqBXjfSUAmd3RHx+G1J57RYKNt/eun4wuQ9Mc/FTgwVtSu O70A== X-Gm-Message-State: AMke39mge8JpKaWG4wLrEPcyOYV/zxdHNBUlQ1uwToiH1rrZQsq2a/AGUTmohH1D+xdywYDKLf9NFip7XGuNvg== X-Received: by 10.55.44.197 with SMTP id s188mr14048847qkh.131.1488798852713; Mon, 06 Mar 2017 03:14:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Mon, 6 Mar 2017 03:14:12 -0800 (PST) In-Reply-To: <9d940886-5021-7208-fc19-477dcd573c7a@selasky.org> References: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> <9d940886-5021-7208-fc19-477dcd573c7a@selasky.org> From: Markus Rechberger Date: Mon, 6 Mar 2017 12:14:12 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: Hans Petter Selasky Cc: freebsd-multimedia@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:14:13 -0000 On Mon, Mar 6, 2017 at 12:04 PM, Hans Petter Selasky 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 >> status 0x6a023 >> >> 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 >> status 0x8a025 >> > > > 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 From owner-freebsd-multimedia@freebsd.org Mon Mar 6 11:31:26 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C287ECFBC86 for ; Mon, 6 Mar 2017 11:31:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5830A1DCC for ; Mon, 6 Mar 2017 11:31:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 448D21FE087; Mon, 6 Mar 2017 12:30:54 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger References: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> Cc: freebsd-multimedia@freebsd.org From: Hans Petter Selasky Message-ID: <9fe561d0-3d8b-8725-98d4-37c2eb094ae9@selasky.org> Date: Mon, 6 Mar 2017 12:30:36 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:31:26 -0000 Hi, On 03/06/17 11:53, Markus Rechberger wrote: > 1. slow usb control messages - did you already noticed that? From what I can see no USB control transfer completed no later than 1.555 milliseconds. I loaded the numbers in the trace into a spreadsheet and got the attached distribution. This is not slow. What times do you expect? The fastest XHCI can do is ~ 0.125 ms and from the analysis is appears that the USB device is NAKing a little bit, causing the extra delay. --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 11:36:37 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9019BCFBE56 for ; Mon, 6 Mar 2017 11:36:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5835F1075 for ; Mon, 6 Mar 2017 11:36:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 075F11FE086; Mon, 6 Mar 2017 12:36:05 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger References: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> <9d940886-5021-7208-fc19-477dcd573c7a@selasky.org> Cc: freebsd-multimedia@freebsd.org From: Hans Petter Selasky Message-ID: <599369d4-5458-a61c-e28d-762c86e65a4b@selasky.org> Date: Mon, 6 Mar 2017 12:35:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:36:37 -0000 On 03/06/17 12:14, Markus Rechberger wrote: > On Mon, Mar 6, 2017 at 12:04 PM, Hans Petter Selasky 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 >>> status 0x6a023 >>> >>> 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 >>> status 0x8a025 >>> >> >> >> 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 From owner-freebsd-multimedia@freebsd.org Mon Mar 6 11:36:59 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30300CFBE7D for ; Mon, 6 Mar 2017 11:36:59 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCFD010B8 for ; Mon, 6 Mar 2017 11:36:58 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id v125so86847534qkh.2 for ; Mon, 06 Mar 2017 03:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=muugufQJxmbgkedeP0d4uhto2WdSrZqxwP6bIn8Jo9o=; b=nZMa/BQedhcMyLYcpuv6gprh0YNw64TfsBjtOR2YLDFJ6XGn47fEGvOB2kab+Dxb6q VshDrKmMKf3mpDIWr+XWXcPqbJIhzpgxhrenjyXa+SksaSQzVXmTfi+1kw+5o92mGUkS +OMh51wiCTw+OKXdOKJ/xLV6vpLvmIPLenzhmbrL7mVcB/U9xvzcmEqWAtrN/wM/S0fA WRrcO266/Svpm1KFcDC24gGefdR7ymeefGQvMJs0ukVDWWhH7N5OjmUywwtVUNC9VYM/ 1xEDFg+RI71Hg/11f/CAAnX1BeEILa4m846cbq/IijT2AxTPEHcfK4ORY3+cTjLscpHn gFnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=muugufQJxmbgkedeP0d4uhto2WdSrZqxwP6bIn8Jo9o=; b=E5iKxoTwTSQtGqquM5NL+5Qhsa5Q6YnW/fc9nGiLRLrunxney9/C1xzzthWzTGWp0D NbmW1CL8cSMlSK8/6AncxhHhpgkRKyiV/re8KHIJAc6ToGgCPgmvIe1Nm+xNkAW1ur6i PA8D49P1zGIfGNCl29Dse4JgsF6r4HwvVSW+1GSkKxhnIoBX82CPjqe7ZqtD8pPEaDXJ sM4ADmr73D1Xow5kmXojPJSeGPNAjHsNoD9KF034y/cRDLEHqRHIcgiC5R57VqsFT2Ql aKO6PMJwntmsegfs06zGGvk/WWKyB3W5iqyqbEYbdwFOCckRbTwGxg7Tg9Jp0AxRiyDa GFDA== X-Gm-Message-State: AMke39mg4xElvaOFbQV71m2JkMMBBsKgbNi8KlVExhP+jB8k/2G2fh+IAN53fsHQmhqT8nWzh3sCy/7+rATM/Q== X-Received: by 10.55.47.4 with SMTP id v4mr14648727qkh.77.1488800218135; Mon, 06 Mar 2017 03:36:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Mon, 6 Mar 2017 03:36:57 -0800 (PST) In-Reply-To: <9fe561d0-3d8b-8725-98d4-37c2eb094ae9@selasky.org> References: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> <9fe561d0-3d8b-8725-98d4-37c2eb094ae9@selasky.org> From: Markus Rechberger Date: Mon, 6 Mar 2017 12:36:57 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: Hans Petter Selasky Cc: freebsd-multimedia@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:36:59 -0000 On Mon, Mar 6, 2017 at 12:30 PM, Hans Petter Selasky wrote: > Hi, > > On 03/06/17 11:53, Markus Rechberger wrote: >> >> 1. slow usb control messages - did you already noticed that? > > > From what I can see no USB control transfer completed no later than 1.555 > milliseconds. I loaded the numbers in the trace into a spreadsheet and got > the attached distribution. > > This is not slow. What times do you expect? > > The fastest XHCI can do is ~ 0.125 ms and from the analysis is appears that > the USB device is NAKing a little bit, causing the extra delay. > it's EHCI, but the driver needs 14 seconds to load everything with freebsd (ok there's a lot to send) but the other systems are all way faster with that (7 seconds max for initialising 4 chipsets). I somewhat think that this issue also has to do with the bulk latency killing the data transfer. Maybe the actual send is quick but maybe there's some additional libusb20 - usb userspace interface - usb - roundtrip problem that causes this high latency. From owner-freebsd-multimedia@freebsd.org Mon Mar 6 11:41:38 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 377CDCFBFE9 for ; Mon, 6 Mar 2017 11:41:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F05C6132F for ; Mon, 6 Mar 2017 11:41:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0D05F1FE086; Mon, 6 Mar 2017 12:41:06 +0100 (CET) Subject: Re: What is wrong with FreeBSD and USB Support To: Markus Rechberger References: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> <9fe561d0-3d8b-8725-98d4-37c2eb094ae9@selasky.org> Cc: freebsd-multimedia@freebsd.org From: Hans Petter Selasky Message-ID: Date: Mon, 6 Mar 2017 12:40:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:41:38 -0000 Hi, On 03/06/17 12:36, Markus Rechberger wrote: > libusb20 - usb userspace interface - usb - roundtrip problem that > causes this high latency. If you are using an old FreeBSD kernel, more than two years old, there was an issue where malloc() was used in the generic IOCTL path. This piece has in later versions of FreeBSD been replace with a conditional on-stack buffer. If you have this issue you should see high CPU usage on one of the CPU cores while doing USB transfers fast. --HPS From owner-freebsd-multimedia@freebsd.org Mon Mar 6 11:42:52 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DA43CFB02A for ; Mon, 6 Mar 2017 11:42:52 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 470691465 for ; Mon, 6 Mar 2017 11:42:52 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x236.google.com with SMTP id 1so148406336qkl.3 for ; Mon, 06 Mar 2017 03:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ITSlQTEUAHxiGIh09LkSU2D/vbDkkrg2HrOZmLbjUpY=; b=qaSVLanV1n1ndASEbHOW57+o0vAyPcl08D2H3O+Cc+fjG90bziYTz9XkN5nI9QZwdU FjEvqU0xIoJejxMnDTkvVRY1pFuV4p9WcGAboRQwYaW2QladoeIKlQSPByQiU267QGrr k4rslZT8AxLrCWWPb99OXZ8klswTcObNSypSRYGgDiJL5Yozb+SrwE8STcO5v6jBxBxu uDEpDbZ75n0xHfeqUUNc9mJBBiug/KjnNNtsWV3YKH9uL4dpoHZ52k0WBC8ZHXEhDZg9 D6v6V5ZfMpCPYhWnDAd2Dsqp2kukVTlOqnGKlWUfFL7d5g+v9Z51sBUgS8orOODLEvQz bCZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ITSlQTEUAHxiGIh09LkSU2D/vbDkkrg2HrOZmLbjUpY=; b=XWp59uenqfPS/vpuSzwqLKwplqpUE541v9uLEpBYH6TKi5kLCQHZ9C4zaMaMyj0/Rf U0bwszdxsGNcmAByd3QewxI+Rtoo0spOupHnv1tNP8Inzdejb6uINTKntXP7XdVo+DzW spjfiW15pos+7eLs51TvQ2quZvTE6yGoG96zLG4s1kUtQTZYsnMe+l1CVbkXsDlZa2+/ E6m0tTgq9YdwzleDw1bLJbX547cY6iiFS25UJ3TlKyg+bvufXfNR3AFU47xiHPEVWah3 7MvYE2roT0WNHB+jEZI4a7ejVACjzeqTFG66ovic/MWJYMYdcSJY/9Zu4L2tOWcV/+Su GIlQ== X-Gm-Message-State: AMke39kCEdv3u5r89DC5njQ8mn9+eN+Gvxmcrmh9qIccoe3nlKMeayzlDYod4HyJSr8lLE5npO52AmmEGfSTuQ== X-Received: by 10.237.41.229 with SMTP id o92mr14502776qtd.223.1488800571434; Mon, 06 Mar 2017 03:42:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Mon, 6 Mar 2017 03:42:50 -0800 (PST) In-Reply-To: References: <1aff0983-deb6-2884-472c-bb1e1037275c@selasky.org> <9fe561d0-3d8b-8725-98d4-37c2eb094ae9@selasky.org> From: Markus Rechberger Date: Mon, 6 Mar 2017 12:42:50 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: Hans Petter Selasky Cc: freebsd-multimedia@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:42:52 -0000 On Mon, Mar 6, 2017 at 12:40 PM, Hans Petter Selasky wrote: > Hi, > > On 03/06/17 12:36, Markus Rechberger wrote: >> >> libusb20 - usb userspace interface - usb - roundtrip problem that >> causes this high latency. > > > If you are using an old FreeBSD kernel, more than two years old, there was > an issue where malloc() was used in the generic IOCTL path. This piece has > in later versions of FreeBSD been replace with a conditional on-stack > buffer. If you have this issue you should see high CPU usage on one of the > CPU cores while doing USB transfers fast. > I'm using FreeBSD 11 the latest one.