LIBUSB_ERROR_PIPE and "improperly" stopping gnuradio

Hello all,

I am facing a strange problem when I am starting my gnuradio script. I
keep
getting the following message.

– Operating over USB 3.

Traceback (most recent call last):
File “file_sinks.py”, line 104, in
tb = file_sinks()
File “file_sinks.py”, line 47, in init
channels=range(2),
File
“/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/init.py”,
line 122, in constructor_interceptor
return old_constructor(*args)
File
“/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py”,
line 1753, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: usb rx8 submit failed: LIBUSB_ERROR_PIPE

I have been receiving this error while executing UHD scripts, GRC
flowgraphs and python scripts. As an example, the latest python script
that
I have developed looks like this:

tb = file_sinks()
try:
    while(True):
        raw_input('Press any key to begin..')
        tb.start()
        raw_input('Press any key to stop..')
        tb.stop()
        tb.blocks_file_source_0.seek(0,0)
        tb.wait()
except (KeyboardInterrupt):
    tb.stop()
    tb.blocks_file_source_0.seek(0,0)
    tb.wait()
    sys.exit()

In order to stop the script I issue a ctrl-c to the terminal and as you
can
see I manage the correspinding interrupt by properly stopping the
top_block. However, the next time I execute the script I get the
aforementioned error.

This error occurs even in simple GRC flow graphs whenever I press the
stop
button. However if I just close the WX window that pops up, I wont get
it
the next time I execute my script.

The only way to avoid this error in a future execution is to remove and
re-insert the usb cable from the computer. My intuition is that it is a
low-level driver problem but I cannt really figure out what’s going on,
let
alone fix it.

Removing and re-inserting the USB cable as one can imagine is quite
discomforting so any suggestions on how to approach this are more than
welcome.

My setup is the following:
Macmini Late 2012, OSX 10.9.5 gnuradio 3.7.5.1


Eleftherios(Lefteris) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
mail: [email protected]

Hi Lefteris,

does the same happen when you just press any key instead of killing the
script?

Greetings,
Marcus

Hello

Thank you for your reply.

No it happens only when I kill the script. let me give you another
example. I have a flowgraph in GRC that looks like this:

USRP source → USRP sink

I connect the B210 to the macmini via USB3 and press the “execute the
flow
graph” button. The script is executed ok.
I stop it using the “Kill the flowgraph” button and run it again. I get
the
follwoing message on the GRC console:

------------------------------------------------FIRST
EXECUTION------------------------------------------------
Mac OS; Clang version 6.0 (clang-600.0.54); Boost_105600;
UHD_003.007.003-0-unknown

– Operating over USB 3.
– Initialize CODEC control…
– Initialize Radio control…
– Performing register loopback test… pass
– Performing register loopback test… pass
– Performing CODEC loopback test… pass
– Performing CODEC loopback test… pass
– Asking for clock rate 32.000000 MHz
– Actually got clock rate 32.000000 MHz
– Performing timer loopback test… pass
– Performing timer loopback test… pass

Done

------------------------------------------------SECOND
EXECUTION------------------------------------------------

Generating: “/Users/kampianakis/Desktop/top_block.py”

Executing: “/Users/kampianakis/Desktop/top_block.py”

Mac OS; Clang version 6.0 (clang-600.0.54); Boost_105600;
UHD_003.007.003-0-unknown

– Operating over USB 3.
Traceback (most recent call last):
File “/Users/kampianakis/Desktop/top_block.py”, line 78, in
tb = top_block()
File “/Users/kampianakis/Desktop/top_block.py”, line 35, in init
channels=range(1),
File
“/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/init.py”,
line 122, in constructor_interceptor
return old_constructor(*args)
File
“/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py”,
line 1753, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: usb rx8 submit failed: LIBUSB_ERROR_PIPE

After this point the only thing that I can do is remove and re-insert
the
USB from the computer in order for my script to work. I assume this is
not
normal behavior (and also not a programming error) because this is a
minimum working example, and its not working.

Best regards
Lefteris

On Tue, Nov 4, 2014 at 6:40 PM, Eleftherios(Lef) Kampianakis <
[email protected]> wrote:

tb = file_sinks()

RuntimeError: RuntimeError: usb rx8 submit failed: LIBUSB_ERROR_PIPE
raw_input(‘Press any key to stop…’)

re-insert the usb cable from the computer. My intuition is that it is a


