-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to claim interface multiple times #16
Comments
Please post the code here, Thanks. You can even enable syntax highlighting using the github markdown syntax. |
The original thread in libftdi mailing list. With libusbK.dll, the test program (with libftdi) will fail to autoclaim. libusb: warning [winusbx_claim_interface] failed to auto-claim interface 0 |
Here's an example program the will fail after 32 opens when using libusbK. If you use WinUSB (with no libusbK dlls on the system) it will performt he open all 50 times. I noticed this issue under libFTDI trying to open Interface B multiple time; this code also appears to fail opening Interface A. The logic of the code is taken from the logic of libFTDI. Steve
|
Could you post the running log after setting LIBUSB_DEBUG environment variable to be 4? It will be quite a long log but you only need to post the logs containing the initial device list, the 1st successful open and the first failed open. |
Somehow I could not run your program under Mac OS X 10.9.3 (can not find device). However, I can run your program under Windows 8.1 x64 and reproduce the issue (with 0403:cff8 device). Open count 1 of 50
|
The above is the debug log with libusb-1.0.18 release, I think it will be similar for latest git as well. |
Since you were able to recreate the issue, do you still want me to post And I did see that same error for both 1.0.18 and 1.0.19-rc2. Steve |
I think you do not need to post your debug unless you see major differences between my debug log and yours. Thanks. |
Still I think your libusb test program has some problems, it causes segmentation fault with the first open already under Ubuntu Linux 14.04 and also quit in the first open with no device find under Mac OS X 10.9.3. So probably there is a problem somewhere in the test program. |
On the other hand, the original libftdi test program seems to be okay under Ubuntu Linux 14.04 and Mac OS X 10.9.3. |
Just so you know, I am not planning to look into this, so hopefully someone else can. |
Sorry for the late reply; all my code and devices were in the office. I just ran the test under Fedora 20 x64 with no problems; not sure However, the problem is not with the Linux environment - as I mentioned, The problem is only showing up under Windows; and then only when libusbK I'm not sure if this points to an issue with libusbK or not; I don't Not sure if this helps any or just confuses the matter; at this point I Steve |
Just want to add that now I can run your test program under Mac OS X. I need to add " i = 0;" before the following two lines. Maybe it is because of C compiler thingy. After that, there is no problem running this test program under Mac OS X. // find our device |
Same thing, once I add that line, it is okay under Ubuntu 14.04. |
And of course it does not change the results under Windows 8.1. The same error happens, no matter it is Interface A or B. |
I enable libusbK.dll debugging and found out that there are many warnings, no so sure if this is a problem or not.
|
"If I install my Windows drivers as WinUSB and don't have libusbK in the path, I can open the device 50 times without any problems. With libusbK in the path, it fails after 32 tries"
quote from wikipedia http://en.m.wikipedia.org/wiki/WinUSB |
* issue libusb#16 "Unable to claim interface multiple times" * interface 0 is auto-claimed on windows when other interfaces are claimed, but it wasnt released along with the other interface
If anyone needs a quick hack fix for this issue, you can use the commit here: rabryan@473e2ec This issue stems from the fact that interface 0 is auto-claimed on windows when interfaces 1 and higher are claimed, but when those interfaces are explicitly released the auto-claimed interface 0 is not released. The commit above fixes this issue, but also introduces a bug whenever interface 0 and 1 are explicitly claimed but then the user only releases interface 1. In that case, interface 0 will be auto-released erroneously. So as long as that use case doesn't apply for you, the commit above will work fine. |
* issue libusb#16 "Unable to claim interface multiple times" * interface 0 is auto-claimed on windows when other interfaces are claimed, but it wasnt released along with the other interface
Hi, Please try the patch below and see if that resolves the issue you are observing. Regards,
|
Hi Chris, I want to test out this patch but it does not seem to apply to current git Could you please generate a new patch? Thanks. Regards, |
Hmm, it appears that it doesn't apply cleanly because the whitespace is all messed up. Please access the patch file from here: https://drive.google.com/file/d/0B21dl58QIZY-NGpLWExOSEhHdDg/view Regards, |
Thanks. Now the patch applies cleanly on top of git master. However, it Xiaofan |
This problem may be an bug in libusbK. Apparently, simply closing the device handle (the one from CreateFile) is not sufficient as libusbK does not release resources properly. |
On Sun, Jan 11, 2015 at 3:56 PM, Chris Dickens notifications@github.com
Hi Chris, The patch seems to break the build since "handle" is not defined, probably Xiaofan |
On Sun, Jan 11, 2015 at 4:02 PM, Chris Dickens notifications@github.com
Thanks. I will relay this message to Travis. And yes your patch indeed fixed the problem after I fixed the build issue. Xiaofan |
Sorry about that...too much concurrent development. Fix has been applied. Regards, On Sun, Jan 11, 2015 at 2:14 AM, Xiaofan Chen xiaofanc@gmail.com wrote:
|
This updates libusb1 from 1.0.19 to 1.0.20 2015-09-13: v1.0.20 * Add Haiku support * Fix multiple memory and resource leaks (#16, #52, #76, #81) * Fix possible deadlock when executing transfer callback * New libusb_free_pollfds() API * Darwin: Fix devices not being detected on OS X 10.8 (#48) * Linux: Allow larger isochronous transfer submission (#23) * Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings * Windows: Fix broken bus number lookup * Windows: Improve submission of control requests for composite devices * Examples: Add two-stage load support to fxload (#12) * Correctly report cancellations due to timeouts * Improve efficiency of event handling * Improve speed of transfer submission in multi-threaded environments * Various other bug fixes and improvements The (#xx) numbers are libusb issue numbers, see ie: libusb/libusb#16 Signed-off-by: Jens Rehsack <sno@netbsd.org> Signed-off-by: Ross Burton <ross.burton@intel.com>
add experimental SunOS backend support adapted from the upstream RTI submission from Oracle and initial illumos support from OpenIndiana/Hipster From the Changelog: For detailed information about the changes below, please see the git log or visit: http://log.libusb.info 2015-09-13: v1.0.20 * Add Haiku support * Fix multiple memory and resource leaks (#16, #52, #76, #81) * Fix possible deadlock when executing transfer callback * New libusb_free_pollfds() API * Darwin: Fix devices not being detected on OS X 10.8 (#48) * Linux: Allow larger isochronous transfer submission (#23) * Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings * Windows: Fix broken bus number lookup * Windows: Improve submission of control requests for composite devices * Examples: Add two-stage load support to fxload (#12) * Correctly report cancellations due to timeouts * Improve efficiency of event handling * Improve speed of transfer submission in multi-threaded environments * Various other bug fixes and improvements The (#xx) numbers are libusb issue numbers, see ie: libusb/libusb#16 MAKE_JOBS_SAFE=no given build issues when enabled.
* libusbK (as of v3.0.7.0) will fail after 32 opens because resources from claimed interfaces are not freed by simply closing just the device handle * Closes libusb#16 Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
This updates libusb1 from 1.0.19 to 1.0.20 2015-09-13: v1.0.20 * Add Haiku support * Fix multiple memory and resource leaks (#16, #52, #76, #81) * Fix possible deadlock when executing transfer callback * New libusb_free_pollfds() API * Darwin: Fix devices not being detected on OS X 10.8 (#48) * Linux: Allow larger isochronous transfer submission (#23) * Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings * Windows: Fix broken bus number lookup * Windows: Improve submission of control requests for composite devices * Examples: Add two-stage load support to fxload (#12) * Correctly report cancellations due to timeouts * Improve efficiency of event handling * Improve speed of transfer submission in multi-threaded environments * Various other bug fixes and improvements The (#xx) numbers are libusb issue numbers, see ie: libusb/libusb#16 (From OE-Core rev: 641a9454fbb25f1458bb8f96cbfada3e0da98dee) Signed-off-by: Jens Rehsack <sno@netbsd.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When performing multiple open/close cycles and claiming an interface, libusbK fails after 32 times with Access Denied error.
This error was found during unit testing of my code using libFTDI; further testing using only libusb 1.0.19-rc2 code reproduces the error. This happens under Win8.1 x64; USB drivers are installed using libusbK-inf-wizard. If I install only the libusbK driver, the problems occurs. I've installed the driver on both the composite device (an FT2232H chip) and on Interface A; the error occurs either way.
If I install the WinUSB driver, the problem occurs... but if you then remove the libusb0 and libusbK dll files (installed by the inf-wizard) and only use the WinUSB driver the error does not occur.
I have a sample program to demonstrate the issue; not sure how to attach it here though. Let me know if you need additional info...
Steve
The text was updated successfully, but these errors were encountered: