17 Apr
2013
17 Apr
'13
6:14 a.m.
This is with a version of rtl-sdr I got by git last night and OpenBSD 5.2 (current
release). 5.2 has some pthreads fixing so I waited until I bought another computer and
loaded it. Are the crashes related to threads? I don't know, but possibly. It
didn't work with OpenBSD 5.0 either.
rtl_fm crashes and uses threads
rtl_adsb crashes and uses threads
rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c
rtl_test doesn't crash, doesn't use threads, won't stop
rtl_eeprom doesn't crash, doesn't use threads, ends normally
I'm not real practiced using gdb but I tried looking at a couple of core files,
here's a run of rtl_fm:
rtl_fm -f 162550000 -N - | play -t raw -r 24k -e signed-integer -b 16 -c 1
-V1 -
-: (raw)
Encoding: Signed PCM
Channels: 1 @ 16-bit
Samplerate: 24000Hz
Replaygain: off
Duration: unknown
In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000013
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Tuned to 162802000 Hz.
Sampling at 1008000 Hz.
Output at 24000 Hz.
Exact sample rate is: 1008000.009613 Hz
Tuner gain set to automatic.
In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0
Done.
Abort (core dumped)
d530# gdb -c rtl_fm.core /usr/local/bin/rtl_fm
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd5.2"...
Core was generated by `rtl_fm'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libpthread.so.16.0...done.
Loaded symbols for /usr/lib/libpthread.so.16.0
Reading symbols from /usr/lib/libm.so.7.0...done.
Loaded symbols for /usr/lib/libm.so.7.0
Reading symbols from /usr/local/lib/librtlsdr.so.0.0...done.
Loaded symbols for /usr/local/lib/librtlsdr.so.0.0
Reading symbols from /usr/local/lib/libusb-1.0.so.1.0...done.
Loaded symbols for /usr/local/lib/libusb-1.0.so.1.0
Symbols already loaded for /usr/lib/libpthread.so.16.0
Reading symbols from /usr/lib/libc.so.65.0...done.
Loaded symbols for /usr/lib/libc.so.65.0
Loaded symbols for /usr/libexec/ld.so
#0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0
(gdb) bt
#0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0
#1 0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2 0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c)
at /usr/src/lib/librthread/rthread_sync.c:218
#3 0x1c00266e in full_demod (fm=0xcfa2de5c)
at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583
#4 0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c)
at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641
#5 0x005ebc2e in _rthread_start (v=0x84da4c00)
at /usr/src/lib/librthread/rthread.c:111
#6 0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0
The backtrace (bt) shows that it dies trying to do a mutex_unlock (I think). rtl_tcp also
does a mutex_unlock and it doesn't crash. I'm probably reading it wrong for all I
know. I don't know what's causing the signal 6 either.
I'd also like to get the -lrt of of the cmake files. OpenBSD doesn't use or have
lrt, it works without. I can edit it out and compile, but every time I run cmake again, I
have to edit the files again.
Alan
-----
Radio Astronomy - the ultimate DX
19 Apr
19 Apr
2:37 p.m.
On 2013-04-17, Alan Corey <alancorey(a)yahoo.com> wrote:
This is with a version of rtl-sdr I got by git last
night and OpenBSD
5.2 (current release). 5.2 has some pthreads fixing so I waited until
I bought another computer and loaded it. Are the crashes related to
threads? I don't know, but possibly. It didn't work with OpenBSD 5.0
either.
rtl_fm crashes and uses threads
rtl_adsb crashes and uses threads
rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c
rtl_test doesn't crash, doesn't use threads, won't stop
rtl_eeprom doesn't crash, doesn't use threads, ends normally
[snip]
I've just got hold of a card and looking into this.
(gdb) bt
#0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0
#1 0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2 0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c)
at /usr/src/lib/librthread/rthread_sync.c:218
#3 0x1c00266e in full_demod (fm=0xcfa2de5c)
at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583
#4 0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c)
at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641
#5 0x005ebc2e in _rthread_start (v=0x84da4c00)
at /usr/src/lib/librthread/rthread.c:111
#6 0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0
By specification, pthread_mutex_unlock() has undefined behaviour when
unlocking a mutex which is already unlocked.
Currently OpenBSD's "undefined behaviour" in this case is to immediately
abort(), which has helped debug problems with some threaded programs.
You can change this behaviour by hacking librthread/rthread_sync.c:218
and building/installing new librthread, this gets rid of the crash but
does not make things work properly; like rtl_test, rtl_fm doesn't stop
when you ^C. I don't get any output from rtl_fm instead I get high
system cpu usage. I suspect this is some issue (quite possibly kernel
driver) with bulk transfers.
rtl_test doesn't work well for me. It starts up but
$ 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 Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9
25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.
Reading samples in async mode...
lost at least 1228 bytes
lost at least 1924 bytes
lost at least 1892 bytes
lost at least 2588 bytes
lost at least 1648 bytes
[...]
Notably the two programs which do seem to work correctly are rtl_eeprom
and rtl_tcp (at least I get some data from rtl_tcp but don't have
anything setup to use it yet) - notably these two do *not* use
rtlsdr_read_sync i.e. bulk transfers.
I'd also like to get the -lrt of of the cmake
files. OpenBSD doesn't
use or have lrt, it works without. I can edit it out and compile, but
every time I run cmake again, I have to edit the files again.
OpenBSD isn't the only system which has the realtime functions
in libc; this might be more generally applicable but note I have
not tested it on a system which *does* have librt.
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 6b23395..2afb494 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -101,12 +101,21 @@ target_link_libraries(rtl_adsb rtlsdr_shared
if(UNIX)
target_link_libraries(rtl_fm m)
target_link_libraries(rtl_adsb m)
-if(APPLE)
- target_link_libraries(rtl_test m)
-else()
- target_link_libraries(rtl_test m rt)
-endif()
-endif()
+
+include(CheckFunctionExists)
+check_function_exists(clock_gettime LIBRT_LIBC_HAS_CLOCK_GETTIME)
+if(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+ set(LIBRT_LIBRARIES)
+ set(LIBRT_LIB_FOUND TRUE)
+else(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+ find_library(LIBRT_LIBRARIES NAMES rt )
+ if(LIBRT_LIBRARIES)
+ set(LIBRT_LIBRARIES TRUE)
+ endif(LIBRT_LIBRARIES)
+endif(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+
+target_link_libraries(rtl_test m ${LIBRT_LIBRARIES})
+endif(UNIX)
if(WIN32)
target_link_libraries(rtl_sdr libgetopt_static)
diff --git a/src/rtl_test.c b/src/rtl_test.c
index f5a56b8..f84d453 100644
--- a/src/rtl_test.c
+++ b/src/rtl_test.c
@@ -131,7 +131,7 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void
*ctx)
}
ppm_count += (int64_t)len;
#ifndef _WIN32
- #ifndef __APPLE__
+ #ifdef CLOCK_REALTIME
clock_gettime(CLOCK_REALTIME, &ppm_now);
#else
gettimeofday(&tv, NULL);
@@ -143,7 +143,7 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void
*ctx)
ns += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec);
printf("real sample rate: %i\n",
(int)((1000000000L * ppm_count / 2L) / ns));
- #ifndef __APPLE__
+ #ifdef CLOCK_REALTIME
clock_gettime(CLOCK_REALTIME, &ppm_recent);
#else
gettimeofday(&tv, NULL);
20 Apr
20 Apr
5:59 a.m.
I've just got hold of a card and looking into
this.
Do you mean a dongle? I got one of the $20 ones, which works pretty well in Windows with
SDR# and RTL1090, so I bought a second one.
By specification, pthread_mutex_unlock() has undefined behaviour when
unlocking a mutex which is already unlocked.
I wondered about that. If it wasn't either locking something already locked our
unlocking something already unlocked. I stuck a bunch of extra printfs in the code and
was trying to keep track of what it was doing. It works under Linux, but that's like
saying a web page works fine in IE. Too sloppy to do otherwise.
Currently OpenBSD's "undefined behaviour" in this case is to
immediately
abort(), which has helped debug problems with some threaded programs.
You can change this behaviour by hacking librthread/rthread_sync.c:218
and building/installing new librthread, this gets rid of the crash but
does not make things work properly; like rtl_test, rtl_fm doesn't stop
when you ^C. I don't get any output from rtl_fm instead I get high
system cpu usage. I suspect this is some issue (quite possibly kernel
driver) with bulk transfers.
I wonder if the not stopping is because the low level acquisition, possibly a different
thread, isn't getting stopped.
Info: This tool will continuously read from the
device, and report if
samples get lost. If you observe no further output, everything is fine.
I seem to always have samples getting lost, no matter what I do I think it's also
supposed to give you a ppm adjustment figure, but I worked out mine from tuning in a few
stations and seeing how far off frequency they were (with SDR#). One dongle is off 102
ppm, the other 62 ppm.
I forgot to mention it, but rtl_sdr (the simplest one) also doesn't work. I was
looking at trying to adapt them to use the Gnu pth threads.
Notably the two programs which do seem to work
correctly are rtl_eeprom
and rtl_tcp (at least I get some data from rtl_tcp but don't have
anything setup to use it yet) - notably these two do *not* use
rtlsdr_read_sync i.e. bulk transfers.
There's a scanning client for rtl_tcp somebody wrote, but they did it in Python. It
has one dependency that seems badly packaged. I don't have it working yet. I was
thinking of writing a command line scanner in C that has hopefully no dependencies.
Are you sure your rtl_tcp is actually working? Mine stops after a while. You could test
it by running SDR# on a Windows machine and having the source of that be the rtl_tcp on an
OpenBSD box, just enter the IP address and port. I think it's a lot of network load
for even 100baseTX though. There are also Gnuradio sources that can work from rtl_tcp.
OpenBSD isn't the only system which has the realtime functions
in libc; this might be more generally applicable but note I have
not tested it on a system which *does* have librt.
I could in principle do that. I can boot this box into an old Debian and try that.
Alan
11:51 a.m.
On 2013/04/19 20:59, Alan Corey wrote:
Yes..
Linux doesn't have this strict checking, it was specifically added to
try to flush out bugs in programs using mutexes.
I think Pth won't help things on OpenBSD versions which already use
kernel threads (5.2+), and unlikely to have helped earlier versions
with userland threads either, the problem with userland thread
implementations is how file descriptor blocking is handled.
Can't test these; I can only run Windows in VM (SDR# is broken if you
have no audio device) or by dual booting my laptop (in which case
I can't use rtl_tcp on OpenBSD as a source).
I've just
got hold of a card and looking into this.
Do you mean a dongle? I got one of the $20 ones, which works pretty
well in Windows with SDR# and RTL1090, so I bought a second one. By
specification, pthread_mutex_unlock() has undefined behaviour when
unlocking a mutex which is already unlocked.
I wondered about that. If it wasn't either locking something already
locked our unlocking something already unlocked. I stuck a bunch of
extra printfs in the code and was trying to keep track of what it was
doing. It works under Linux, but that's like saying a web page works
fine in IE. Too sloppy to do otherwise. I wonder if the not stopping is because the low level
acquisition,
possibly a different thread, isn't getting stopped.
I've talked to another developer and we don't have good support for
usb transfer with asynchronous events yet, somebody is already looking
at this though. So for this side of things, it probably makes sense
to wait until that's available as this is likely to be the main
problem. (this is separate to the strict mutex checks mentioned above).
However I've just tried a few things in synchronous mode (rtl_test -S,
rtl_sdr -S, and RTLSDR-Scanner which uses sync mode anyway) and those
*do* seem to work.
Info: This
tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is
fine.
I seem to always have samples getting lost, no matter what I do I
think it's also supposed to give you a ppm adjustment figure, but I
worked out mine from tuning in a few stations and seeing how far off
frequency they were (with SDR#). One dongle is off 102 ppm, the other
62 ppm.
I forgot to mention it, but rtl_sdr (the simplest one) also doesn't
work. I was looking at trying to adapt them to use the Gnu pth
threads. Notably the
two programs which do seem to work correctly are
rtl_eeprom
and rtl_tcp (at least I get some data from
rtl_tcp but don't have
anything setup to use it yet) - notably these two do *not* use
rtlsdr_read_sync i.e. bulk transfers.
There's a scanning client for rtl_tcp somebody wrote, but they did it
in Python. It has one dependency that seems badly packaged. I don't
have it working yet. I was thinking of writing a command line scanner
in C that has hopefully no dependencies.
Are you sure your rtl_tcp is actually working? Mine stops after a
while. You could test it by running SDR# on a Windows machine and
having the source of that be the rtl_tcp on an OpenBSD box, just enter
the IP address and port. I think it's a lot of network load for even
100baseTX though. There are also Gnuradio sources that can work from
rtl_tcp.
working on this ;)
21 Apr
21 Apr
4:45 a.m.
> I forgot to mention it, but rtl_sdr (the simplest
one) also doesn't
work. I was
looking at trying to adapt them to use the Gnu pth
threads.
I think Pth won't help things on OpenBSD versions which already use
kernel threads (5.2+), and unlikely to have helped earlier versions
with userland threads either, the problem with userland thread
implementations is how file descriptor blocking is handled. There are also Gnuradio sources that can work
from rtl_tcp.
working on this ;)
1:31 p.m.
On 2013/04/20 19:45, Alan Corey wrote:
I was trying to figure out whether pth was abandoned or just mature
enough that it doesn't need any more updates. Looks like it's just
mature. I was suspicious that it was somebody's thesis project.
It's not all that much needed now that most unix-like OS have posix
threads support..
I forgot to mention it, but rtl_sdr (the simplest one)
also doesn't
work. I was looking at trying to adapt them to use the Gnu pth
threads.
I think Pth won't help things on OpenBSD versions which already use
kernel threads (5.2+), and unlikely to have helped earlier versions
with userland threads either, the problem with userland thread
implementations is how file descriptor blocking is handled. Your patch/diff for the cmake stuff works fine under
OpenBSD, but not
under Linux:
bleh, silly mistake ;)
OK - just setup an fc18 box to test it; here's a fixed version.
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 4b91a4b..4cc77fc 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -101,12 +101,17 @@ target_link_libraries(rtl_adsb rtlsdr_shared
if(UNIX)
target_link_libraries(rtl_fm m)
target_link_libraries(rtl_adsb m)
-if(APPLE)
- target_link_libraries(rtl_test m)
-else()
- target_link_libraries(rtl_test m rt)
-endif()
-endif()
+
+include(CheckFunctionExists)
+check_function_exists(clock_gettime LIBRT_LIBC_HAS_CLOCK_GETTIME)
+if(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+ set(LIBRT_LIBRARIES)
+else(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+ find_library(LIBRT_LIBRARIES NAMES rt)
+endif(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+
+target_link_libraries(rtl_test m ${LIBRT_LIBRARIES})
+endif(UNIX)
if(WIN32)
target_link_libraries(rtl_sdr libgetopt_static)
9 May
9 May
1:30 p.m.
On 04/20/2013 05:59 AM, Alan Corey wrote:
Note also that rtl_fm uses mutexes as semaphores/condition variables,
it locks mutexes in one thread and unlocks them in another thread -
which is undefined behavior (Except if the mutex is recursive or error
checking, in which case pthread_mutex_unlock must detect this situation
and return an error).
You're only supposed to unlock a mutex by the same thread that locked
it, and it's possible OpenBSD bails out if you do otherwise.
I've just
got hold of a card and looking into this.
Do you mean a dongle? I got one of the $20 ones, which works pretty
well in Windows with SDR# and RTL1090, so I bought a second one.
>
> By specification, pthread_mutex_unlock() has undefined behaviour when
> unlocking a mutex which is already unlocked.
10 May
10 May
9:24 a.m.
On 2013/05/09 13:30, noselasd(a)fiane.dyndns.org wrote:
On 04/20/2013 05:59 AM, Alan Corey wrote:
Note also that rtl_fm uses mutexes as semaphores/condition variables,
it locks mutexes in one thread and unlocks them in another thread -
which is undefined behavior (Except if the mutex is recursive or error
checking, in which case pthread_mutex_unlock must
detect this situation and return an error).
You're only supposed to unlock a mutex by the same thread that locked
it, and it's possible OpenBSD bails out if you do otherwise.
Is there a reason for doing it this way rather than using sem_post
and sem_wait?
I've
just got hold of a card and looking into this.
Do you mean a dongle? I got one of the $20 ones, which works pretty
well in Windows with SDR# and RTL1090, so I bought a second one.
>
> By specification, pthread_mutex_unlock() has undefined behaviour when
> unlocking a mutex which is already unlocked. 
18 Aug
18 Aug
7:43 a.m.
I think I've fixed all the problems with rtl_fm. It does not use the
async helper functions any more. For my purposes async mode is
broken. No clue what happened, but when you re-turn it freezes up on
rtlsdr_demod_read_reg(dev, 0x0a, 0x01, 1); line 476 of librtlsdr.c.
The new code is still multithreaded and should be just as fast.
My patch is at
https://github.com/keenerd/rtl-sdr
It would be nice to hear if this fixes the OpenBSD problems, and a
confirmation that the new code still runs under windows.
-Kyle
http://kmkeen.com
5:49 p.m.
keenerd wrote:
I think I've fixed all the problems with rtl_fm.
It does not use
the async helper functions any more. For my purposes async mode
is broken. No clue what happened, but when you re-turn it freezes
up on rtlsdr_demod_read_reg(dev, 0x0a, 0x01, 1); line 476 of librtlsdr.c.
The OpenBSD kernel doesn't currently offer any async API that libusb
can use, so libusb has to emulate the async behavior as best it can,
and it is by no means perfect.
If you have a chance, I would very much like to work with you today,
tomorrow and/or on Tuesday in order to look more closely into this.
I have some ideas if you are up for it? After Tuesday I have no
chance for a few weeks or so.
//Peter
7:15 p.m.
On 8/18/13, Peter Stuge <peter(a)stuge.se> wrote:
If you have a chance, I would very much like to work
with you today,
tomorrow and/or on Tuesday in order to look more closely into this.
I have some ideas if you are up for it?
Sure, I'll be in ##rtlsdr on Freenode today. Not sure how much help I
can be though. I still don't know much about libusb or librtlsdr yet.
-Kyle
http://kmkeen.com
3912
days inactive
4035
days old
10 comments
5 participants
participants (5)
-
Alan Corey -
keenerd -
noselasd＠fiane.dyndns.org -
Peter Stuge -
Stuart Henderson