djurny
-
Posts
58 -
Joined
-
Last visited
Posts posted by djurny
-
-
Hi,
I found myself in a similar situation, (on OrangePi Zero, but method described here should also apply here) where my I2C based DS3231 was detected last (rtc1) and the SoC's RTC detected first (rtc0). Looks like all kernel and userspace processes & tools use first detected RTC only (11 minute sync), timedatectl, ntp[sec]d. Tried some udev rules to rename the devices based on their DEVPATH, but this did not work. I also did not want to start renaming device nodes or do some symbolic link cooking to get it to work.
What did work (for my OrangePi Zero): Add an overlay where the SoC's RTC is aliased to rtc1 and the I2C based one is aliased as rtc0:
/dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; /* * Aliases can be used to set the external RTC as rtc0 * Needs supplying the correct path to the I2C controller RTC is connected to, * this example is for I2C0 on H2+ (TWI0 on PA11 + PA12) * NOTE: setting time at boot by the kernel * may not work in some cases if the external RTC module is loaded too late */ fragment@0 { target-path = "/aliases"; __overlay__ { rtc0 = "/soc/i2c@1c2ac00/ds3231@68"; }; }; fragment@1 { target = <&i2c0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; ds3231@68 { compatible = "dallas,ds3232"; reg = <0x68>; status = "okay"; }; }; }; fragment@2 { target-path = "/aliases"; __overlay__ { rtc1 = "/soc/rtc@1f00000"; }; }; fragment@3 { target = <&rtc>; __overlay__ { rtc@1f00000 { status = "disabled"; }; }; }; };The SoC's RTC location should be matched to your SoC in fragments 2 and 3 (or remove fragmet 3 altogether).
Also, the 'compatible' line should be modified to match your SoC's/board's DT as well.
The overlay is based on the one available here. Modified the ds1307 to ds3232 after reading this post. Added the fragments 2 and 3 to alias the SoC's RTC to rtc1, the 'disable' part is not working.
Hope this helps for you as well:
Groetjes,
-
Hi,
I have a similar possible identical issue. One of my NanoPi R2S systems is running as my VPN gateway (for both data and Pihole DNS). On several occasions my Pihole get shut (pun intended) -- DNS stops working due to my VPN gateway being unreachable on it's LAN side. On the serial console there are no warnings, errors or messages of any kind, bar armbianmonitor.
02:09:48: 408MHz 0.04 1% 0% 0% 0% 0% 0% 50.8°C 0/5 02:09:53: 600MHz 0.04 2% 1% 0% 0% 0% 0% 51.2°C 0/5 02:09:58: 1200MHz 0.27 6% 4% 0% 1% 0% 0% 53.3°C 0/5 02:10:03: 408MHz 0.25 3% 1% 1% 0% 0% 0% 50.8°C 0/5 02:10:08: 408MHz 0.31 1% 0% 0% 0% 0% 0% 51.7°C 0/5 02:10:14: 408MHz 0.41 1% 1% 0% 0% 0% 0% 50.8°C 0/5 02:10:19: 408MHz 0.38 1% 0% 0% 0% 0% 0% 51.7°C 0/5 02:10:24: 408MHz 0.43 1% 1% 0% 0% 0% 0% 50.4°C 0/5 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 02:10:29: 1200MHz 0.55 5% 4% 0% 0% 0% 0% 52.1°C 0/5 02:10:34: 600MHz 0.67 1% 1% 0% 0% 0% 0% 50.8°C 0/5 02:10:39: 408MHz 0.78 1% 1% 0% 0% 0% 0% 51.2°C 0/5 02:10:45: 408MHz 0.87 2% 1% 0% 0% 0% 0% 50.4°C 0/5 02:10:50: 600MHz 0.96 1% 1% 0% 0% 0% 0% 50.8°C 0/5 02:10:55: 408MHz 1.05 1% 1% 0% 0% 0% 0% 52.5°C 0/5The interesting thing is that the load number seems to increase at some point: where it was average around well below 0.8 before, it started to creep up to around 7.00.
07:23:16: 408MHz 7.05 1% 1% 0% 0% 0% 0% 51.2°C 0/5 07:23:21: 1200MHz 7.05 1% 1% 0% 0% 0% 0% 52.5°C 0/5 07:23:26: 1200MHz 7.04 2% 2% 0% 0% 0% 0% 54.6°C 0/5After attempting to log in on the serial console, there was nothing in 'top' indicating any processes were hogging up the cores causing high load numbers at all:
SpoilerTasks: 129 total, 1 running, 128 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.5 us, 4.7 sy, 0.0 ni, 91.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 978.0 total, 328.7 free, 116.5 used, 532.9 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 766.2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 662 root 20 0 8976 3068 2656 R 15.0 0.3 0:00.07 top 1 root 20 0 166444 9816 7116 S 0.0 1.0 0:31.19 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:01.80 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu+ 9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks+ 10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks+ 11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks+ 12 root 20 0 0 0 0 S 0.0 0.0 1:16.02 ksoftirqd+ 13 root 20 0 0 0 0 I 0.0 0.0 4:08.37 rcu_preem+ 14 root rt 0 0 0 0 S 0.0 0.0 0:00.32 migration+ 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1 17 root rt 0 0 0 0 S 0.0 0.0 0:00.35 migration+ 18 root 20 0 0 0 0 S 0.0 0.0 1:05.48 ksoftirqd+ 21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2(Note that I did have to "terminate all tasks" using <BRK>+e to be able to login on the serial console, so the 'top' results might be useless here.)
Currently I have added the udev rule to the system to disable TX and RX offloading, as well as to disable the link power management for the RTL8153 device.
SUBSYSTEM!="net", GOTO="__rtl815x_end" ACTION!="add", GOTO="__rtl815x_end" ENV{ID_VENDOR_ID}!="0bda", GOTO="__rtl815x_end" ENV{ID_MODEL_ID}!="8153", GOTO="__rtl815x_end" LABEL="__rtl815x_disable_lpm" RUN+="/bin/sh -c 'echo %E{ID_VENDOR_ID}:%E{ID_MODEL_ID}:k > /sys/module/usbcore/parameters/quirks'" LABEL="__rtl815x_disable_offloading" RUN+="/usr/sbin/ethtool -K $name rx off tx off" LABEL="__rtl815x_end"(Bit modified to also apply to any other RTL8153 device, to use the assigned name instead of hardcoded 'lan0'.)
Spoilers below on 'blocked task state' show some links to the r8152 module and RTL8153 device.
Spoiler[426200.919448] sysrq: Show Blocked State [426200.919840] task:ntpd state:D stack: 0 pid: 1378 ppid: 1 flags:0x00000001 [426200.920583] Call trace: [426200.920817] __switch_to+0x100/0x158 [426200.921145] __schedule+0x268/0x758 [426200.921463] schedule+0x40/0xf8 [426200.921751] schedule_preempt_disabled+0x18/0x30 [426200.922167] __mutex_lock.isra.13+0x16c/0x538 [426200.922562] __mutex_lock_slowpath+0x14/0x20 [426200.922948] mutex_lock+0x38/0x50 [426200.923252] __netlink_dump_start+0x90/0x278 [426200.923638] rtnetlink_rcv_msg+0x248/0x338 [426200.924009] netlink_rcv_skb+0x5c/0x120 [426200.924356] rtnetlink_rcv+0x18/0x28 [426200.924681] netlink_unicast+0x1b8/0x278 [426200.925037] netlink_sendmsg+0x1d4/0x3e0 [426200.925393] sock_sendmsg+0x4c/0x58 [426200.925712] __sys_sendto+0xd4/0x140 [426200.926037] __arm64_sys_sendto+0x28/0x38 [426200.926403] el0_svc_common.constprop.2+0x8c/0x190 [426200.926833] do_el0_svc+0x24/0x90 [426200.927136] el0_svc+0x14/0x20 [426200.927416] el0_sync_handler+0x90/0xb8 [426200.927763] el0_sync+0x160/0x180 [426200.928080] task:atop state:D stack: 0 pid:22113 ppid: 1 flags:0x00000001 [426200.928821] Call trace: [426200.929050] __switch_to+0x100/0x158 [426200.929376] __schedule+0x268/0x758 [426200.929693] schedule+0x40/0xf8 [426200.929982] rpm_resume+0x13c/0x718 [426200.930300] rpm_resume+0x280/0x718 [426200.930616] __pm_runtime_resume+0x3c/0x88 [426200.930987] usb_autopm_get_interface+0x24/0x60 [426200.931407] rtl8152_get_link_ksettings+0x40/0x390 [r8152] [426200.931899] ethtool_get_settings+0x68/0x1f0 [426200.932285] dev_ethtool+0x174/0x20b0 [426200.932617] dev_ioctl+0x1f0/0x388 [426200.932927] sock_do_ioctl+0x104/0x2c8 [426200.933266] sock_ioctl+0x320/0x520 [426200.933584] __arm64_sys_ioctl+0xa8/0xe8 [426200.933941] el0_svc_common.constprop.2+0x8c/0x190 [426200.934372] do_el0_svc+0x24/0x90 [426200.934676] el0_svc+0x14/0x20 [426200.934956] el0_sync_handler+0x90/0xb8 [426200.935303] el0_sync+0x160/0x180 [426200.935607] task:kworker/0:1 state:D stack: 0 pid: 5745 ppid: 2 flags:0x00000028 [426200.936355] Workqueue: ipv6_addrconf addrconf_verify_work [426200.936839] Call trace: [426200.937067] __switch_to+0x100/0x158 [426200.937392] __schedule+0x268/0x758 [426200.937710] schedule+0x40/0xf8 [426200.937998] schedule_preempt_disabled+0x18/0x30 [426200.938415] __mutex_lock.isra.13+0x16c/0x538 [426200.938808] __mutex_lock_slowpath+0x14/0x20 [426200.939194] mutex_lock+0x38/0x50 [426200.939498] rtnl_lock+0x18/0x28 [426200.939794] addrconf_verify_work+0x10/0x28 [426200.940174] process_one_work+0x1ec/0x4d0 [426200.940537] worker_thread+0x48/0x478 [426200.940869] kthread+0x140/0x150 [426200.941165] ret_from_fork+0x10/0x34 [426200.941488] task:kworker/2:2 state:D stack: 0 pid: 9367 ppid: 2 flags:0x00000028 [426200.942233] Workqueue: pm pm_runtime_work [426200.942595] Call trace: [426200.942823] __switch_to+0x100/0x158 [426200.943149] __schedule+0x268/0x758 [426200.943467] schedule+0x40/0xf8 [426200.943753] schedule_timeout+0x188/0x368 [426200.944116] msleep+0x2c/0x40 [426200.944390] napi_disable+0x58/0x100 [426200.944720] rtl8152_suspend+0x308/0x468 [r8152] [426200.945136] usb_suspend_both+0x90/0x240 [426200.945492] usb_runtime_suspend+0x30/0x80 [426200.945862] __rpm_callback+0x100/0x150 [426200.946211] rpm_callback+0x5c/0x88 [426200.946527] rpm_suspend.part.12+0xd8/0x568 [426200.946905] pm_runtime_work+0xb4/0x2b0 [426200.947252] process_one_work+0x1ec/0x4d0 [426200.947614] worker_thread+0x48/0x478 [426200.947946] kthread+0x140/0x150 [426200.948241] ret_from_fork+0x10/0x34 [426200.948565] task:kworker/3:3 state:D stack: 0 pid:11994 ppid: 2 flags:0x00000028 [426200.949314] Workqueue: events rtl_work_func_t [r8152] [426200.949767] Call trace: [426200.949995] __switch_to+0x100/0x158 [426200.950320] __schedule+0x268/0x758 [426200.950639] schedule+0x40/0xf8 [426200.950926] rpm_resume+0x13c/0x718 [426200.951243] rpm_resume+0x280/0x718 [426200.951560] __pm_runtime_resume+0x3c/0x88 [426200.951929] usb_autopm_get_interface+0x24/0x60 [426200.952341] rtl_work_func_t+0x74/0x3f8 [r8152] [426200.952750] process_one_work+0x1ec/0x4d0 [426200.953113] worker_thread+0x48/0x478 [426200.953446] kthread+0x140/0x150 [426200.953741] ret_from_fork+0x10/0x34 [426200.954069] task:ping state:D stack: 0 pid:19888 ppid: 19885 flags:0x00000024 [426200.954811] Call trace: [426200.955038] __switch_to+0x100/0x158 [426200.955365] __schedule+0x268/0x758 [426200.955682] schedule+0x40/0xf8 [426200.955970] schedule_preempt_disabled+0x18/0x30 [426200.956387] __mutex_lock.isra.13+0x16c/0x538 [426200.956780] __mutex_lock_slowpath+0x14/0x20 [426200.957167] mutex_lock+0x38/0x50 [426200.957470] rtnl_lock+0x18/0x28 [426200.957766] ip6mr_sk_done+0x38/0xe8 [426200.958091] rawv6_close+0x28/0x68 [426200.958403] inet_release+0x50/0xa8 [426200.958720] inet6_release+0x34/0x50 [426200.959045] __sock_release+0x44/0xb8 [426200.959376] sock_close+0x18/0x28 [426200.959680] __fput+0x78/0x230 [426200.959960] ____fput+0x10/0x20 [426200.960248] task_work_run+0x88/0xc8 [426200.960574] do_exit+0x370/0xab8 [426200.960869] do_group_exit+0x44/0xa0 [426200.961193] __wake_up_parent+0x0/0x30 [426200.961534] el0_svc_common.constprop.2+0x8c/0x190 [426200.961965] do_el0_svc+0x24/0x90 [426200.962267] el0_svc+0x14/0x20 [426200.962548] el0_sync_handler+0x90/0xb8 [426200.962895] el0_sync+0x160/0x180 [426200.963196] task:ip state:D stack: 0 pid:29248 ppid: 1373 flags:0x00000000 [426200.963936] Call trace: [426200.964164] __switch_to+0x100/0x158 [426200.964489] __schedule+0x268/0x758 [426200.964807] schedule+0x40/0xf8 [426200.965096] schedule_preempt_disabled+0x18/0x30 [426200.965513] __mutex_lock.isra.13+0x16c/0x538 [426200.965906] __mutex_lock_slowpath+0x14/0x20 [426200.966291] mutex_lock+0x38/0x50 [426200.966594] rtnetlink_rcv_msg+0xe4/0x338 [426200.966956] netlink_rcv_skb+0x5c/0x120 [426200.967303] rtnetlink_rcv+0x18/0x28 [426200.967628] netlink_unicast+0x1b8/0x278 [426200.967983] netlink_sendmsg+0x1d4/0x3e0 [426200.968339] sock_sendmsg+0x4c/0x58 [426200.968657] ____sys_sendmsg+0x284/0x2c8 [426200.969013] ___sys_sendmsg+0x84/0xc8 [426200.969346] __sys_sendmsg+0x6c/0xc0 [426200.969672] __arm64_sys_sendmsg+0x24/0x30 [426200.970043] el0_svc_common.constprop.2+0x8c/0x190 [426200.970473] do_el0_svc+0x24/0x90 [426200.970776] el0_svc+0x14/0x20 [426200.971056] el0_sync_handler+0x90/0xb8 [426200.971403] el0_sync+0x160/0x180 [426200.971712] task:ip state:D stack: 0 pid:29980 ppid: 29979 flags:0x00000001 [426200.972452] Call trace: [426200.972680] __switch_to+0x100/0x158 [426200.973006] __schedule+0x268/0x758 [426200.973324] schedule+0x40/0xf8 [426200.973613] schedule_preempt_disabled+0x18/0x30 [426200.974030] __mutex_lock.isra.13+0x16c/0x538 [426200.974422] __mutex_lock_slowpath+0x14/0x20 [426200.974808] mutex_lock+0x38/0x50 [426200.975111] __netlink_dump_start+0x90/0x278 [426200.975496] rtnetlink_rcv_msg+0x248/0x338 [426200.975866] netlink_rcv_skb+0x5c/0x120 [426200.976214] rtnetlink_rcv+0x18/0x28 [426200.976540] netlink_unicast+0x1b8/0x278 [426200.976895] netlink_sendmsg+0x1d4/0x3e0 [426200.977250] sock_sendmsg+0x4c/0x58 [426200.977568] __sys_sendto+0xd4/0x140 [426200.977892] __arm64_sys_sendto+0x28/0x38 [426200.978257] el0_svc_common.constprop.2+0x8c/0x190 [426200.978688] do_el0_svc+0x24/0x90 [426200.978991] el0_svc+0x14/0x20 [426200.979271] el0_sync_handler+0x90/0xb8 [426200.979617] el0_sync+0x160/0x180 [426200.979921] task:sudo state:D stack: 0 pid:30561 ppid: 30516 flags:0x00000001 [426200.980662] Call trace: [426200.980889] __switch_to+0x100/0x158 [426200.981215] __schedule+0x268/0x758 [426200.981532] schedule+0x40/0xf8 [426200.981821] schedule_preempt_disabled+0x18/0x30 [426200.982237] __mutex_lock.isra.13+0x16c/0x538 [426200.982630] __mutex_lock_slowpath+0x14/0x20 [426200.983015] mutex_lock+0x38/0x50 [426200.983318] __netlink_dump_start+0x90/0x278 [426200.983703] rtnetlink_rcv_msg+0x248/0x338 [426200.984073] netlink_rcv_skb+0x5c/0x120 [426200.984421] rtnetlink_rcv+0x18/0x28 [426200.984746] netlink_unicast+0x1b8/0x278 [426200.985102] netlink_sendmsg+0x1d4/0x3e0 [426200.985457] sock_sendmsg+0x4c/0x58 [426200.985774] __sys_sendto+0xd4/0x140 [426200.986099] __arm64_sys_sendto+0x28/0x38 [426200.986463] el0_svc_common.constprop.2+0x8c/0x190 [426200.986893] do_el0_svc+0x24/0x90 [426200.987195] el0_svc+0x14/0x20 [426200.987476] el0_sync_handler+0x90/0xb8 [426200.987823] el0_sync+0x160/0x180Backtrace of all active CPUs below.
Spoiler[426121.505605] sysrq: Show backtrace of all active CPUs [426121.506080] sysrq: CPU0: [426121.506336] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C 5.10.43-rockchip64 #21.05.4 [426121.507130] Hardware name: FriendlyElec NanoPi R2S (DT) [426121.507613] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [426121.508173] pc : arch_cpu_idle+0x18/0x28 [426121.508544] lr : arch_cpu_idle+0x10/0x28 [426121.508909] sp : ffff8000118b3e90 [426121.509222] x29: ffff8000118b3e90 x28: ffff800011510108 [426121.509725] x27: 0000000000000000 x26: ffff8000118c3ac0 [426121.510226] x25: 0000000000000000 x24: ffff800011307b70 [426121.510727] x23: ffff80001157e8b8 x22: ffff8000118b9948 [426121.511228] x21: ffff8000118ba2e8 x20: 0000000000000001 [426121.511728] x19: ffff8000118ba208 x18: 0000000000000000 [426121.512228] x17: 0000000000000000 x16: 0000000000000000 [426121.512728] x15: 0000000000000000 x14: 0000000000000000 [426121.513229] x13: 0000000000000000 x12: 0000000000000002 [426121.513729] x11: 0000000000000000 x10: 0000000000000a40 [426121.514229] x9 : ffff8000118b3de0 x8 : ffff8000118c4560 [426121.514730] x7 : 0000000000003b3e x6 : 0000094d2d44750d [426121.515230] x5 : 00ffffffffffffff x4 : ffff80002e7c8000 [426121.515731] x3 : 0000000000000001 x2 : 0000000000000000 [426121.516230] x1 : 00000000778bc530 x0 : 00000000000000e0 [426121.516732] Call trace: [426121.516979] arch_cpu_idle+0x18/0x28 [426121.517320] default_idle_call+0x44/0x1bc [426121.517699] do_idle+0x204/0x278 [426121.518009] cpu_startup_entry+0x24/0x60 [426121.518380] rest_init+0xd4/0xe4 [426121.518692] arch_call_rest_init+0x10/0x1c [426121.519080] start_kernel+0x818/0x850 [426121.519534] sysrq: CPU2: [426121.519786] Call trace: [426121.520037] dump_backtrace+0x0/0x200 [426121.520389] show_stack+0x18/0x28 [426121.520708] showacpu+0x68/0x80 [426121.521015] flush_smp_call_function_queue+0x100/0x250 [426121.521495] generic_smp_call_function_single_interrupt+0x14/0x20 [426121.522056] ipi_handler+0x7c/0x370 [426121.522394] handle_percpu_devid_fasteoi_ipi+0x9c/0x1f0 [426121.522878] generic_handle_irq+0x30/0x48 [426121.523254] __handle_domain_irq+0x94/0x108 [426121.523650] gic_handle_irq+0xc4/0xe0 [426121.523997] el1_irq+0xc8/0x180 [426121.524304] ep_item_poll.isra.24+0x68/0xe0 [426121.524701] ep_scan_ready_list.isra.23+0xa4/0x1d0 [426121.525147] ep_poll+0x100/0x3b8 [426121.525461] do_epoll_wait+0xd8/0x128 [426121.525812] __arm64_sys_epoll_pwait+0x5c/0xd8 [426121.526231] el0_svc_common.constprop.2+0x8c/0x190 [426121.526679] do_el0_svc+0x24/0x90 [426121.526998] el0_svc+0x14/0x20 [426121.527295] el0_sync_handler+0x90/0xb8 [426121.527658] el0_sync+0x160/0x180 [426121.527974] sysrq: CPU1: [426121.528225] Call trace: [426121.528476] dump_backtrace+0x0/0x200 [426121.528828] show_stack+0x18/0x28 [426121.529157] showacpu+0x68/0x80 [426121.529465] flush_smp_call_function_queue+0x100/0x250 [426121.529946] generic_smp_call_function_single_interrupt+0x14/0x20 [426121.530508] ipi_handler+0x7c/0x370 [426121.530844] handle_percpu_devid_fasteoi_ipi+0x9c/0x1f0 [426121.531337] generic_handle_irq+0x30/0x48 [426121.531715] __handle_domain_irq+0x94/0x108 [426121.532111] gic_handle_irq+0xc4/0xe0 [426121.532460] el1_irq+0xc8/0x180 [426121.532767] syslog_print+0x120/0x278 [426121.533119] do_syslog.part.27+0x33c/0x488 [426121.533506] do_syslog+0x44/0x58 [426121.533820] kmsg_read+0x4c/0x68 [426121.534134] proc_reg_read+0x30/0xf8 [426121.534477] vfs_read+0xac/0x1d0 [426121.534788] ksys_read+0x68/0xf0 [426121.535100] __arm64_sys_read+0x1c/0x28 [426121.535467] el0_svc_common.constprop.2+0x8c/0x190 [426121.535915] do_el0_svc+0x24/0x90 [426121.536236] el0_svc+0x14/0x20 [426121.536534] el0_sync_handler+0x90/0xb8 [426121.536897] el0_sync+0x160/0x180As I did spot several references to either suspend states of the RTL8153 (rtl8152_get_link_ksettings, rtl8152_suspend, __pm_runtime_resume), it might be more related to the link power management issue referenced in this thread.
In the meantime, as this 'hangup' occurs only perhaps once every 1-2 weeks, I will monitor the system to see if it will happen still after the LPM and RX/TX offloading tweaks.
If anyone is interested in some more backtrace content, I can provide.
Groetjes,
-
Hi @tparys,
LUKS2 on-disk format is not supported/understood by cryptsetup 1.x, it requires cryptsetup 2.0 or higher. At that time, I do recall I had to build it (cryptsetup 2.x) from source on my Helios4 and Helios64 boxes which were at 4.4.x back then.
As mentioned, my memory is failing here as I cannot recollect or find any logs on the actual errors I encountered, but the errors thrown at me by LUKS(1) were putting me on all my wrong feet at that time.
Anyhow, I thought it is worth to check out to see if this might help out - or not of course.
Groetjes,
-
Hi @a5s397,
I also had some issues with my LUKS encrypted partitions after a kernel upgrade before, but I have a hard time remembering what actually happened and how I managed to get it working again.
Perhaps I'm stating the obvious, but are you sure you have a LUKS or LUKS2 type setup on your drive? As for me, I had to recompile LUKS2 in the past to get it to work for sure. Cannot really recall about the ... stopping here, just read your console.txt and you indeed have a LUKS2 format.
Can you paste the output of cryptsetup --version and a syslog or dmesg output just before, during and after your first initial attempt to luksOpen your device on the working and non-working setups?
Groetjes,
-
Hi,
You can try the following to get an idea of which process is modifying the file:
sudo apt-get install auditd sudo auditctl -w /boot/armbianEnv.txt -p wa sudo tail -F /var/log/audit/audit.logThe output should show actions performed on the file and (IIRC) the process ID performing those actions, perhaps that might help?
e.g.:
type=CWD msg=audit(1624526184.097:207): cwd="/home/djurny" type=PATH msg=audit(1624526184.097:207): item=0 name="/boot/" inode=7601 dev=b3:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1624526184.097:207): item=1 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.097:207): proctitle=xx type=SYSCALL msg=audit(1624526184.109:208): arch=40000028 syscall=94 per=800000 success=yes exit=0 a0=3 a1=81a4 a2=c80eeb00 a3=81a4 items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=PATH msg=audit(1624526184.109:208): item=0 name=(null) inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:208): proctitle=xx type=SYSCALL msg=audit(1624526184.109:209): arch=40000028 syscall=226 per=800000 success=yes exit=0 a0=1787820 a1=b6e3e1a0 a2=1907fc0 a3=1c items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=CWD msg=audit(1624526184.109:209): cwd="/home/djurny" type=PATH msg=audit(1624526184.109:209): item=0 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:209): proctitle=xxSource: Find which process is modifying a file [duplicate]
It honestly sounds a bit more like a filesystem that has lost track or a inode mixup somewhere? As someone mentioned, perhaps something else is writing to this file, thinking it is something else? Perhaps try to locate a symbolic (or hard)link to armbanEnv.txt:
## find any symbolic links to armbianEnv.txt sudo find / -xdev -type l -ls | egrep -i -- armbianEnv.txt ## find hardlinks to armbianEnv.txt - need to be on the same filesystem! sudo find / -xdev -samefile /boot/armbianEnv.txtGroetjes,
-
Hi,
To enable the armbianmonitor to show information on the running system on the serial console, I used to have a custom startup script, called from /etc/rc.local. After some time, I thought it was more neat to have this automatically started (and stopped) for login sessions that are started on serial consoles/terminals.
This lead (led?) me to the following systemd unit file:
[Unit] Description=armbianmonitor on ttyS2 Requires=serial-getty@ttyS2.service After=serial-getty@ttyS2.service After=getty.target BindsTo=serial-getty@ttyS2.service [Service] Type=idle ExecStartPre=-/bin/sleep 10 ExecStart=/usr/bin/armbianmonitor -m TTYPath=/dev/ttyS2 StandardInput=null StandardOutput=tty StandardError=syslog KillSignal=SIGKILL SendSIGHUP=yes [Install] WantedBy=serial-getty@ttyS2.serviceFile goes into /usr/lib/systemd/system/armbianmonitor@ttyS2.service. To 'activate' it, perform the following after creating the file at the specified location:
sudo systemctl daemon-reload sudo systemctl enable armbianmonitor@ttyS2 sudo systemctl stop armbianmonitor@ttyS2 sudo systemctl start armbianmonitor@ttyS2This is currently working for me on OrangePi Zero, NanoPi R2S, Helios4 (@ttyS0) and Helios64.
If you do not have serial-getty services started on ttyS2 - like in the example unit file - you will need to modify the 'ttyS2' with the serial console matching your situation.
Note that the new armbianmonitor@ttyX service will auto-start when seial-getty@ttyX is started and it will also stop when serial-getty@ttyX is stopped. This is to prevent orphaned armbianmonitors. Fun thing to try is to stop and start serial-getty@ttyX and also see the armbianmonitor service for that tty stop/start in tandem.
Hope this helps anyone out there, it's always nice to have serial output available in case things happen (and they always happen unexpectedly).
Groetjes,
p.s. See below spoiler for auto-adding these unit files based on your currently enabled serial-getty services.
Spoiler#!/bin/bash systemctl list-units --type=service --state=active,inactive --full --no-pager --no-legend --plain "serial-getty@*" | while read _UNIT _DONTCARE do _DEVICE="${_UNIT%.service}" _DEVICE="${_DEVICE##*@}" _FILE="/lib/systemd/system/armbianmonitor@${_DEVICE:?}.service" { cat << EOF [Unit] Description=armbianmonitor on ${_DEVICE:?} Requires=${_UNIT:?} After=${_UNIT:?} After=getty.target BindsTo=${_UNIT:?} [Service] Type=idle ExecStartPre=-/bin/sleep 10 ExecStart=/usr/bin/armbianmonitor -m TTYPath=/dev/${_DEVICE:?} StandardInput=null StandardOutput=tty StandardError=syslog KillSignal=SIGKILL SendSIGHUP=yes [Install] WantedBy=${_UNIT:?} EOF } | sudo tee "${_FILE:?}" > /dev/null sudo chown root:root "${_FILE:?}" sudo chmod 0644 "${_FILE:?}" sudo systemctl daemon-reload done # EOF -
Hi @Elektrický,
Nice tutorial, worked great for me. Bought a cheap GPS module:
And a pinheader to solder onto the OrangePi Zero board itself.
The only thing I had to change was to swap the RX/TX wires, as a straight connection did not work for my GPS board.
I did not have any success getting PPS to work through the USB connection (works as ttyACM). I had to use the GPIO dtb overlay and electrical connection as per your tut.
gpsd in action:
ntp[sec] in action:
Thanks a lot!
Groetjes,
p.s. I still have to figure out why I needed this
-
Hi,
Have you checked "nut" (network UPS tools) to see if they have some prefab solutions?
Perhaps a custom nut driver, as I recall they have this type of behavior already available for "regular" UPSes.
Groetjes,
-
Hi @lanefu,
For your usecase, best to do the following:
for A in /dev/ttyUSB* do ( echo "${A:?}" udevadm info --query property "${A:?}" | egrep -- '^ID_(PATH|SERIAL_SHORT)=' ) | xargs doneThat will give you either the USB port location in the USB tree (ID_PATH) or any serial number (ID_SERIAL_SHORT) as provided by udev, ready to make rules with.
As I bought a lot of low-end USB-serial dongles, they do not have any serial - hence the use of the USB port location. I run the script (attached in earlier post) every time I change something in the hub, or when I plug the hub into another device.
Let me know if this helped you!
Groetjes,
-
Hi, sorry, I forgot to mention that the configure-serial-tty script does require some target modification: it depends on the baudrate being fixed on the target, as sending <BRK> both triggers Magic SysRq and optional baudrate switch by *getty. To get this to work on my setup with highish successrate, I reconfigured the target's serial-getty configurations to only work on one baudrate.
See parts of my ansible task that sets that puppy up:
Spoiler#... - name: Determine serial-getty services shell: | systemctl list-units --type=service --state=active,inactive --full --no-pager --no-legend --plain "{{item}}@*" | while read _UNIT _DONTCARE do echo "{{item}} ${_UNIT:-N/A}" done with_items: - 'serial-getty' - 'armbianmonitor' register: service_units - name: Modify serial-getty console baudrate shell: | set -x _TIMESTAMP=`date -Isec` _TMP=`mktemp` _ITEM_STDOUT="{{item.stdout}}" echo "${_ITEM_STDOUT:-}" | while read _SERVICE _UNIT do _UNITFILE=`systemctl show "${_UNIT:?}" | sed -n '/FragmentPath/ { s/^FragmentPath=//p; q; }'` sed -n 's/^ExecStart=//p;' "${_UNITFILE:?}" > "${_TMP}" read -r _CMDLINE < "${_TMP}" eval set -- ${_CMDLINE:-} OPTIND=2 # skip ARGV[0] while getopts ':o:-:' OPT do : done shift $(( ${OPTIND:-} - 1 )) _BAUDRATES="${1:?}" _BAUDRATE_NEW="${_BAUDRATES%%,*}" if [ "${_BAUDRATE_NEW:-}" != "${_BAUDRATES:-}" ] then _BACKUP="${_UNITFILE:?}.${_TIMESTAMP:?}~" echo "Making backup of '${_UNITFILE:-N/A}' to '${_BACKUP:-N/A}'." cp -ab "${_UNITFILE:?}" "${_BACKUP:?}" echo "Modifying '${_UNITFILE:-N/A}'." ## Example: ## ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 1500000 %I $TERM sed -i -E " /^ExecStart=/ { h; s/^[ \t]*[^#].*/#[DISABLED by Ansible] &/p; g; i #[BEGIN] Ansible managed s/ *\<-s\>//; s/--keep-baud[[:blank:]]//; s/--extract-baud[[:blank:]]//; s/${_BAUDRATES}/${_BAUDRATE_NEW}/; a #[END] Ansible managed }" "${_UNITFILE:?}" echo "# diff -y -W\${COLUMNS:-} '${_UNITFILE:-}' '${_BACKUP:-}'" echo "Changed!" systemctl daemon-reload fi done rm "${_TMP:?}" register: serial_getty_config changed_when: "'Changed!' in serial_getty_config.stdout" vars: - __item: 'serial-getty' loop: "{{ service_units.results }}" when: - __item == item.item #...The ansible task shell script will try to parse the commandline to get the currently configured baudrates. It assumes the baudrates are sorted from high to low, i.e. 1500000,115200,38400,9600 for my NanoPi R2S and Helios64 boxen. It will replace the baudrates with the most-left it had parsed (which should be the highest baudrate). It also will disable the options to *getty that skip setting the baudrate explicitly (i.e. keep-baud and extract-baud).
Let me know if this worked out for you!
Groetjes,
-
Hi,
See below udevadm rule:
Spoiler## ## __usb_serial ## ACTION=="remove", GOTO="__usb_serial_end" SUBSYSTEM!="tty", GOTO="__usb_serial_end" ENV{ID_VENDOR_ID}!="067b", GOTO="__usb_serial_ftdi" ENV{ID_MODEL_ID}!="2303", GOTO="__usb_serial_ftdi" LABEL="__usb_serial_pl2303" ## these devices do not have a serial number ## assignment is done based on physical location: usb-port, usb-hub ## be sure to plug in all the usb dongles in the same positions, otherwise this assignment is messed up! #[BEGIN] AUTOMATICALLY GENERATED CONTENT ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.2:1.0", SYMLINK+="serial/by-name/sinaspi" ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.3:1.0", SYMLINK+="serial/by-name/orangepi" ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.1.2:1.0", SYMLINK+="serial/by-name/pi2-01" ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.1.3:1.0", SYMLINK+="serial/by-name/pi2-02" ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.4.1:1.0", SYMLINK+="serial/by-name/nanopi0" ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.1.4:1.0", SYMLINK+="serial/by-name/pi2-03" ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.4.2:1.0", SYMLINK+="serial/by-name/nanopi1" ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.1.1:1.0", SYMLINK+="serial/by-name/kobol0" ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.5.4.4:1.0", SYMLINK+="serial/by-name/bluebox1" #[END] AUTOMATICALLY GENERATED CONTENT LABEL="__usb_serial_ftdi" ENV{ID_VENDOR_ID}!="0403", GOTO="__usb_serial_end" ENV{ID_MODEL_ID}!="6015", GOTO="__usb_serial_end" ## these devices have a serial number ENV{ID_SERIAL_SHORT}=="DT03O6AD", SYMLINK+="serial/by-name/kobol0" ENV{ID_SERIAL_SHORT}=="DJ00JULE", SYMLINK+="serial/by-name/bluebox1" ENV{ID_SERIAL_SHORT}=="DJ00JDCX", SYMLINK+="serial/by-name/bluebox0" LABEL="__usb_serial_end" ## EOFAnd below bash snippet of how to generate it:
generate_udev_rule() { # <dev> <name> typeset _DEV="${1:?}" typeset _NAME="${2:?}" typeset _ID_PATH _ID_PATH="$( udevadm info --query property "${_DEV}" | sed -n '/^ID_PATH/ { s/^ID_PATH=//p; q; }' )" printf "ENV{ID_PATH}==\"%s\", SYMLINK+=\"serial/by-name/%s\"\n" \ "${_ID_PATH:?}" \ "${_NAME:?}" }
Hope that helps!
Groetjes,
-
Hi,
I made a small detection script using expect. That will spit out the hosts it found per try and baudraute guesstimate. Afterwards it will query the USB port location using udevadm info and build udev rules on a name basis for the hosts it found on those ports.
It's not a generic solution, let me know if you are interested, I'll share when back at my workstation.
Groetjes,
-
Hi,
How are you configuring your interfaces? ifup/ifdown or NetworkManager?
How many NICs do you have on the system? Both are connected to the same network?
Can you share output of:
# show current dhcp clients pgrep -al dhclient # show network manager info sudo nmcli dev sh sudo nmcli con sh # show interface info sudo ifconfig -a # show ifup/ifdown config cat /etc/network/interfaces cat /etc/network/interfaces.d/* # show current listening adresses of dnsmasq sudo netstat -anp -AipGroetjes,
-
Hi,
On my orangepi zero (256MB) running armbian image, I am observing some odd behavior that I do not fully understand.
SpoilerLinux sinaspi 5.10.16-sunxi #21.02.2 SMP Sun Feb 14 21:12:17 CET 2021 armv7l GNU/Linux Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: busterIn an effort to 'harden' the orangepi zero configuration (by making the user experience annoying), I have shortened the sudo password prompt timeout. On the orangepi zero board, the following setting results in a timeout of only 2 seconds, instead of 15 seconds:
#[BEGIN] Ansible managed ## DMZ special: Authentication always required except for TOOLS djurny ALL = (root) PASSWD: ALL, NOPASSWD: TOOLS ## DMZ special: Stricter timeout settings Defaults:djurny passwd_timeout=0.25 Defaults:djurny timestamp_timeout=0 Defaults:djurny !logfile Defaults:djurny !syslog #[END]The exact same setting works as expected on raspberrypi and also as expected on nanopi R2S (armbian). Even more odd, setting the timeout to 1, the timeout is indeed set to 1 minute. Setting it to any fractional value like 0.3 or 0.5 it seems that the timeout calculation/interpretation is just not working as per manpage.
I'm not blocked by this, but if this is something that can be fixed easily, I will. For now, I've just the timeout to 1 minute (still more annoying than 15 minute timeout :-)
Anyone have experienced this as well?
Groetjes,
-
On 4/6/2021 at 12:10 PM, gprovost said:
I observe the same behavior. It seems to be linked to the introduction of the ESSIV kernel module in Linux Kernel 5.4
When creating and opening a new LUKS2 device, I can still see the interrupt of the crypto engine increasing. However when exercising the mounted encrypted device I don't see anymore increase of interrupt. What I realized is that there is this module essiv that get loaded and it seems to suggest it bypass the CESA crypto engine.
We need to find a way to force dm-crypt to use marvell_cesa
[..]
I also see the same. Tried simple things, like blacklisting essiv kernel module, but that prevents cryptsetup from working at all. There seems to be a dependency of the authenc kernel module to essiv. Not sure what it was before, as I don't have any box running on older kernel at the moment:
filename: /lib/modules/5.10.21-mvebu/kernel/crypto/essiv.ko [..] depends: authenc intree: Y name: essiv [..]Without authenc, crytpsetup starts complaining:
Apr 7 22:52:04 localhost kernel: [ 126.468108] device-mapper: ioctl: error adding target to table Apr 7 22:53:36 localhost kernel: [ 218.613317] essiv: Unknown symbol crypto_authenc_extractkeys (err -2)Groetjes,
-
@jsr my bad for the filename. Will check on my box as soon as I can.
Can you also do cryptsetup benchmark? I wonder if the names in crypto and the ones used by cryptsetup might have changed somehow.
Can you also share syslog of your box? The Marvell crypto drivers are also announced there, something might be off.
(Note I'm not an expert in this crypto business so I might be barking up the verkeerde boom.)
Groetjes,
Sent from my SM-T500 using Tapatalk -
@jsr, can you also check /proc/cryptinfo ? If I remember correctly, the mv/marvell module should show up in cryptinfo.
Edit: Also noticed you are LUKSing an mmc device. Not sure about the speed of device used in your setup, but my SD cards hardly reach 30MiB/s, even if CESA would work. Your throughput might be limited by additional bottleneck.
-
3 hours ago, SR-G said:
I would be fine with this solution on my side if it was working
(but on my side it's not enough to have same freq. for min and max value (also with 1.8 Ghz, i haven't tryed with lower values) + "performance" or "governor" mode.
Hi @SR-G,
FYI I have been running Linux kobol0 5.9.13-rockchip64 #trunk.16 SMP PREEMPT Tue Dec 8 21:23:17 CET 2020 aarch64 GNU/Linux for some days now. Still up. Perhaps you can give this one a try?
Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster/etc/default/cpufrequtils:
ENABLE=true MIN_SPEED=408000 MAX_SPEED=1200000 GOVERNOR=powersave(The box runs idles with 'powersave' and will be set to 'performance' when performing tasks.)
I do not know which non-dev kernel version this is? I assume it's 21.02 or 21.03?
Groetjes, -
3 hours ago, Glock24 said:
Hello, what's the disk space needed to seed the torrents?
On a side note, would creating a repository mirror also help?
Hi,
I would also be interested in finding out what it would take to host a local repository mirror. Over the past few weeks I did try to rsync the repo to local storage, but I'm not sure if that will affect anything on the 'other' side. Had to break off the rsync as it appeared to sync extremely slow.
Groetjes,
-
Hi @tikey,
Did you make sure the SSD is making proper contact to the backplane connector? I also have some issues with the utmost left disk slot, when I remove/replace a disk in that slot, I have to open up the box and make sure that the connectors are tight and snug. If that does not help, you can try to insert the disk in another slot to rule out any connector or power rail issues. When box is open, make sure to also press down on the connectors in the main board, to make sure this is not related to loose cables or such.
Just FYI, I run a CT120BX500SSD1 in my box, although not the same model, but it works :-)
Groetjes,
-
Hi @3735943886,
When logging in on any of "my" Armbian devices, it will also (start and) attach to GNU screen session. I sometimes observe this behavior as well (mostly in aptitude and not armbian-config), but have not been able to pinpoint when this starts or what causes this.
Have you tried to detach from GNU screen and retry? If it shows and behaves correctly outside of GNU screen, you can start digging in the environment settings first by 'env'. Perhaps also show the current active LOCALEs and write down the terminal encoding configured for your ssh client/terminal, as for me sometimes the arrow keys refuse service in aptitude (seems linked to either wrong terminal enconding on connecting client or wrong terminal type set on the Armbian side).
I'll try to reproduce at home and share results, perhaps you can do the same, so we can compare output.
Groetjes,
-
Hi @snakekick,
USB HDD for snapraid parity, sounds like my setup! You can check with vm_block_dump what is waking up your device:
echo 1 | sudo tee /proc/sys/vm/block_dumpAbove will enable logging of block device accesses into syslog.
If you want to see it happen without flooding your /var/log/syslog:
sudo service rsyslog stop while true ; do dmesg -cT ; done sudo service rsyslog startSee: Documentation for /proc/sys/vm/* and How to conserve battery power using laptop-mode.
You should also check if you have enabled SMART offline auto testing on your HDD; that might also wake up your drive, but this is done by the drive itself:
sudo smartctl -a /dev/sdX | egrep 'offline' sudo smartctl --offlineauto=off /dev/sdXOther things that will wake up your drive: temperature monitoring services like hddtemp, you should check if it offers options to not access the drive if it's in standby/sleep mode. Other things like blkid when used as root, will also check all blockdevices, even if you think it is using cache.
What is the brand of USB dock you are using? Perhaps your dock is doing something to the drive to wake it up regularly.
Hope that helps,
Groetjes,
-
1 hour ago, Z06Frank said:
Here is the serial output......
[..] libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! 276 bytes read in 19 ms (13.7 KiB/s) Applying user provided DT overlay dwc3-0-device.dtbo No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! Error applying DT overlays, restoring original DT ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 17971336 Bytes = 17.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Loading Ramdisk to f4dc3000, end f5ee6888 ... OK FDT and ATAGS support not compiled in - hanging ### ERROR ### Please RESET the board ###
Hi,
Not sure if I can help here, but willing to help.
Can you put the SDcard into another Linux system and list the contents of the /boot folder? Also, please share the contents of the /boot/armbianEnv.txt. Looks like the same thing I had once, after a downgrade of kernel, the DTB files were renamed or not present for unknown reasons.
Groetjes
-
3 hours ago, Z06Frank said:
Note: I tried the basic reset button; the HHD's spin (and blue LED's flicker) for about 25 sec and it freezes with all blue LED's solid.
Hi,
Can you connect the USB-C cable, connect to the serial console (1.500.000 baud and no HW/SW flow control) and post the output after a reboot/powercycle? What's on the serial console should point to what is going wrong.
Did you by any change update the system and continue without rebooting? I had something similar happen on one of the nanopi R2S boxes, where the update was not successful, resulting in an incomplete /boot folder.
Groetjes,
Real time clock DS3231
in Allwinner H2 & H3
Posted · Edited by djurny
formatting and added link to 11 minute sync
Hi @IgorS,
After following the how to's on this forum and the internets, would like to share some other things I did to make it work even better on my OrangePi Zero.
[...] overlays=usbhost2 usbhost3 uart1 pps-gpio i2c0 [...]/dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; /* * Aliases can be used to set the external RTC as rtc0. * Needs supplying the correct path to the I2C controller RTC is connected to, * this example is for I2C0 on H2+ (TWI0 on PA11/PA12). * NOTE: setting time at boot by the kernel * may not work in some cases if the external RTC module is loaded too late */ fragment@0 { target-path = "/aliases"; __overlay__ { rtc0 = "/soc/i2c@1c2ac00/ds3231@68"; }; }; fragment@1 { target = <&i2c0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; ds3231@68 { compatible = "dallas,ds3232"; reg = <0x68>; status = "okay"; }; }; }; };Save as rtc0-i2c0-ds3231.dts.
sudo armbian-add-overlay rtc0-i2c0-ds3231.dts/dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; /* * Aliases can be used to set the internal RTC as rtc1. */ fragment@0 { target-path = "/aliases"; __overlay__ { rtc1 = "/soc/rtc@1f00000"; }; }; fragment@1 { target = <&rtc>; __overlay__ { rtc@1f00000 { status = "disabled"; }; }; }; };Save as rtc1-soc.dts.
sudo armbian-add-overlay rtc1-soc.dtssudo systemctl stop fake-hwclock.service # stop sudo systemctl disable fake-hwclock.service # disable sudo systemctl mask fake-hwclock.service # really disableroot@sinaspi:~# ls -l /dev/rtc* lrwxrwxrwx 1 root root 4 Aug 5 22:57 /dev/rtc -> rtc0 crw------- 1 root root 253, 0 Aug 5 22:57 /dev/rtc0 crw------- 1 root root 253, 1 Aug 5 22:57 /dev/rtc1for RTC in /dev/rtc[0-9] do hwclock --rtc="${RTC:?}" --adjust hwclock --rtc="${RTC:?}" --systohc done sleep $(( 5 * 60 )) for RTC in /dev/rtc[0-9] do echo "${RTC:-N/A}:" hwclock --rtc="${RTC:?}" --get date --rfc-3339=ns doneOn my OrangePi Zero the SoC RTC is dashing ahead:
/dev/rtc0: 2021-08-08 09:17:52.760046+08:00 2021-08-08 09:17:52.526062078+08:00 /dev/rtc1: 2021-08-08 11:59:11.150733+08:00 2021-08-08 09:17:54.392611945+08:00(rtc0 = DS3231 and rtc1 = SoC RTC.)
On the same OrangePi Zero, there is also a GPS receiver connected that has PPS output. Used @Elektrický's how to, to set up GPS and ntpsec. After successfully following the how to, ntp will synchronize and adjust system clock to high(er) accuracy. Once system clock is synchronized, the kernel will also update the RTC (/dev/rtc0) every 11 minutes, giving you a system as follows:
root@sinaspi:~# timedatectl Local time: Sun 2021-08-08 09:24:01 CST Universal time: Sun 2021-08-08 01:24:01 UTC RTC time: Sun 2021-08-08 01:24:02 Time zone: Asia/Taipei (CST, +0800) System clock synchronized: yes NTP service: inactive RTC in local TZ: no root@sinaspi:~# ntpq -p remote refid st t when poll reach delay offset jitter ======================================================================================================= 0.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 1.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 2.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 3.debian.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0019 oPPS(0) .PPS. 0 l 56 64 377 0.0000 -0.0072 0.0035 xSHM(0) .GPS. 0 l 21 64 377 0.0000 -15.3659 1.7862 +SHM(2) .PPS. 0 l 18 64 377 0.0000 -0.0163 0.0094 +europa.ellipse.net 209.180.247.49 2 u 40 64 377 167.9069 -0.9358 0.1437 +ntp1.time.nl .MRS. 1 u 43 64 377 210.9643 1.7869 0.1945 +promethee.boudot.one 94.198.159.10 2 u 21 64 377 220.2528 2.3322 0.0931 root@sinaspi:~#As the DS3231 is now set as rtc0, the udev rules in /lib/udev/rules.d/85-hwclock.rules will make sure to read the DS3231 clock time after a reboot, making sure your system clock has a nice starting offset after being powered off for a while.
Hope this helps anyone out there,
Groetjes,