SDRplay Community Forum

As per the title...

I can't reproduce that. I have a new 16.04 install from scratch and CubicSDR working well with SoapySDR/Play and the RSP

Is yours upgraded from 15.x or a fresh 16.04 install? Trying to understand the differences (32/64bit?)

Best regards,

SDRplay Support

It's 64-bit Linux, upgraded from 15.10; 'uname -a':

Linux 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I'll try recompiling '/usr/local/lib/SoapySDR/modules/libsdrPlaySupport.so' this evening and see what happens; however, this is very strange indeed - it's the first consistent kernel panic I've seen in Linux for years!

Please see other topic on same problem and try if also with your setup SoapySDRUtil --probe show same error and Python SoapySDR test program crash Ubuntu.

After this we need to test a fresh Ubuntu 16.04, not an upgraded system from 15.10

Regards
Franco Spinelli
IW2DHW

IW2DHW wrote:Please see other topic on same problem and try if also with your setup SoapySDRUtil --probe show same error and Python SoapySDR test program crash Ubuntu.

After this we need to test a fresh Ubuntu 16.04, not an upgraded system from 15.10

Regards
Franco Spinelli
IW2DHW

I've tried avoiding SoapySD and going via gr-osmosdr and the same kernel panic. My libusb is 1.0.20:

$ dpkg -l | grep libusb
ii libusb-1.0-0:amd64 2:1.0.20-1 amd64 userspace USB programming library

The plot thickens..!

It has the same problem with Arch Linux, currently on kernel 4.6.3 and systemd 230-5.

I've had the lockup problem with the SoapySDR/CubicSDR combination for a several weeks now. I finally gave up trying to fix it, hoping the new API would solve the problem.

After the new API came out, I removed all traces of the old API, SoapySDR installs, and CubicSDR installations. After installing the new API, I installed SoapySDR with the SDRplay module. Probing the SDRplay showed everything good. I pulled the latest CubicSDR source from Git and compiled it. Everything appeared to be fine with it.

Started CubicSDR, selected SDRplay RSP, and the laptop locked up solid as soon as I hit "Start" -- had to remove power to reboot. I suspect the problem is related to recent kernel or udev changes allowing the SoapySDR SDRplay module to do something nasty, but I haven't been able to track down what's causing the complete system lock.

I have no problems with gr-osmosdr-git modified with HB9FXQ's sdrplay library files and gqrx. Gqrx is a nice receiver when the right settings are used, but I'd like to get CubicSDR working again!

73...
Doug AH6DL

I have rebuilt the API using slightly different options to see if it's that (1.95.2)...

http://www.sdrplay.com/linux.html

Best regards,

SDRplay Support

I gave it a try, but I'm getting an error in SoapySDRUtil --probe. The same error prevents CubicSDR from loading:
Reinstalling 1.95.1 eliminates the SoapySDRUtil --probe errors, but I haven't tested CubicSDR yet as I wanted to send this first in case it crashes the laptop.

73...
...Doug AH6DL

Moving the SDRPlay to a USB 3.0 port eliminated the crashes with SoapySDR/CubicSDR and dump1090_sdrplus using API 1.95.1.

Haven't tried reinstalling 1.95.2 to see if it still fails nicely with the undefined symbol error.

73...

...Doug, AH6DL

AH6DL wrote:I gave it a try, but I'm getting an error in SoapySDRUtil --probe. The same error prevents CubicSDR from loading:

Code: Select all

symbol lookup error: /usr/lib/libmirsdrapi-rsp-1.95.so: undefined symbol: libusb_init

Reinstalling 1.95.1 eliminates the SoapySDRUtil --probe errors, but I haven't tested CubicSDR yet as I wanted to send this first in case it crashes the laptop.

73...
...Doug AH6DL

I have the same error, while trying to start gr-osmosdr with 1.95.2.

This error does not appear with 1.95.1, but the system crashes anyhow. Surprisingly, SoapySDRPlay used to work excellent with the old 1.8 api on a RPi.