svts

So the problem was solved! sed -i -e '1imw.l 0x01C20020 0x80101810\' /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr The reason of crashes was DRAM PLL value which seems too high for the boards I have. Default DRAM_PLL value set by u-boot 2017.05+ is 624MHz. It seems not all board support this value. I changed it to 600MHz by setting 0x01c20020 register to 0x1810 value (instead of 0x1910 set by u-boot) and there's no any crash anymore. The script adds "mw.l 0x01C20020 0x80101810" line to boot.cmd and then compiles boot.scr. After that u-boot will change DRAM_PLL value to a bit lower one to avoid crashes. Thanks everybody who helped me to find a solution. Special thanks to @znoxx for testing and logging :)

@znoxx Maybe it depends on what it is running... Would you please to run my test script there if it's possible? This script breaks the system in like 5 to 15 minutes usually. Thank you!

@znoxx Thank you. Well actually I did just what you said. When I started expecting some issues I ordered a new board and when it arrived I confimed that the problem did persist. Technically it's possible that the board I ordered has the same buggy parts but... it's almost unbelievable you know :)

@znoxx Nice job! I like the way how it looks, handmade devices have their own charm! :) So the debug proccess is still in process. I tried u-boot 2017.11 but got unfortunately no success. Would you please check "dmesg" of one of yours OPI PC2? Thank you in advance. The problem is it's almost impossible to notice the crash when there's no serial cable attached nor display as system recovers it but also notices in dmesg. I tried ATX power supply as well - so got same problem and also soldered 1000uF 10v capacitor directly to power supply connector to be sure there's no power fluctuation because of long cables but the problem still persists.

Thank you for your information, I'll try u-boot 2017.11 tomorrow. I compared DDR_PLL registers set by old and new u-boot, new one set a bit lower value of 624MHz and old one set 684MHz. Once I noticed that I fixed it directly in u-boot (wm.l) but got a crash again. Old uboot doesn't work with network interface and USB properly (as it's really old one) but it doesn't affect linux kernel which works perfect. I have bought these OPI PC2 separately from different suppliers so I'm not sure it could be some kind of hardware bug. I have hardware version of 1.1 of both boards. Which is yours? And during the tests I tried different CPU frequences from 120/480MHz upto 1104/1284MHz. Same distro works fine with older uboot and crashes in like five minutes with new one. 7z test shows almost the same value in both cases. I also compared GPU_PLL registers and SDC_PLL, they are a bit different but when I change values I have a crash again. So there must be something else.

UPDATE2: u-boot causes kernel crashes of OPI PC2 After some more days of debugging I figured out that problem isn't in the kernel itself and nor in system services but in u-boot. I changed different kernels, tried to black list modules and disable services using servicectl and update-rc.d but nothing really helped. Then I boot with init=/bin/bash kernel parameter and tested like that, so crashes appeared. After that I found and old "dietpi" distro based on 4.10.0 and armbian 5.27 (imho) and checked, and no crashes. Then I updated its kernel to 4.14.78 and checked again - no crashes. 4.18.8 - no crashes again. I tried to boot it with init=/bin/bash and had success as well. After that I transferred Image and uInitrd from this distro to armbian and checked again with init=/bin/bash. And I got a crash in like 5 minutes. So there was no difference... but u-boot. I tried also downgrade armbian's u-boot to 2017.05 (downloaded from apt.armbian.com) but it didn't really help. Then I extracted u-boot 2017.01-rc1 from the "dietpi" distro and wrote it to armbian SD card. And no more crashes. Then I updated it to kernel version of 4.19.6-sunxi64 (as I did at the first time too) and it works stable. It works with 100% load for like 15 hours at max. freq of 1296MHz (I limited it with cpufrequtils). root@orangepipc2:~# uptime 06:45:48 up 15:27, 4 users, load average: 7.44, 7.62, 7.59 root@orangepipc2:~# uname -a Linux orangepipc2 4.19.6-sunxi64 #5.67.181207 SMP Fri Dec 7 10:54:20 CET 2018 aarch64 aarch64 aarch64 GNU/Linux So the question is what's happened to u-boot which causes those crashes. I suppose it can be a thing which enables some SoC unused pins or probably some interrupts. I compared boot.scr files and found nothing really hw-related, which could cause some difficulties. An "Official" support for H5 SoC was made since u-boot 2017.05 but I have 2017.01-rc1 which is probably patched at the moment. And it works perfect. U-Boot 2017.01-rc1-g5df570f-dirty (May 02 2017 - 12:04:46 +0100) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: OrangePi PC 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Does anybody have an idea why new u-boot could cause some hangs? Had anybody made some stress-test of Armbian running OPI PC2 boards? If yes so which HW version, which u-boot? I have two boards (bougth separately) of HW version 1.1 and it works with really old u-boot only. So let it be my "Bug report"

Update: after the second day of non-stop testing I figured out, that crashes still appear but rarely. Nor isolcpus, nor numcpus really help. But all crashes are like this Unable to handle kernel NULL pointer dereference at virtual address 00000038 The difference is only the virtual address value which is always less then 0x00000100. I tried to check voltages eveywhere. Sure no short-circuit and no probes into USB ports directly So I use two different PSUs, and there's 5.11v and 5.02v. I even tried oscilliscope to check, but everything is okay, no fluctuations. (ps: Is that really important as I don't use USB devices during the test? I saw the circuit diagram and supply voltage isn't used directly anywhere but USB, all other voltages and their oscilloscope shapes seem to be okay) Yep, wrote to them also. Thank you for the tip

Hello everybody! I've bought recently OrangePi PC2 to develop a small data gathering machine but got stuck with some difficulties with Armbian. Board is OrangePi PC2 v 1.1. The problem is random crashes (kernel oops and kernel panics then sometimes). What I have done: made SD card with Armbian "next" 5.65 distro (kernel 4.14.78-sunxi64). No changes, no overlays etc. What happens: the system crashes randomly. It happens never during initial kernel boot but it starts happening after systemd load. Sometimes (like 1-2 of 10) system cannot boot at all without crash. When system boots okay I use a script to test: The script runs well for a while (like 5-15 mins) and then crash appears in system console and dmesg. Sometimes system hangs immediately but sometimes it works then. I check then the state of the system using ambianmonitor -m (temp and cpu freq) and also top (f -> P to watch CPU id of the process) When there's no direct oops crash in system log, some local crashes can occur, i.e. it can be segfault of some tool (ssh, top, sudo etc). What I have already tried: updated kernel to dev-version (4.19) but got the same random crashes. Downgraded to 4.10.0 and got the same things. Tried to upgrade u-boot to dev version, tried to downgrade u-boot. Uploaded u-boot to NOR flash and used USB for armbian (no SD card at all) - random crashes appear. "Official" distro (Debian 8, kernel 3.10) works with no issue. But it's too old to use with 1-wire, I2C and other sensors. Then I spent hours to check PC and LR values, also checked processes which was involved to crash issue but nothing common. I tried to downclock CPU (to 480 MHz min and max) - no luck. Checked voltages (1.1 Vcore, 1.2Vdram) - everything is okay. Changed PSU - no effect. Changed the board to another OPI PC2 one - no effect, same crashes. Then I tried to run the system on a single core by kernel parameter maxcpus=1. And everything was FINE. No crashes for 24h. Then I made CPU1 online (echo 1 > /sys/bus/cpu/devices/cpu1/online) and got crash after like 5 minutes of running the script (non stop). Then I tried to play with kernel parameter isolcpus=1-3. I saw then some interrupts (cat /proc/interrupts) got served by all CPU cores, but all software were running at CPU0 core. Then no crash for like 12h. Then I started the same script on CPU2 using taskset -c 4 ./test.sh, saw it running on CPU2 (using top) and then got a crash again in 15 minutes. Then I tried isolcpus=0,2-3, saw systemd and all services running at CPU1, run test.sh for like 4 hours on CPU1 (as well) with no problem, then run it on CPU2 taskset -c 4 ./test.sh and got crash in like 10 minutes. UPDATED: nope, that was wrong. Crashes still appear but very rarely. Also I tried memtester on both boards I have - everything is fine. Conclusion: it seems it's not hardware issue, something prevents apps work normally when there's high I/O load when multiple cores are used. And it seems it's not kernel itself as kernel processes work and serve interrupts during isolcpus parameter used. Could it be an issue with systemd? There's no option in repo to update it and check. Please help me to figure out what's happening. Thank you so much. UPDATED2: u-boot causes kernel crashes of OPI PC2 Some infos is in my post below UPDATED3: new u-boot set DRAM PLL to 624MHz which seems to high for some boards (especially "cheapest" from aliexpress). So I set DRAM PLL to 600MHz using u-boot mw.l command and I have no crash anymore. Some infos is in my post after Some crash oops logs are below.