OpenBSD: crashing

Alan Corey alancorey at yahoo.com
Sat Apr 20 03:59:34 UTC 2013


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130419/f1011fd7/attachment.html>


More information about the osmocom-sdr mailing list