Closed eroom1966 closed 1 year ago
Hi,
I get a floating point exception while running gsm_scan on a Raspberry Pi 4 with the latest Raspbian and latest rtlsdr-ogn. The error is thrown at the same location:
Thread 1 "gsm_scan" received signal SIGFPE, Arithmetic exception.
raise (sig=8) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) info stack
#0 raise (sig=8) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0xb6aae1f8 in __aeabi_ldiv0 () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
#2 0x0000a1bc in SlidingFFT(SampleBuffer<std::complex<float> >&, SampleBuffer<unsigned char>&, RPI_GPU_FFT&, float*, float) ()
#3 0x00009a10 in main ()
I don't have a workaround.... :/
You have my sympathies, nobody seems to be answering this question unfortunately :-(
Just a comment for all those who use the Raspberry Pi 4.
As of today, the Video firmware is not up to date (even using rpi-update). This means that the GPU accelerated package does not work on the rpi4 and will exit with the cryptic "Floating Point Exception" message.
You need to download the standard ARM package, an then everything should be ok. Hope this helps someone.
For those who want to check the firmware:
sudo rpi-update && sudo reboot
cd /opt/vc/src/hello_pi/hello_fft
make
./hello_fft.bin 8
As of today, this exits with the message:
Unable to enable V3D. Please check your firmware is up to date.
Just another little extra comment. I have chatted to the developer of the RPi GPU FFT module and there appears no intention to make it work on the Raspberry Pi 4, and in any case, the CPU is faster on the model 4, so it is pointless. I am using the FFTW and can additionally comment that having one's RPi spending days generating Wisdom files for FFTW is also a pointless exercise as what pops out isn't a measurable improvement. The same goes for having FFTW run multi-processor. However, it is a fun exercise, if you're into that kind of thing...
My station runs on rpi 3b that is upgraded to raspbian 11.1. Only recently I also got the floating point exception. I had to revert to the ARM version, that works. The cpu load is significant now. Anything I can do short of reverting to Raspbian 10?
Only a few days ago I have installed a new OGN test station, based on Pi Zero 2 W and RasPiOS 11 aarch64. Here is a link to my script that I used: https://github.com/VirusPilot/ogn-pi34 which I recently updated to use Pawel's latest OGN binaries from here: https://github.com/pjalocha/ogn-frb-search. Maybe you can use some part of my script to update your station to ogn 0.2.9 and RasPiOS 11.
It seems Pawels binaries for GPU are based on Jessie, while the arm64 version is based on buster. Do you know what other advantages has the 0.2.9 over 0.2.8?
This question certainly goes to @pjalocha
0.2.9 contains lot of, mainly small, improvements, which keep accumulating, untill we give out a new version. There is no major improvement, as of now over the 0.2.9.
BTW: I compile the Jessie, as there are many receivers there with fairly old OSes and apparently when you compile on newer systems, there is always some library which is newer and thus not compatible and the binary refuses to start.
0.2.9 contains lot of, mainly small, improvements, which keep accumulating, untill we give out a new version. There is no major improvement, as of now over the 0.2.9.
BTW: I compile the Jessie, as there are many receivers there with fairly old OSes and apparently when you compile on newer systems, there is always some library which is newer and thus not compatible and the binary refuses to start.
I installed the Jessie package on my Bullseye, and it works. Thank you!
To fix this issue for Raspberry Pi 3B(+):
sudo raspi-config
There navigate to 6 Advanced Options
-> A2 GL Driver
-> G1 Legacy
-> OK.
Reboot follows.
The RPI-GPU-0.2.8 version from glidernet works properly. The RPI-GPU-0.2.9-Jessie from @pjalocha repo works properly.
Might be also working for Raspberry Pi 4, I don't have this device to try.
P.s: @pjalocha it would be great help to have new rtlsdr-ogn versions also at glidernet.org, if possible. Thanks!
sudo raspi-config
There navigate to 6 Advanced Options -> A2 GL Driver -> G1 Legacy -> OK. It always says "The GL driver is disabled" after that step. I guess it should be enabled?
Choosing the "G2 GL (Full KMS) OpenGL" option seems to work, but there is still the floating point exception.
This is correct, because there are only two options: G1 - for legacy driver, and G2 for proper GL driver. When you select G1, the proper GL driver gets disabled.
I tested this with the latest Raspbian Lite OS from https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2022-04-07/2022-04-04-raspios-bullseye-armhf-lite.img.xz Maybe this is possible only starting from some of the latest OS images. I don't have more details.
I have noted on numerous occasions that the ogn-rf exits after having a floating point exception, here is a back trace from gdb below - not sure how to go about fixing this other than a reboot.
Exact sample rate is: 1000000.026491 Hz RTLSDR::Open(1,868300000,1000000) => Generic RTL2832U OEM, 868.303 MHz, 1.000 Msps RTLSDR::Gain[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 [dB] Floating point exception
Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x760e1450 (LWP 26654)] 0x76f1b2e8 in raise (sig=8) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 37 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory. (gdb) where
0 0x76f1b2e8 in raise (sig=8) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
1 0x76aad14c in __aeabi_ldiv0 () from /lib/arm-linux-gnueabihf/libgcc_s.so.1
2 0x0000b79c in SlidingFFT(SampleBuffer<std::complex >&, SampleBuffer&, RPI_GPU_FFT&, float*, float) ()
3 0x0001009c in Inp_FFT::ThreadExec(void*) ()
4 0x76f11e90 in start_thread (arg=0x760e1450) at pthread_create.c:311
5 0x76a2e598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info thread Id Target Id Frame 9 Thread 0x744ff450 (LWP 26660) "ogn-rf" 0x76a24b80 in poll () at ../sysdeps/unix/syscall-template.S:81 5 Thread 0x74eff450 (LWP 26656) "ogn-rf" 0x76a26f2c in ioctl () at ../sysdeps/unix/syscall-template.S:81 4 Thread 0x756ff450 (LWP 26655) "ogn-rf" 0x76f167a4 in __pthread_cond_wait (cond=0x39878 <RF+2192>, mutex=0x398ac <RF+2244>) at pthread_cond_wait.c:187