Re: [Discuss-gnuradio] Unable to find USRP

[Berndt Josef Wulf]

On Sunday 15 May 2005 11:28, Eric Blossom wrote:
> On Sun, May 15, 2005 at 10:13:03AM +0930, Berndt Josef Wulf wrote:
> > > This is similar to the problem I had with the audio device that doesn't
> > > permit it to be opened by two or more processes, see the lines
> > > containing EBUSY. I will try to figure out which part of
> > > benchmark_usb.py doesn't close the ugen device.
> >
> > The problem is that benchmark_usb.py opens usrp.sink() and usrp.source(),
> > both which use the open() calls to access the device. On *BSD this is not
> > possible and is exactly the some problem as seen with the audio.sink()
> > and audio.source() function that I hacked around.
> >
> > A possible generic solution to this is to acquire the filedescriptor for
> > the device which is then used by the subsequent calls. e.g.:
> >
> > usrp_dev = usrp.open()   <- instantiate device
> > sink = usrp.sink(usrp_dev, ....)  <- open source
> > source = usrp.source(usrp_dev, .....) <- open sink
> >
> > similar for other sink/source devices that are used with GnuRadio.
> >
> > Else, *BSD will not be able to run scripts that use sink and source of
> > the same device simultaneously..
> >
> > cheerio Berndt
>
> My humble suggestion is that somebody fix the NetBSD libusb
> implementation, or if that isn't possible, then fix the usb ugen
> device driver.  If what you describe is true, it's totally asinine
> that different processes can't open different end points of a given
> USB device.  What purpose does such a limitation serve?  Instead of
> trying to work around broken code, fix the broken code.
>
> We do expect to be able to open end point 0, the designated usb
> control endpoint, by more than one processes.  It's how we configure
> the USRP.  The Rx code is smart enough to only mess with Rx related
> settings, and likewise for the Tx code.
>
> If the ugen driver has code that forces exclusivity, it ought to be
> simple enough to remove it (at least on end point 0).  Search for
> EBUSY in the driver source.  It's probably in the first 10 lines of
> the open routine.
>
> Eric

Thanks for your help. On inspection of the ugen device driver I can confirm 
that it implements exclusive access to the control endpoint. After modifying 
the driver to allow multiple access to the control endpoint benchmarks_usb.py 
works fine.

I'm not familiar with the USB specifications, but from what you're saying did 
I understand you correctly that multiple access to USB Control Endpoints is 
permissible, but access to other endpoints are exclusive to one process? If 
so, we just found a bug in the kernel.

In any case, I'm happy to report that, using a modified kernel, the benchmark 
utility is working now.

cheerio Berndt
-- 
Every man who says frankly and fully what he thinks is doing a public service.
[Leslie Stephen]