Raspberry Pi 4 B ARMv8 Monerod segfault #6663
Comments
|
If you're sure this is about AES insns, you can try to run the env var MONERO_USE_SOFTWARE_AES=1 |
|
Try starting monerod like this: |
|
MONERO_USE_SOFTWARE_AES=1 do not help, i still get
I removed my old blockchain and started syncing from scratch, that is working ok till now, however, i am currently on block 1382424, i.e. before transition to RandomX. I'll let you know what happens at block height 1978433 ... |
|
If this happens again, you could try |
|
OK, it synced up to ~ 2092532, then it crashes again:
Upping the loglevel i get:
Any ideas ? |
|
Checking HugePages Support:
running
does not change anything |
|
If you don't allocate the hugepages at boot time it's very likely you won't be able to. What does /proc/meminfo show after you run the sysctl command? Also - the lack of hugepages is irrelevant, as far as the Illegal Instruction exception is concerned. |
|
Large pages are not required to run RandomX. It's just a harmless warning. The issue also doesn't seem to be caused by hardware AES since you were able to sync past block 1978433. I have experienced random SIGILL/SIGSEGV on ARM before. It was caused by the instruction cache not getting flushed properly after JITing the RandomX code. You can try running |
|
Hi ! I notice mining is much slower now, is 2092532 the first RANDOMX block ?
Very cool. |
karlkashofer
changed the title
karlkashofer
changed the title
No. The first RandomX block was 1978433. Also I don't think the name of the issue is correct. Your previous segfault was on a different block height AFAICS. Or does it always crash on 2092532? If yes, it could be related to the particular program that the block was mined with. |
|
You are correct about the title, it seems to crash on different blocks, i just took the number from the log but that does not seem to be the current block. Will change the title asap. Hmm, when i remove MONERO_RANDOMX_UMASK=8 it crashes again.
So, will it have to run in this slow interpreter mode forever ? Also, is there documentation of Monero environment variables somewhere ? |
karlkashofer
changed the title
|
Ok, so with MONERO_RANDOMX_UMASK=8 i was now able to successfully sync up to now. Still, it seems compiled mode is not working on Armv8. |
I have a Raspberry Pi 3B and compiled mode works for me just fine. AFAIK you are the first one reporting this issue. It's possible that the chip in your Raspberry is faulty. |
|
Hmm, how did you produce the arm64 monerod binary ? I use the one from Debian bullseye, but i have also done a native compile on the RPi4 from debian sources. Both have the same problem. Maybe a compiler flag ? Could you send me your binary ? |
|
I'm not running monerod on my raspberry, but I did quite extensive testing using the RandomX benchmark. You can build it from source here: https://github.com/tevador/RandomX You can test it with: If the basic tests doesn't crash, you can try |
|
Hmm, verify seems to work, mining does not work here, "Ungültiger Maschinenbefehl" is "Illegal instruction": karl@rpi4-20200622:~$ ./randomx-benchmark --verify --auto
karl@rpi4-20200622:~$ ./randomx-benchmark --verify --auto --threads 4 --nonces 1000
karl@rpi4-20200622:~$ ./randomx-benchmark --mine --jit --threads 4 --init 4
karl@rpi4-20200622:~$ ./randomx-benchmark --mine --threads 4 --init 4
karl@rpi4-20200622:~$ ./randomx-benchmark --mine --jit --secure --threads 4 --init 4
karl@rpi4-20200622:$ uname -a different pi: karl@rpi4-20200516:~$ ./randomx-benchmark --mine --jit --threads 4 --init 4
karl@rpi4-20200516:~$ ./randomx-benchmark --verify --auto
|
You are using the wrong command for mining. You have to either use Also I recommend running the test with a lot more than the default 1000 nonces. Try |
|
You are right, RandomX works in verify and mine mode on arm8 Rpi4: karl@rpi4-20200622:~$ time ./randomx-benchmark --verify --auto --threads 4 --init 4 --nonces 100000
real 39m25,094s karl@rpi4-20200622:~$ ./randomx-benchmark --mine --auto
Which gets us back to the question why is my monerod crashing in compile mode ? |
|
Can you rerun the benchmark with the Run: If this crashes, then we know it's caused by the secure option. It can be disabled with |
|
Seems to work: karl@rpi4-20200622:~$ ./randomx-benchmark --verify --auto --secure --threads 4 --init 4 --nonces 100000
|
|
Then I'm out of ideas. Can you check with |
|
root@ed91bb20dc8a:/# monerod --data-dir /mnt/monero_blockchain/ --log-file /mnt/monero_blockchain/monerod.log --non-interactive --confirm-external-bind --restricted-rpc --rpc-bind-ip=0.0.0.0 For help, type "help". |
|
It looks like it's executing garbage data. I will summon @SChernykh since he is the author of the ARMv8 JIT compiler. |
|
@karlkashofer Did you build monerod yourself? And randomx-benchmark? Or was it all official binaries? I remember we had garbage code in RandomX on ARMv8 with certain compiler/linker versions... |
|
monerod is the arm64 binary from debian bullseye, randomx-benchmark was downloaded from https://github.com/tevador/RandomX/releases, all tests were done in docker containers |
|
randomx-benchmark works with JIT for you, hmm... I have RPi3 B+. I don't run monerod there, but mining works. Can you try to compile randomx-benchmark? If your binary still works with JIT, you have a good chance to get working monerod if you compile it yourself. |
|
Scanning dependencies of target randomx-tests
seems to work OK |
so, monerod built from debian sources crashes. |
|
The plot thickens:
Compiling from git works ! So it seems the debian packagr is broken. It seems git has a newer version than debian, v0.16.0.1-release instead of v0.16.0.0-unknown I will ping the debian maintainers to update. |
Trying to get a monero daemon running on RPi 4B running aarch64
Debians arm64 binary gives "Illegal instruction (core dumped)"
According to #4452 and #2858 and #5782 this could be connected to AES instructions.
I recompiled with "cmake -d NO_AES=ON", but its still not working:
If you want to try, this is my docker build file, you need 4GB swap to run it on RPi4:
Any idea what i could try next ?
The text was updated successfully, but these errors were encountered: