Jump to content

Recommended Posts

Posted

Hi, I have a few Orange Pi PC Plus using Armbian bulldog and have two questions / issues. its my 1st post and not sure where best to ask

 

1. I have a python program that starts on a service, this can take around 25 seconds to start, I would like sub 20, less than 15 would be fantastic but not sure what service's to remove. reading a few posts here, I have an svg log but unable to see how i can attach?. It boots from eMMC. The program uses USB, I2C and internal UART and wi-fi

2. on a few OPi the wifi will not work. if I type in "sudo iwlist wlan0 scan" it returns " no scan results" if I reboot, it finds this. I have a lot of OPi and some have a wifi issue so I would like to either see if I can reset/interface with the 818fs chip or see why it does not work. I have looked at dmseg and "lsmod | grep 8189sf" and nothing jumps out.

 

Thanks in advance

 

 

Posted
5 hours ago, digby26 said:

Armbian bulldog

Sorry, just had to smirk at this 😂

 

Edit: but sorry, I can't answer your questions. Maybe somebody more knowledgeable will...

Posted

I noticed soon as I posted but I was unable to edit it to Bullseye, good way to start a post 😂

 

some more info. I type "systemd-analyze blame" and I get the below result, is there some easy wins to get the boot time down?

 

15.021s bootsplash-hide-when-booted.service
 4.823s logrotate.service
 4.301s armbian-hardware-optimize.service
 3.223s armbian-ramlog.service
 2.129s networkd-dispatcher.service
 1.907s armbian-zram-config.service
 1.827s systemd-random-seed.service
 1.392s dev-mmcblk2p1.device
 1.248s man-db.service
  960ms e2scrub_reap.service
  947ms loadcpufreq.service
  877ms systemd-logind.service
  783ms ssh.service
  681ms systemd-udev-trigger.service
  643ms NetworkManager.service
  600ms chrony.service
  585ms user@1000.service
  573ms hostapd.service
  524ms cpufrequtils.service
  503ms keyboard-setup.service
  453ms smartmontools.service
  405ms apt-daily-upgrade.service
  382ms apt-daily.service
  312ms alsa-restore.service
  277ms systemd-journald.service
  270ms sysstat-summary.service
  256ms rsyslog.service
  231ms run-rpc_pipefs.mount
  198ms rc-local.service
  185ms sys-kernel-tracing.mount
  184ms modprobe@fuse.service
  182ms dev-mqueue.mount
  181ms modprobe@drm.service
  181ms fake-hwclock.service
  181ms modprobe@configfs.service
  176ms armbian-led-state.service
  174ms systemd-udevd.service
  174ms kmod-static-nodes.service
  173ms sys-kernel-debug.mount
  160ms networking.service
  154ms sysstat.service
  150ms systemd-modules-load.service
  146ms wpa_supplicant.service
  144ms systemd-remount-fs.service
  140ms systemd-tmpfiles-clean.service
  126ms sysfsutils.service
  113ms systemd-user-sessions.service
  104ms systemd-sysctl.service
   93ms systemd-update-utmp-runlevel.service
   73ms systemd-tmpfiles-setup-dev.service
   72ms systemd-update-utmp.service
   72ms systemd-sysusers.service
   72ms sys-fs-fuse-connections.mount
   69ms systemd-tmpfiles-setup.service
   66ms sys-kernel-config.mount
   66ms polkit.service
   61ms nfs-config.service
   57ms console-setup.service
   56ms rpcbind.service
   50ms sysstat-collect.service
   45ms systemd-rfkill.service
   44ms user-runtime-dir@1000.service
   42ms systemd-journal-flush.service
   25ms tmp.mount
   25ms armbian-hardware-monitor.service
   15ms ifupdown-pre.service

 

For the Wi-Fi issue, I have done more digging. When the pi does not connect to wifi, if I "dmesg | grep mmc" I get the below response

 

[    3.436390] mmc1: new high speed SDIO card at address 0001
[    4.067827] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[    5.645923] EXT4-fs (mmcblk2p1): re-mounted. Opts: commit=600,errors=remount-ro. Quota mode: none.
[   20.916301] sunxi-mmc 1c10000.mmc: data error, sending stop command
[   20.916334] sunxi-mmc 1c10000.mmc: send stop command failed
 

where on a pi where wifi is good, I do not get the bottom 2 lines, is this a good way to log the issue or is it just a coincidence?

 

If I "lsmod | grep 8189" I get the below when it can not scan for wifi and when it can

 

8189fs                901120  0
cfg80211              516096  1 8189fs

 

If there is any commands you would like me to try, please let me know

Posted
55 minutes ago, digby26 said:

is there some easy wins to get the boot time down?

 

Setting fixed IP address might get you some savings.

Posted

Thanks Igor, we have from 50 to 100 on each network so they can only be on DHCP, they do get moved around so setting to static will be impossible to manage

Posted
1 hour ago, digby26 said:

Thanks Igor, we have from 50 to 100 on each network so they can only be on DHCP, they do get moved around so setting to static will be impossible to manage

 

Elsewhere you won't get much.

 

Boot loader waits 1 or 2 seconds for input. This you can disable. Other services all together are close to nothing ... you can get down by shrinking kernel to support your use case only and use busy-box https://busybox.net/ and completely shrink OS functions, but its some work - if you can afford according to your use case. DHCP will sadly remain bottleneck, its also dependant on DHCP server ... this doesn't look like a hobby project?

Posted

is there a way to have my service start sooner? The service is currently set to

 

"After=network.target"

 

but I have also tried below and that doesn't seem to make it start faster

 

After=system.slice

 

Posted
Just now, atone said:

Which kind of SD card

its on eMMC

 

this is the critical chain from my device

 

graphical.target @17.998s
└─multi-user.target @17.997s
  └─sysfsutils.service @14.776s +1.603s
    └─cpufrequtils.service @12.423s +2.227s
      └─loadcpufreq.service @11.393s +937ms
        └─basic.target @11.297s
          └─armbian-hardware-optimize.service @7.022s +4.270s
            └─sysinit.target @7.008s
              └─systemd-update-utmp.service @6.950s +56ms
                └─systemd-tmpfiles-setup.service @6.854s +71ms
                  └─systemd-journal-flush.service @6.803s +45ms
                    └─systemd-journald.service @6.520s +277ms
                      └─armbian-ramlog.service @3.314s +3.196s
                        └─var-log.mount @3.412s
                          └─dev-zram1.device @2.789s

 

Posted
23 minutes ago, atone said:

system.slice seems to be one of the last elements of the critical chain

My bad, the tree is upside down. 

 

5 hours ago, digby26 said:
"After=network.target"

Don't know how it works, but "network.target" is not listed.

 

Edit: neither is system.slice

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines