Bug in rtl-sdr / libusb / usbfs

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.

Gonzalo José Carracedo Carballal batchdrake at gmail.com
Sat Jan 11 10:56:15 UTC 2014


Hello!

This is my first time using this mailing list, hope it's the right
place to post this.

I compiled rtl-sdr under Debian 7.2 (32 bits x86) it detects my ezcap
e4k properly but it's unable to read samples. When running rtl_sdr
like this, it just hangs:

---8<--------------------------------------------------------------------------------------------
% rtl_sdr -f 100000000 -
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN:

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in async mode...
---8<--------------------------------------------------------------------------------------------

Pressing Ctrl+C only makes rdl_sdr say "Signal caught, exiting!", but
it won't exit unless you kill it explicitly with SIGKILL. If I run it
in synchronous mode, I get this output instead:

---8<--------------------------------------------------------------------------------------------
% rtl_sdr -f 100000000 -S -
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN:

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in sync mode...
WARNING: sync read failed.

Library error -8, exiting...
rtlsdr_demod_write_reg failed with -1
---8<--------------------------------------------------------------------------------------------

I tried to reinstall libusb, recompiling it from a newer version (I'm
currently using 1.0-16rc10)  and got the same output. As -8 means
overflow for libusb, I decided to increase the output block size. I
had to edit rtl_sdr.c to read as much as 30M, and that was the only
way I could get some output. Block sizes below 10M just won't do the
trick:

---8<--------------------------------------------------------------------------------------------
 % rtl_sdr -b 30000000 -f 100000000 -S -
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN:

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in sync mode...
Short read, samples lost, exiting!

Library error 0, exiting...
(here be messy bytes of 64 bytes sampled by RTL)
---8<--------------------------------------------------------------------------------------------

That's why I recompiled libusb with logging, and I got this output
(now, with 3M blocks):

---8<--------------------------------------------------------------------------------------------
[...]
Reading samples in sync mode...
libusb: 1.079895 debug [submit_bulk_transfer] need 184 urbs for new
transfer with length 3000000
libusb: 1.080660 debug [libusb_handle_events_timeout_completed] doing
our own event handling
libusb: 1.080692 debug [handle_events] poll() 4 fds with timeout in 60000ms
libusb: 1.083056 debug [handle_events] poll() returned 1
libusb: 1.083082 debug [reap_for_handle] urb type=3 status=-75 transferred=64
libusb: 1.083104 debug [handle_bulk_completion] handling completion
status -75 of bulk urb 1/184
libusb: 1.083125 debug [handle_bulk_completion] overflow, actual_length=64
libusb: 1.083146 debug [disarm_timerfd]
libusb: 1.083161 debug [usbi_handle_transfer_completion] transfer
0x97a0424 has callback 0xb775c7f0
libusb: 1.083182 debug [bulk_transfer_cb] actual_length=64
WARNING: sync read failed.

Library error -8, exiting...
[...]
---8<--------------------------------------------------------------------------------------------

Status -75 (overflow) made me think about a limitation on the URB size
in my system, but it looks that in Linux that's a standard (16K), so I
ran out of ideas. I don't know where the problem is anymore, whether
in rtl-sdr, libusb, usbfs or even in my system; because I've compiled
it in two different systems already (my laptop - Ubuntu 12.04 - and my
home computer - Debian Sid -) and it works fine in both of them.

Regards,
-- 
>> Gonzalo José Carracedo Carballal




More information about the osmocom-sdr mailing list