Dennboy

  • Posts

    38
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    The Netherlands
  • Interests
    high speed sensing, ADC, SPI, DMA, GPIO, hardware interrupts

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Dennboy's Achievements

  1. Hi Igor, Thanks for your support! Bullseye already feels stable enough for my purposes (synchronized voltage/current sensors for green R&D projects). I temporarily fixed my /var/log/journal size issue at (every) boot by clearing /var/log.hdd/journal and copying over /var/log/journal after logrotate has run. Guess this could be automated somehow in the boot scripts. Kind regards, Dennis
  2. Hi Again, The problem seems to be /var/log.hdd/journal which is copied back to /var/log/journal after reboot without cleaning. Directly after a reboot: % du /var/log/journal /var/log.hdd/journal 46560 /var/log/journal/50bea5a2341c40588d32c8103dea6e71 46568 /var/log/journal 46320 /var/log.hdd/journal/50bea5a2341c40588d32c8103dea6e71 46324 /var/log.hdd/journal % sudo diff -r /var/log/journal /var/log.hdd/journal [sudo] password for dennis: Only in /var/log/journal/50bea5a2341c40588d32c8103dea6e71: system@0005cc0672bea9a2-be31a0e4284cf010.journal~ Binary files /var/log/journal/50bea5a2341c40588d32c8103dea6e71/system.journal and /var/log.hdd/journal/50bea5a2341c40588d32c8103dea6e71/system.journal differ Kind regards, Dennis
  3. Hi again, Just updated and rebooted bullseye on nanopi neo3 and now the journals take 50M, before the reboot it was 17.3M .... Fortunately, the log rotation seems to be working again has /bin/bash on first line now, so after 15 minutes /var/log was back to reasonable size. Could not yet reproduce this on opi0, it used 20M of journals after reboot. Welcome to Armbian 21.08.2 Bullseye with Linux 5.10.63-rockchip64 System load: 100% Up time: 0 min Memory usage: 12% of 978M IP: 192.168.0.13 CPU temp: 60�°C Usage of /: 29% of 15G # journalctl --disk-usage Archived and active journals take up 50.6M in the file system. npin3bullseye:~:% df -h /var/log Filesystem Size Used Avail Use% Mounted on /dev/zram1 49M 48M 0 100% /var/log Welcome to Armbian 21.08.2 Bullseye with Linux 5.10.60-sunxi System load: 48% Up time: 0 min Memory usage: 15% of 491M IP: 192.168.0.30 CPU temp: 57�°C Usage of /: 21% of 15G [ General system configuration (beta): armbian-config ] % journalctl --disk-usage Archived and active journals take up 20.0M in the file system. opi0bullseye:~:% df -h /var/log Filesystem Size Used Avail Use% Mounted on /dev/zram1 49M 27M 19M 60% /var/log Kind regards, Dennis
  4. Dear all, I gave the new opi0 bullseye image a try, since It seems to be supported now. It may be worth to have a fresh look at the limits for systemd journald logging, and log rotation. My /var/log was loaded upto 45M some hours after booting, installing packages on the opi0, mainly due to /var/log/journal. I vacuumed it to 10M but after some reboots, package installations and hours it was full again although SystemMaxUse=20M by default. Additionally, the log rotation (fired every 15 minutes from /etc/cron.d/armbian-truncate-logs) does not seem to work properly due to an issue in the script that is started with /bin/sh (see script line 1, instead of a shell that performs the $() command expansion): % sudo /usr/lib/armbian/armbian-truncate-logs [sudo] password for dennis: /usr/lib/armbian/armbian-truncate-logs: 18: /etc/default/armbian-ramlog: Syntax error: "(" unexpected Running it with bash seems to work fine (sudo bash /usr/lib/armbian/armbian-truncate-logs, which also vacuums the journal). After deciphering the journald.conf manpage, I found that both runtime /run/log/journal, as persistent /var/log/journal are running, and /var/log/journal is not really persistent since it is actually mapped zram memory (journald does not care and treats it as disk). % egrep -i "(system|runtime)MaxUse" /etc/systemd/journald.conf SystemMaxUse=20M #RuntimeMaxUse= % sudo journalctl --vacuum-size=10M Vacuuming done, freed 0B of archived journals from /run/log/journal. Deleted empty archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb79ce3b8f57-f277d6397cc77cac.journal~ (380.0K). Deleted empty archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb7769ae3241-2385d20dac4738ae.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@1c1a53e8b25d40f3b676b26240347188-0000000000000001-0005ca73fa192ab2.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@7268c35dcad84410bca267900c47dcf3-00000000000003de-0005cb76b53d43a7.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb77143d39ed-a0190e6a8b8f96ef.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb77ab234dfb-97d2013e1117189a.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb77ab294eee-86b91930cb2eb4a9.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-0000000000000001-0005cb77ab1c0c05.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-00000000000002be-0005cb77ab27dc7d.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@bd369698bf69432a8bc7ab495a90d103-00000000000002cd-0005cb77abdedbd0.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-0000000000000960-0005cb7805815938.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb787689a85a-c5fb08a0411e45bd.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb787781d2a7-d60e1ce6a19e246b.journal~ (2.5M). Vacuuming done, freed 30.4M of archived journals from /var/log/journal/078479a1b0a4459f80590dd571c3d6de. Vacuuming done, freed 0B of archived journals from /var/log/journal. Vacuuming done, freed 0B of archived journals from /run/log/journal/078479a1b0a4459f80590dd571c3d6de. % ls -lsa /run/log/journal/078479a1b0a4459f80590dd571c3d6de total 5056 0 drwxr-s---+ 2 root systemd-journal 200 Sep 8 11:58 . 0 drwxr-sr-x+ 3 root systemd-journal 60 Sep 8 11:01 .. 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:51 system@6b593560fcd344f2910e96f6d1a94416-000000000000719c-0005cb7a7b871b5f.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:52 system@6b593560fcd344f2910e96f6d1a94416-0000000000007493-0005cb7a81dbae26.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:54 system@6b593560fcd344f2910e96f6d1a94416-0000000000007783-0005cb7a85740dde.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:55 system@6b593560fcd344f2910e96f6d1a94416-0000000000007a7a-0005cb7a8c94d731.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:56 system@6b593560fcd344f2910e96f6d1a94416-0000000000007d6f-0005cb7a8d656445.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:57 system@6b593560fcd344f2910e96f6d1a94416-0000000000008062-0005cb7a93bd9e11.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:58 system@6b593560fcd344f2910e96f6d1a94416-0000000000008352-0005cb7a9754eac1.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 12:32 system.journal % ls -lsa /var/log/journal/078479a1b0a4459f80590dd571c3d6de total 12740 4 drwxr-sr-x 2 root systemd-journal 4096 Sep 8 11:58 . 4 drwxr-sr-x 3 root systemd-journal 4096 Aug 26 10:39 .. 2564 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:37 system@0005cb78a256a261-d8ca0603791c37d6.journal~ 2564 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:26 system@1e380884930f4d539d6a0d93d2b03d39-0000000000000001-0005cb7876859703.journal 2476 -rw-r-----+ 1 root systemd-journal 2527232 Sep 8 11:01 system.journal 2564 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:26 user-1000@933777cd01ac4494a761849c2e955801-00000000000002ee-0005cb787781bf5f.journal 2564 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:36 user-1000.journal % ls -lsa /var/log.hdd/journal/078479a1b0a4459f80590dd571c3d6de total 43904 4 drwxr-sr-x 2 root systemd-journal 4096 Sep 8 09:56 . 4 drwxr-sr-x 3 root systemd-journal 4096 Aug 26 10:39 .. 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 07:46 system@0005cb77143d39ed-a0190e6a8b8f96ef.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:28 system@0005cb77ab234dfb-97d2013e1117189a.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:25 system@0005cb787689a85a-c5fb08a0411e45bd.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:37 system@0005cb78a256a261-d8ca0603791c37d6.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:28 system@0368477b592e43fdbf9ffcfb6934d264-0000000000000001-0005cb77ab1c0c05.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:53 system@0368477b592e43fdbf9ffcfb6934d264-00000000000002be-0005cb77ab27dc7d.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:18 system@0368477b592e43fdbf9ffcfb6934d264-0000000000000960-0005cb7805815938.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 07:46 system@1c1a53e8b25d40f3b676b26240347188-0000000000000001-0005ca73fa192ab2.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:26 system@1e380884930f4d539d6a0d93d2b03d39-0000000000000001-0005cb7876859703.journal 376 -rw-r----- 1 root systemd-journal 385024 Sep 8 09:37 system.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:10 user-1000@0005cb7769ae3241-2385d20dac4738ae.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:28 user-1000@0005cb77ab294eee-86b91930cb2eb4a9.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:25 user-1000@0005cb787781d2a7-d60e1ce6a19e246b.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 07:46 user-1000@7268c35dcad84410bca267900c47dcf3-00000000000003de-0005cb76b53d43a7.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:26 user-1000@933777cd01ac4494a761849c2e955801-00000000000002ee-0005cb787781bf5f.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:43 user-1000@bd369698bf69432a8bc7ab495a90d103-00000000000002cd-0005cb77abdedbd0.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:18 user-1000@bd369698bf69432a8bc7ab495a90d103-0000000000000a2b-0005cb7811371fa6.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:36 user-1000.journal % sudo journalctl --disk-usage Archived and active journals take up 17.3M in the file system. Kind regards, Dennis
  5. Hi tparys, Yes, that is exactly my point. I had NetworkManager stopped and disabled, and during an apt update && apt upgrade, the linked /etc/resolv.conf was turned into a NetworkManager managed textfile, rendering 2 nanopi neo3's unreachable after reboot. I had to use debug-uart to repair the softlink. Kind regards, Dennis
  6. Hi Ianefu, Thanks for the pointer. It appears that rc-manager in `/etc/NetworkManager/NetworkManager.conf` is currently set to file, it probably needs to be set to something else to respect the softlink in /etc/resolv.conf. From the networkmanager.conf manpage : rc-manager Set the resolv.conf management mode. The default value depends on NetworkManager build options, and this version of NetworkManager was build with a default of "resolvconf". Regardless of this setting, NetworkManager will always write resolv.conf to its runtime state directory /run/NetworkManager/resolv.conf. From the description of the different options, it looks like it can be set to `symlink` or `resolvconf` to improve its behaviour, even `file` should not replace existing links... unless there is something in the network-manager debian package that does this... Kind regards, Dennis
  7. Dear all, I'm running Armbian 21.02.1 on the nanopi neo3 (diagnostic: http://ix.io/3y5D) using /etc/network/interfaces and have network-manager disabled (`sudo systemctl disable network-manager.service` ). I occasionally use network-manager for a usb-wifi stick. When I recently upgraded the packages it triggered a network-manager update. After a reboot the nanopi was not able to start is networking, it only got a 169.254.6.233 address. After analyzing the situation the network-manager update apparently removed the softlink `/etc/resolv.conf -> /run/resolvconf/resolv.conf` and replaced it with a text file. Can network-manager be changed somehow, so that it keeps using the softlink instead of its own interpretation of /etc/resolv.conf? Kind regards, Dennis
  8. Hi tparys, Thanks for your reply pointing to the upstream debian repo's, and sorry for posting an upstream bug here. I just looked up the dtc package in debian, and they appear to have it fixed in their newest update 1.4.7-4 from 27 january 2021 (see DTC debian changelog), it is now available in Armbian too, and seems to be working. Apparently it took some time to travel to the repo/mirrors, it wasn't yet available when I posted here. Kind regards, Dennis
  9. Dear all, My system logs: http://ix.io/2Pgj I consistency get a crash with dtc on both orangepi, nanopi neo+2, nanopi neo3 when I try to see the current devicetree via the filesystem, e.g.: $ dtc -I fs /sys/firmware/devicetree/base/ <stdout>: Warning (unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit name <stdout>: Warning (clocks_property): /soc/spdif@1c21000:clocks: cell 0 is not a phandle reference <stdout>: Warning (clocks_property): /soc/spdif@1c21000:clocks: cell 2 is not a phandle reference .... /dts-v1/; / { [1] 16929 segmentation fault dtc -I fs /sys/firmware/devicetree/base/ My current work-around is to install the kernel headers and start dtc from there, but headers takes quite long to install: $ sudo apt install linux-headers-current-sunxi $ /lib/modules/5.10.12-sunxi/build/scripts/dtc/dtc -I fs /sys/firmware/devicetree/base/ /dts-v1/; / { compatible = "xunlong,orangepi-zero\0allwinner,sun8i-h2-plus"; serial-number = "02c000421661c2d2"; model = "Xunlong Orange Pi Zero"; interrupt-parent = <0x01>; #address-cells = <0x01>; #size-cells = <0x01>; ... }; I could also try to install an upstream version of dtc, but it would be great if the supplied dtc doesn't crash. Kind regards, Dennis
  10. I tried to override the interrupt affinity using a devicetree overlay, but also this seems to be ignored on sunxi. Anybody knows why? Is the affinity simply not implemented by sunxi? Below is the overlay to change the interrupt affinity. Devicetree before modification shows interrupt-affinity=<&cpu0>,<&cpu1>,<&cpu2>,<&cpu3>; /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3","allwinner,sun50i-h5","friendlyarm,nanopi-neo2"; fragment@1 { target-path = "/pmu"; __overlay__ { interrupt-affinity = <&cpu0>; }; }; }; After boot only using cpu0 is reflected in the runtime devicetree on opi0: $ /lib/modules/5.10.12-sunxi/build/scripts/dtc/dtc -I fs /sys/firmware/devicetree/base|less pmu { compatible = "arm,cortex-a7-pmu"; interrupts = <0x00 0x78 0x04 0x00 0x79 0x04 0x00 0x7a 0x04 0x00 0x7b 0x04>; interrupt-affinity = <0x30>; }; cpus { cpu@0 { compatible = "arm,cortex-a7"; phandle = <0x30>; ... }; ... }; Here is the /proc/interrupt table again: HomeCT2:~:% grep ads /proc/interrupts 66: 1043 0 0 0 sunxi_pio_edge 1 Edge ads131a04 162: 68 255 1040571 1 ads131a04-dev0 Edge ads131a04_consumer0 So the affinity has been changed but seems to be ignored. p.s. Sorry for talking to myself;-)
  11. Hi, I experimented some further and set /proc/irq/default_smp_affinity to 1 for the first core, and it looks good on paper, but in practice most interrupts still go to the second core. echo 1 > /proc/irq/default_smp_affinity # dynamically load ADC kernel driver HomeCT2:~:% cat /proc/irq/162/smp_affinity 1 HomeCT2:~:% cat /proc/irq/162/effective_affinity 0 HomeCT2:~:% grep ads /proc/interrupts 66: 1397 0 0 0 sunxi_pio_edge 1 Edge ads131a04 162: 557 1394461 27 0 ads131a04-dev0 Edge ads131a04_consumer0
  12. Dear all, I'm frequently losing GPIO interrupts on various boards, which seem to be caused by bursty processes. When I shield the cores that have those interrupts according to /proc/interrupts with e..g. "cset shield --cpu=0,1" , way less interrupts are lost (e.g. for 4kHz interrupts one in hours instead of once per minute). Most of these (ADC) interrupts are handled by my own kernel module, but couldn't find how to restrict them to e.g. CPU0, and they are not movable using /proc/irq/*/smp_affinity. HomeCT1:~:% grep ads /proc/interrupts 66: 166559 0 0 0 sunxi_pio_edge 1 Edge ads131a04 162: 273 152692648 13858531 17 ads131a04-dev0 Edge ads131a04_consumer0 HomeCT1:~:% cat /proc/irq/162/smp_affinity f I noticed that on allwinner (opi0, nanopi neo+2), the ADC interrupts are on different CPU cores. On the neo3 they always seem to go to the 1st CPU core. Is there any way to force the interrupts to 1st core on the allwinner as well (e.g. in kernel module c-code or via devicetree)? This would make it easier to shield the first core and reduce the lost interrupts. Or is there another way to give more priority to the GPIO interrupts? Making the kernel thread realtime with chrt is apparently not enough. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2407 root rt 0 0 0 0 S 4.6 0.0 116:06.38 [irq/162-ads131a] Kind regards, Dennis
  13. Hi Igor, Thanks very much for fixing this, building out-of-tree modules now works great in Armbian 20.02.1, on 5.10.12-sunxi (opi0) and 5.10.12-rockchip64 (neo3)! Kind regards, Dennis
  14. Yes Igor, for sure we are thankful for all your help here! I'm glad only toys got broken Hope you can teach your kid to repair toys some day I tried with the nanopineo2 (Armbian 20.11.6 Buster), the modules build fine but the installation reports SSL errors during installation of the module, that didn't appear on the orangepizero. The module(s) can be loaded and run after depmod -a. INSTALL pps_timer.ko At main.c:160: - SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:69 - SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:76 sign-file: certs/signing_key.pem: No such file or directory DEPMOD 5.10.4-sunxi64 Kind regards, Dennis
  15. Hi @hjoe, Your fix seems to work beautifully on the orangepizero, thanks! My kernel module loads and runs beautifully. Tomorrow I'll try on nanopi neo2+ and neo3. @Igor Good luck with the family in these strange times. I hope things change for the best in the next months as more people get vacinated. Kind regards, Dennis