My RPi is connected to a mouse, keyboard, and monitor. My swap size is set to 1000 MB and I'm not using wifi.
The RPi freezes randomly, meaning the GUI is frozen, no SSH connection is possible, and
Magic + reisub doesn't work, either. Sometimes, this happens when I use Chromium to surf the web, sometimes it reboots while booting.
While the freezes happen rather occasionally "out of nowhere" (as stated above), I can always reproduce the freeze by executing the following python3 script:
from rtlsdr import RtlSdr # Get a list of detected device serial numbers (str) serial_numbers = RtlSdr.get_device_serial_addresses() # assign object to handle the RTL-SDR sdr = RtlSdr(serial_number=serial_numbers) sample_rate_sdr = sdr.sample_rate = 2.048e6 center_freq_sdr = sdr.center_freq = 100e6 sdr.read_samples(128) sdr.close()
To be specific, the script is not the only reason for the freezes. However, it makes them reproducable.
More information about the problem
Note, that it only(!) happens for sample reads, that are smaller than 129 samples (argument to
read_samples method). The curious thing is, that the Pi won't - in most cases - freeze immediately, but a few seconds after the script has finished executing and I'm already back at the terminal. While I'm running the script, I have no other window open (only
lxterminal to run the script; sometimes another terminal with top, sometimes
Geany to modify the script, but mostly none and it doesn't make a difference).
Sometimes, between the script excecution and the freeze, I can still type in commands, start applications, and run them for a while (mostly, it will then freeze when I try to save a file in Geany, but not always). Sometimes, I can still switch windows, but can't open or close any. Sometimes the freeze occurs while the script is still running, but mostly not. Sometimes, every command I type in the terminal (and may they be random letters) + Enter, this will give me "Segmentation fault". This doesn't always happen, though. Once I saw
kworker/u8+ at 100 % when frozen, but this might not mean anything.
When I do the
read_samples call in a loop, the freeze will mostly occur after a few iterations (after fewer iterations if the loop takes longer because of some other calculations I'm doing in between). This seems to be congruent with my observations with the freeze after several seconds in the stripped down minimal version posted above. When having a long loop, I sometimes see
python go into a zombie state in 'top' (when I load many modules, I can also see a D state for python when loading modules, but this might be normal as it will leave the D state again after loading the modules). When I run the loop version of the script in
jupyter-notebook, I can sometimes see
chromium-browser go into a D state in
top before freezing.
Sometimes, when I go to the console with
Strg + Alt + F1, I can see several kernel messages appear with random numbers, and some messages like
Internal error: Oops: 5 [#5] SMP ARM and
Unable to handle kernel paging request at virtual address 55555555. Sometimes, several of those messages (that span multiple lines) will appear, but in the very end there will mostly be a message about a kernel panic.
Things I've tried to solve the problem
The first thing, that pops up searching for random freezes, is the suggestion to try an adequate 2.5 A power supply. So I connected a laboratory power supply, that controls the voltage at 5.1 V, but nothing changed about the feezes. At least, the undervoltage warning I'd occasionally get at startup (and only then - no yellow flash in the corner later or a blinking LED) was gone. Now, the power supply shows me a current of about 500 ... 1000 mA when the freeze happens.
Next, I tried underclocking the Pi by adding the following lines to /boot/config.txt. Didn't help.
arm_freq=900 core_freq=250 sdram_freq=450
I noticed, that the Broadcom controller's metal case got pretty hot when freezing during execution of the looped script, so I installed a small fan. Now, the chip stayed nice and cool. However, that didn't do anything to the freezes.
Then I tried to use another RPi 3B+. Needless to say, that this didn't solve the problem, either.
Now my best bet for a cause is the SD card. I've executed
e2fsck -cvf /dev/mmcblk0p2 from a linux live system (as indicated in the accepted answer in another thread), but it only showed a few orphaned inodes (repaired that), no bad blocks. I also used
dd to copy the SD card to another one and put that into the second RPi, but that didn't help (perhaps, I also copied the possibly corrupted part by doing this?). I really hope, it's not the SD card as it took a lot of time to set everything up and running (including self-compiled kernel modules), but if that's the fault, I at least know why the freezes occur, although I have no idea what could have corrupted the card. I can't remember any power failures.
Here is the extract from
/var/log/syslog that was written during a session that eventually froze (this time when I started Mathematica after executing the script with 120 read samples). Let me know if you need any more information.