As a new user of GNU radio with a couple RTL2832 dongles to play with I used the build-gnuradio script to install on Fedora 16 and Ubuntu 12.04. The Fedora install worked fine; but the Ubuntu one produced this:
lemur4[18]$ rtl_test Found 1 device(s): 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Elonics E4000 tuner Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0 Reading samples in async mode... cb transfer status: 1, canceling...
Library error 0, exiting... Segmentation fault (core dumped)
The traceback showed the fault to occur in libusb1, and seemed similar to the issue discussed at http://lists.gnumonks.org/pipermail/osmocom-sdr/2012-August/000201.html
I noticed this patch at the head of master touched the same general part of the code.
commit 3cbf1392612a0c6f02ec178f8e78568138f12b0a Author: Hoernchen la@tfc-server.de Date: Wed Jan 16 20:03:00 2013 +0100
exit if our usb device disappears
Reverting this change fixed the issue.
Peter
Hi,
On 20.01.2013 23:42, Peter A. Bigot wrote:
cb transfer status: 1, canceling...
Library error 0, exiting... Segmentation fault (core dumped)
Which version of libusb do you have installed? I just tried to reproduce this behaviour on a Ubuntu 12.04 x86_64 machine with libusb 1.0.9~rc3-2ubuntu1, but it works fine here.
Regards, Steve
On 01/20/2013 06:03 PM, Steve Markgraf wrote:
On 20.01.2013 23:42, Peter A. Bigot wrote:
cb transfer status: 1, canceling...
Library error 0, exiting... Segmentation fault (core dumped)
Which version of libusb do you have installed? I just tried to reproduce this behaviour on a Ubuntu 12.04 x86_64 machine with libusb 1.0.9~rc3-2ubuntu1, but it works fine here.
Regards, Steve
Info below. FWIW, the problem did occur with two RTL2832U from different manufacturers (one E4000 one R820T, both from NooElec), plugged directly into a USB port on a System 76 laptop (no hub involved), and persisted over multiple reboots. It was only reverting that patch that made it work at all.
The segfault makes sense, since the patch has the library detect a transfer error that used to be ignored and then set a flag that inhibits the wait for in-progress asynch actions to complete before shutting down: AFAICT libusb1 is known to get upset when this happens. I'm guessing the error was transient or diagnostic of some other condition, and should not have been taken as a sign that the device had gone away and the library should shut down.
lemur4[3]$ dpkg-query -s libusb-1.0-0 Package: libusb-1.0-0 Status: install ok installed Multi-Arch: same Priority: optional Section: libs Installed-Size: 108 Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com Architecture: amd64 Source: libusb-1.0 Version: 2:1.0.9~rc3-2ubuntu1 Depends: libc6 (>= 2.14) Pre-Depends: multiarch-support Description: userspace USB programming library Library for programming USB applications without the knowledge of Linux kernel internals. Homepage: http://www.linux-usb.org/ Original-Maintainer: Aurelien Jarno aurel32@debian.org
Peter A. Bigot wrote:
The segfault makes sense, since the patch has the library detect a transfer error that used to be ignored and then set a flag that inhibits the wait for in-progress asynch actions to complete before shutting down: AFAICT libusb1 is known to get upset when this happens.
libusb gets upset because it is a usage error. You can't shut down before cleaning up anything you have allocated/started/created for the context.
//Peter
-
Peter A. Bigot -
Peter Stuge -
Steve Markgraf