All Activity

This stream auto-updates     

  1. Past hour
  2. I did similar research some time ago and it resulted as M4V2 with Silicon Power P34A80 NVMe. Sure, this SSD is overkill for M4V2, as only two PCI lanes are used, but I got it for half price. PCIe 2.1 x2 theoretical throughput can't exceed 1GB/s. In my case 663 MB/s is OK, as board is used nonstop as Graylog, InfluxDB+Grafana and Pi-Hole server - even during this benchmark. Not sure about T4, but M4V2 can't boot from NVMe. Even when Armbian is moved to and run from NVMe, so SD card shall stay in slot.
  3. @Adrian Cable - I made the changes for sunxi-current and pushed to the repo: https://github.com/armbian/build/commit/b2adb2935b4dcee57c982a1447de8cf75760dd2a. This change adds a new boot overlay for the sun8i-h3 that enables a maximum of 1.3GHz at a CPU core voltage of 1.3v. If you use this overlay, I strongly recommend you try driving the board hard to ensure stability (e.g., "stress --cpu 4", etc.) Historically on most of my boards the maximum I could push to was 1.2GHz at 1.3v, which is why I added a 1.2GHz overlay for the H5 (and I could only get to 1.368GHz w/a 1.4v core voltage). I can do the same for the H3, but am short on time atm. I'll also add this overlay to sunxi-legacy as well, but I won't be able to get to this later. I tested this on one of my H3 boards w/a max CPU voltage of 1.3v: /boot/armbianEnv.txt (note the addition of "cpu-clock-1.3GHz-1.3v" to the "overlays=" line): verbosity=7 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost1 usbhost2 uart1 cpu-clock-1.3GHz-1.3v rootdev=UUID=3ad712a7-75cb-4ac1-8cfa-dbb67df8f239 rootfstype=f2fs extraargs=net.ifnames=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u After booting with this overlay, from "cpufreq-info", w/everything else at the defaults, maximum clock rate is now 1.30GHz: analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.30 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:96.94%, 648 MHz:0.35%, 816 MHz:0.04%, 960 MHz:0.03%, 1.01 GHz:0.03%, 1.06 GHz:0.02%, 1.10 GHz:0.02%, 1.15 GHz:0.03%, 1.20 GHz:0.02%, 1.22 GHz:0.01%, 1.25 GHz:0.01%, 1.30 GHz:2.50% (253) Please give this a try and let me know how it goes If 1.3GHz is unstable, I'll try to expedite adding the 1.2GHz overlay as well.
  4. I am plenty familiar with the build tools, but not so much with bringing up a new board. To quote a Donald Rumsfeld phrase, there are alot of "unknown unknowns". I suppose I could try booting a similar image and see what happens...
  5. Today
  6. I would have been back sooner, but being new on the forum, it seemed to not let me post more than once in 24 hours. Or something. But I was busy with this most of yesterday in an interesting way. I gave up (for now anyway) doing this on my Fedora Desktop. What I did was to download Armbian for my Orange Pi PC 2, put it on an SD card and run it on the Orange Pi. Then I used armbian-config to download kernel sources, which worked just fine, placing them in /usr/src. Then I could remove the SD card, mount it on my desktop and copy the sources for my convenience. Then I put the SD card back into the Orange Pi, fired it up, did a cd to /usr/src/linux-source-5.4.43-sunxi64 and typed "make". It plowed away for 10 hours or more (it finished during the night when I was asleep). It hung once in the afternoon requiring a reboot and restarting make. The advantage of this for me, is the build leaves object files (*.o) in the source tree letting me know at a glance just what source files were involved in the build. This has proven invaluable for me in the past when rummaging around in the linux sources. Now I can pull that SD card again and copy these files to my desktop for study. It would be nice to do as Werner says and be able to grab the sources and patch them on my desktop. I have the idea of studying the Armbian build system and reproducing parts of it in Python to liberate it from being debian dependent -- but using the actual target system was the easy way. So thanks for the advice. I still haven't looked at why the R_WDOG patch failed, but I figure that is something that someone else will run into and sort out. Thanks again. Tom
  7. 5kft - this is great. If you have something you would like me to test on H2+/H3, happy to do so. -Adrian
  8. Because the opp table in the DTs are common and used for all H3/H5 boards, not just your specific OPi Zero. The CPU regulator voltage defines the maximum clock rate available, specific to each board. Actually this behavior is completely correct - it's how the CPU clock system is defined. You do not want to make a general PR to increase the default clocks for lower voltages here because this will introduce instabilities across all other AW-based boards (!). There is a very easy way to enable this, however - you can use an overclock overlay. I created a few of these a couple of years ago; see this thread for more information: Now I just noticed that this patch apparently didn't make it over to the new sunxi-current branch (5.7); I'll fix this. I also used the H5 prefix for this - I haven't tried it on an H3, but given the common opp table it should work. I'll take a look at cleaning this up now for sunxi-current and will post back.
  9. Oh ! I've completely forgot about the hack, I've forgot to add it in /etc/rc.local of the 5.8.y build ... I will check now ... EDIT: Thanks for the reminder : it is not freezing any more, at least until now !
  10. I meant the devfreq hack: https://armbian.atlassian.net/browse/AR-374
  11. I havent tried that. My first priority is to recover some of my data :(. Is there any way i can connect the hard disks to a desktop and use a software to recover the data? It is RAID5 with 4 hard disks.
  12. Armbian images are tested - we don't want to waste your time ... but did you read what's written on the download pages? Tinkerboard has some critical problems, which are impossible to fix in software.
  13. Does the board works fine with a clean latest Armbian and some other drive?
  14. If you mean this patch/kernel/sunxi-dev/add-missing-H6-gpu-opp-in-5.7.y.patch, Yes it is still applied, although I had to remove CPU OPP since it became a duplicate. But it most probably related to those ones since I had to disabled them completely (I could not easily fix them) : patch/kernel/sunxi-dev/sun50i-h6-drm_panfrost-1-missing-remove-opp-table-in-case-of-failure.patch patch/kernel/sunxi-dev/sun50i-h6-drm_panfrost-2-add-devfreq-regulator-support.patch
  15. The following should do the job : dd if=/dev/zero of=/dev/mmcblk0 bs=1024 seek=8 count=800
  16. Hi everyone. I just updated my system and it seems that `/dev/thermal-cpu` has vanished. Meaning that fancontrol cannot find it. How exactly is this directory created and how can I fix it? edit: I was able to solve the issue by changing `armada_thermal` to `f10e4078.thermal` in `/etc/udev/rules.d/90-helios4-hwmon.rules`
  17. Thanks Nico - what kernel should I use ? also if you can point me to the script that controls the fan it would be great
  18. Hello Team, I have been using a Helios4 NAS for the last year or so. It had been working great until now. I use 4 Seagate hard disks with 4TB each (ST4000DM004). I have always used a UPS with the device and it was safe. More recently we had some problems with the UPS and I had to connect it directly to the power source. About two days ago, I tried doing an apt-upgrade/apt-update and the NAS came crashing down. It now no longer recognizes my hard disk. After a lot of troubleshooting, we found out that the SATA controller is not recognizing the hard disks. There are times (very rare) where the disks are recognized, but most of the time, it fails to detect the drives and mount the drive. I had used Open Media Vault to configure the RAID5 array. The NAS boots off the Armbian OS from an SDCard (16GB). We tried using lsscsi and it doesn’t detect any drives. OpenMediaVault detects the drives sometimes but other times it does not. But this morning it loaded up all the drives and as I tried to backup the data, it started crashing and rebooting. Has anybody faced similar problems in the past? I have a feeling the on-board SATA controller is not working. What can I do to troubleshoot the problem and look for an easy fix? Any suggestions would be greatly appreciated. PS: I have attached all logs from /var/log and the output of my connection to putty. Thanks, Sandeep Archive.zip putty.zip
  19. Would be my guess as well. But now something strange happened. Loaded an image for a Orange Pi Zero Plus (not Plus2 H5) and it booted. To be clear my board is definitely a Orange Pi Zero Plus2 H5 See log here: https://pastebin.com/SR3hywPM
  20. If you have switched the sd card as well as the power source and cable and somebody else with the same board can boot the same image flawless....then well the board might be broken.
  21. So it seems it does boot from SD, but hangs somewhere during kernel loading. Could the Orange Pi be broken ?
  22. Your board is way outdated and will not receive support. Please upgrade to a more recent kernel.
  23. Unfortunately I gets the same "rcu_sched detected stalls on CPUs/tasks" error even with corrected "/etc/default/cpufrequtils" file 2020-08-06T13:30:01+09:00 10.8.2.182 CRON[14672]: pam_unix(cron:session): session opened for user root by (uid=0) 2020-08-06T13:30:01+09:00 10.8.2.182 CRON[14671]: pam_unix(cron:session): session opened for user root by (uid=0) 2020-08-06T13:30:01+09:00 10.8.2.182 CRON[14673]: (root) CMD (/root/logDasIpHealthInfo.sh) 2020-08-06T13:30:01+09:00 10.8.2.182 CRON[14674]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs) 2020-08-06T13:30:01+09:00 10.8.2.182 CRON[14672]: pam_unix(cron:session): session closed for user root 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999178] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999216] rcu: #0110-...!: (2 ticks this GP) idle=77a/0/0x1 softirq=31006567/31006567 fqs=1 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999221] rcu: #011(detected by 2, t=44023 jiffies, g=104505893, q=78) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999243] Sending NMI from CPU 2 to CPUs 0: 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999661] NMI backtrace for cpu 0 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999666] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.62-sunxi #5.92 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999669] Hardware name: Allwinner sun8i Family 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999672] PC is at neigh_timer_handler+0x19e/0x1a4 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999675] LR is at 0x1cecf462 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999678] pc : [<c07f4886>] lr : [<1cecf462>] psr: 00010133 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999681] sp : c0e01de0 ip : d72bc300 fp : c0e04d70 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999684] r10: 1f19f000 r9 : 00000001 r8 : c9f84014 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999687] r7 : 00000002 r6 : c9f84018 r5 : c9f84000 r4 : c9f84030 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999691] r3 : c07f3025 r2 : 00000004 r1 : 000004e2 r0 : c0ab89b8 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999694] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999697] Control: 50c5387d Table: 411c406a DAC: 00000051 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999701] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.62-sunxi #5.92 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999704] Hardware name: Allwinner sun8i Family 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999708] [<c010d74d>] (unwind_backtrace) from [<c010a2f1>] (show_stack+0x11/0x14) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999712] [<c010a2f1>] (show_stack) from [<c08fc121>] (dump_stack+0x69/0x78) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999716] [<c08fc121>] (dump_stack) from [<c090036d>] (nmi_cpu_backtrace+0x59/0x90) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999720] [<c090036d>] (nmi_cpu_backtrace) from [<c010c5d9>] (handle_IPI+0x85/0x2c0) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999723] [<c010c5d9>] (handle_IPI) from [<c05c9c7f>] (gic_handle_irq+0x67/0x68) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999727] [<c05c9c7f>] (gic_handle_irq) from [<c0101a65>] (__irq_svc+0x65/0x94) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999730] Exception stack(0xc0e01d90 to 0xc0e01dd8) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999734] 1d80: c0ab89b8 000004e2 00000004 c07f3025 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999738] 1da0: c9f84030 c9f84000 c9f84018 00000002 c9f84014 00000001 1f19f000 c0e04d70 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999741] 1dc0: d72bc300 c0e01de0 1cecf462 c07f4886 00010133 ffffffff 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999745] [<c0101a65>] (__irq_svc) from [<c07f4886>] (neigh_timer_handler+0x19e/0x1a4) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999749] [<c07f4886>] (neigh_timer_handler) from [<c0170037>] (call_timer_fn+0x23/0x118) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999753] [<c0170037>] (call_timer_fn) from [<c01701bf>] (expire_timers+0x93/0xdc) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999757] [<c01701bf>] (expire_timers) from [<c01702a3>] (run_timer_softirq+0x9b/0x138) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999761] [<c01702a3>] (run_timer_softirq) from [<c010226d>] (__do_softirq+0xd5/0x27c) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999765] [<c010226d>] (__do_softirq) from [<c011fefb>] (irq_exit+0x8f/0xc0) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999769] [<c011fefb>] (irq_exit) from [<c015f855>] (__handle_domain_irq+0x49/0x84) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999773] [<c015f855>] (__handle_domain_irq) from [<c05c9c51>] (gic_handle_irq+0x39/0x68) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999776] [<c05c9c51>] (gic_handle_irq) from [<c0101a65>] (__irq_svc+0x65/0x94) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999780] Exception stack(0xc0e01f18 to 0xc0e01f60) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999783] 1f00: 00000000 23391778 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999787] 1f20: dff55438 c0116441 ffffe000 c0e04d70 c0e04db8 00000001 00000000 c0e04d48 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999791] 1f40: c0dba870 00000000 c0e03d00 c0e01f68 c01078f3 c01078f4 40010033 ffffffff 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999795] [<c0101a65>] (__irq_svc) from [<c01078f4>] (arch_cpu_idle+0x28/0x2c) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999799] [<c01078f4>] (arch_cpu_idle) from [<c013e96b>] (do_idle+0x14b/0x1d8) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999803] [<c013e96b>] (do_idle) from [<c013ebed>] (cpu_startup_entry+0x19/0x1c) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941308.999807] [<c013ebed>] (cpu_startup_entry) from [<c0d00bad>] (start_kernel+0x3a7/0x3c6) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000263] rcu: rcu_sched kthread starved for 44021 jiffies! g104505893 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=3 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000266] rcu: RCU grace-period kthread stack dump: 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000273] rcu_sched R running task 0 10 2 0x00000000 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000299] [<c090acdb>] (__schedule) from [<c090b247>] (schedule+0x2f/0x68) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000314] [<c090b247>] (schedule) from [<c090daf7>] (schedule_timeout+0x77/0x320) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000333] [<c090daf7>] (schedule_timeout) from [<c016af6f>] (rcu_gp_kthread+0x41f/0x728) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000350] [<c016af6f>] (rcu_gp_kthread) from [<c0132ae9>] (kthread+0xfd/0x104) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000363] [<c0132ae9>] (kthread) from [<c01010f9>] (ret_from_fork+0x11/0x38) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000368] Exception stack(0xd7127fb0 to 0xd7127ff8) 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000376] 7fa0: 00000000 00000000 00000000 00000000 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000386] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 2020-08-06T13:30:02+09:00 10.8.2.182 kernel: [1941309.000395] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Watchdog timeout (limit 3min)! 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Killing process 708 (systemd-logind) with signal SIGABRT. 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Main process exited, code=killed, status=6/ABRT 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Failed with result 'watchdog'. 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Service has no hold-off time, scheduling restart. 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 1. 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: Stopped Login Service. 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: Starting Login Service... 2020-08-06T13:31:05+09:00 10.8.2.182 systemd-logind[14740]: New seat seat0. 2020-08-06T13:31:05+09:00 10.8.2.182 systemd[1]: Started Login Service. 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-timesyncd.service: Watchdog timeout (limit 3min)! 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-timesyncd.service: Killing process 329 (systemd-timesyn) with signal SIGABRT. 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-resolved.service: Watchdog timeout (limit 3min)! 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-resolved.service: Killing process 336 (systemd-resolve) with signal SIGABRT. 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Watchdog timeout (limit 3min)! 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Killing process 14740 (systemd-logind) with signal SIGABRT. 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Main process exited, code=killed, status=6/ABRT 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Failed with result 'watchdog'. 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Service has no hold-off time, scheduling restart. 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 2. 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: Stopped Login Service. 2020-08-06T13:34:05+09:00 10.8.2.182 systemd[1]: Starting Login Service... 2020-08-06T13:34:06+09:00 10.8.2.182 systemd-logind[14771]: New seat seat0. 2020-08-06T13:34:06+09:00 10.8.2.182 systemd[1]: Started Login Service. This kernel hang occurred right after 2 CRON jobs started at the same time, hence CPU was not in idle at the time. /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=816000 GOVERNOR=ondemand You can see armbian -U output here: https://paste.c-net.org/b1965858-723d-3409-2e8e-264e9e05d156 Running: 4.19.62-sunxi on Orange Pi Zero. I am going to check with GOVERNOR=performance Can anybody give me a hint/clues what might have caused this error and how to solve it? Thank you
  24. Hm odd. Maybe someone else has an OPi3 laying around and test if hostapd is broken for some reason. I don't have an H6 board with WiFi to test... A few month ago I tested this with my OPi0 which worked flawless.
  25. Isn't it that way, that they HAVE, but also have to find bootloader on uSD? I remember there were instructions on forum to clear xx first kB on uSD to prevent booting from SD after installing system on eMMC. Don't remember numbers. But this case one should copy these xx kB to a file, then clear it to switch to eMMC, doing reverse (copy from file to SD) for revert to uSD booting?
  1. Load more activity