20 Jan
2013
20 Jan
'13
11:42 p.m.
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(a)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
21 Jan
21 Jan
1:03 a.m.
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
1:45 a.m.
On 01/20/2013 06:03 PM, Steve Markgraf wrote:
On 20.01.2013 23:42, Peter A. Bigot wrote:
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(a)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(a)debian.org>
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 
3:13 a.m.
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
4535
days inactive
4536
days old
3 comments
3 participants
participants (3)
-
Peter A. Bigot -
Peter Stuge -
Steve Markgraf