# LIBUSB\_ERROR\_PIPE and "improperly" stopping gnuradio **URL:** \ **Category:** GNU Radio\ **Created:** [November 5, 2014, 3:41am UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924 "2014-11-05T03:41:47Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [November 5, 2014, 3:41am UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/1 "2014-11-05T03:41:47Z")
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/](http://staff.washington.edu/ekampian/) mail: removed\_email\_address@domain.invalid ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 5, 2014, 9:23am UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/2 "2014-11-05T09:23:05Z")
Hi Lefteris, does the same happen when you just press any key instead of killing the script? Greetings, Marcus ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 5, 2014, 9:46pm UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/3 "2014-11-05T21:46:59Z")
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 \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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://staff.washington.edu/ekampian/) [http://users.isc.tuc.gr/~ekabianakis/](http://users.isc.tuc.gr/~ekabianakis/) mail: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 5, 2014, 10:55pm UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/4 "2014-11-05T22:55:01Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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://staff.washington.edu/ekampian/) [http://users.isc.tuc.gr/~ekabianakis/](http://users.isc.tuc.gr/~ekabianakis/) mail: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 5, 2014, 11:01pm UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/5 "2014-11-05T23:01:35Z")
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 😛 USB3 is still quite new and a lot of stuff is still buggy. Cheers, Sylvain ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 5, 2014, 9:53pm UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/6 "2014-11-05T21:53:33Z")
> 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 ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 5, 2014, 11:48pm UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/7 "2014-11-05T23:48:07Z")
Lefteris, ``` If your flowgraph doesn't have a GUI element, you can right click ``` on the Top Block icon and select Quit. Ron ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 6, 2014, 11:16am UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/8 "2014-11-06T11:16:23Z")
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 ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 6, 2014, 11:45am UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/9 "2014-11-06T11:45:02Z")
> 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 ``` ---
**Author:** ![EleftheriosSLefS\_Ka](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/6bbea6/32.png) [@EleftheriosSLefS\_Ka](https://www.ruby-forum.com/u/EleftheriosSLefS_Ka)\ **Post date:** [November 5, 2014, 11:42pm UTC](https://www.ruby-forum.com/t/libusb-error-pipe-and-improperly-stopping-gnuradio/232924/10 "2014-11-05T23:42:45Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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://staff.washington.edu/ekampian/) [http://users.isc.tuc.gr/~ekabianakis/](http://users.isc.tuc.gr/~ekabianakis/) mail: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)