Eleftherios(Lefteris) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
http://users.isc.tuc.gr/~ekabianakis/
mail: [email protected]

Sylvain thank you for your reply,

Ok, what about the python script in my previous message? How can I write
my
code in order to prevent the LIB_USB_ERROR_PIPE message. No matter how I
stop the gnuradio script (e.g. catch keyboard interrupt and issue stop()
and wait as in my original post), I always get the same message. My
intuition due to that is that something is not cleaned up properly in
UHD
level. Any suggestions on that?

Best regards
Lefteris

On Wed, Nov 5, 2014 at 12:52 PM, Sylvain M. [email protected]
wrote:

(SIGKILL), a process cannot catch this signal, nor do anything about
it (i.e. not a single instruction of gnuradio will execute after this)

At this point, it’s up to the operating system to clean up any state
of the process …

Cheers,

Sylvain


Eleftherios(Lefteris) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
http://users.isc.tuc.gr/~ekabianakis/
mail: [email protected]

Hi,

Ok, what about the python script in my previous message? How can I write my
code in order to prevent the LIB_USB_ERROR_PIPE message. No matter how I
stop the gnuradio script (e.g. catch keyboard interrupt and issue stop() and
wait as in my original post), I always get the same message.

Yes, CTRL-C sends a SIGSTOP which can be caught and so proper clean-up
is possible. (although obviously not happenning).

My intuition
due to that is that something is not cleaned up properly in UHD level. Any
suggestions on that?

Not really no.

It’s either in UHD, in libusb, in the OS, or even possibly in the FX3
firmware which is a pretty large area to search for a bug.

Whatever a userspace sw does, it should not be able to lockup access
to a device. When the process exits, all should be cleaned up by the
OS. So I’d look in the lower levels first.

Not so long ago, on linux with bladerf, doing sig-kill actually
triggered a but that caused a kernel panic IIRC … so you see
unplug/replug is not that bad :stuck_out_tongue: USB3 is still quite new and a lot of
stuff is still buggy.

Cheers,

Sylvain

After this point the only thing that I can do is remove and re-insert the
USB from the computer in order for my script to work. I assume this is not
normal behavior (and also not a programming error) because this is a minimum
working example, and its not working.

There is literally nothing GNURadio can do about this.

When you press the ‘red cross’ button, it kills the whole process
(SIGKILL), a process cannot catch this signal, nor do anything about
it (i.e. not a single instruction of gnuradio will execute after this)

At this point, it’s up to the operating system to clean up any state
of the process …

Cheers,

Sylvain

Lefteris,

 If your flowgraph doesn't have a GUI element, you can right click

on the Top Block icon and select Quit.

Ron

Hi Lefteris,

I still don’t know why you kill the process. GNU Radio waits for any
key, and pressing anything but ctrl-C should let the flow graph shut
down correctly, in turn deallocating the UHD sources/sinks, which should
free the libusb device handles.

Greetings,
Marcus

I still don’t know why you kill the process. GNU Radio waits for any
key, and pressing anything but ctrl-C should let the flow graph shut down
correctly, in turn deallocating the UHD sources/sinks, which should free the
libusb device handles.

ctrl-c sends a SIGINT (and not SIGSTOP like I said earlier … my bad
and thanks for ahuemer for pointing it out on IRC :p).

This means that if the GR process is in a system call at that time,
that syscall will be interrupted and return -EINTR and my guess is
someone, somewhere isn’t dealing with that properly.

Cheers,

Sylvain

Thanks again for your (rapid) response!

  1. I think there should be somekind of bug report on that although I
    dont
    really know how to do this

  2. I was thinking of a workaround through lsmod (similar to modprobe in
    linux) to emulate the removal and re-insertion of USB, this way I could
    write a simple script and avoid the physical procedure which prohibits
    remote control of the USRP host. Any ideas on that?

  3. When I execute a flowgraph that contains a WXGUI element and close
    the
    python window instead of killing the flowgraph, I can issue a next
    execution without problems. What’s happening then and how can I use this
    for my
    purposes?

Best regards,
Lefteris

On Wed, Nov 5, 2014 at 2:00 PM, Sylvain M. [email protected] wrote:

is possible. (although obviously not happenning).
firmware which is a pretty large area to search for a bug.
Cheers,

Sylvain


Eleftherios(Lefteris) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
http://users.isc.tuc.gr/~ekabianakis/
mail: [email protected]