LIBUSB_ERROR_BUSY

[ekoloski]

Hi,

I've been running into some trouble getting my bladeRF up and running on CentOS. I am at a point where libbladeRF is compiled and installed, as are the bladeRF-cli and flash utilities. The bladeRF kernel mod is compiled and installed as well, although I did have to modify the code slightly in order to make it play nice with 2.6.32-431.20.3 - not sure if this broke anything. Specifically, usb_alloc_coherent and usb_free_coherent had to be changed to usb_buffer_alloc and usb_buffer_free respectively. Libusb-1.0.18 was also compiled as a shared library, as the latest I could find in any repo was 1.0.9. The bladeRF has the latest precompiled fx3 image, and the latest precompiled hostedx115 image being loaded automatically.

The bladeRF is recognized by the system when attached, I've tried SS ports and standard USB2 with the same results:

usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
usb 4-1: Parent hub missing LPM exit latency info. Power management will be impacted.
usb 4-1: New USB device found, idVendor=1d50, idProduct=6066
usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 4-1: Product: bladeRF
usb 4-1: Manufacturer: Nuand
usb 4-1: SerialNumber: 5e3f22194ff04d15410af081********
usb 4-1: configuration #1 chosen from 1 choice
nuand_bladerf 4-1:1.0: Nuand bladeRF device is now attached

After attaching the device, the udev rule never seems to apply:

$ ls -la /dev | grep bladerf
crw-rw----. 1 root root 180, 193 Jun 28 09:35 bladerf0

I have been manually setting the group on the dev node for now as a quick and dirty workaround.

In bladeRF-cli I am able to see the libusb backend just fine:

No device(s) attached.
bladeRF> probe

Backend: libusb
Serial: 5e3f22194ff04d15410af081********
USB Bus: 4
USB Address: 3

This is where the fun stops though. Any attempt to probe for more information or open the device fails, verbose mode gives me the following error:

[VERBOSE] Using libusb version: 1.0.18.10866
[VERBOSE] Found a bladeRF (based upon VID/PID)
[DEBUG] Could not claim interface: LIBUSB_ERROR_BUSY

Interestingly enough, I can pass the bladeRF through to a windows VM on this same machine. While this works for testing, USB2 is not enough for me and Virtualbox has issues with USB3.

I'm wondering what could cause this busy error, does libusb_detach_kernel_driver() need to be called before attempting to claim the interface?

Has anyone out there tried to install bladeRF on CentOS 6 with any luck? Any assistance is greatly appreciated.

[jynik]

Hi ekoloski,

Sorry for the confusion -- don't use the kernel driver for now.

It's severely out of date and has a number of known issues. It was put on the "back burner" while libusb support was integrated into the codebase, as this allowed for efforts to yield cross-platform compatibility. Recently, there has been work done to decouple the USB interface code from the core libbladeRF logic, which will allow a user to select different "backends." There are plans to overhaul and clean up the kernel module in the future however, with some low-latency applications in mind (from my understanding, at least.) When this happens, I believe you are correct that we will need a libusb_detach_kernel_driver(), as your experience here shows.

So in short, unload the kernel module and libusb should take care of the rest. If you're building from source, the Getting Started: Linux guide should cover the entirety of what's needed.

Out of curiosity, was there something you read that lead you to use that kernel driver? If so, we should fix that documentation.

- Jon

[ekoloski]

That did it, I removed the kernel driver and the bladeRF is now showing up and working as expected. Thank you!

This one is my fault, not a flaw in the docs. The last time I had built the bladeRF source was before all the libusb stuff, I had followed the same general steps this time as I had back then.