BarnA

http://ix.io/40CH (Armbian stretch) http://ix.io/40CI (Armbian buster)

I can't help with the original question, but just thought I'd say that I downloaded and compiled from source Freepbx/Asterisk on Armbian running on an SDcard and have never had an issue with choppy audio. My version is FreePBX 13.0.197.31 which is fairly old as its been running for a few years, but it is still under support. Im using an orange pi one with 512Mb memory, The PBX which has light use (3 extensions, one PSTN gateway, one IVR, 3 trunks) but does do other stuff as well.

How do I enable the cgroup memory controller on Armbian? I’m trying to control memory usage on my orange pi one using systemd with a unit file as follows: [Service] Slice=influxGroup.slice MemoryAccounting=true MemoryHigh=100M MemorySwapMax=250M The command systemd-cgls confirms that the influxGroup.slice has been created, yet memory is not controlled in line with the parameters in the unit file. I think the issue may be that cgroup memory controller is not enabled. I haven’t done anything to enable it, but I did notice that dmesg appears to indicate an enable statement in the kernel parameters: [ 0.000000] Kernel command line: root=UUID=5446759b-56c9-4877-ad1f-15e43cbb95cc rootwait rootfstype=ext4 console=tty1 console=ttyS0,115200 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 loglevel=1 ubootpart=f22f559a-01 ubootsource=mmc usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory swapaccount=1 However /proc/cgroups would indicate (I think) that it is not enabled. #subsys_name hierarchy num_cgroups enabled Cpuset 10 1 1 cpu 3 8 1 cpuacct3 8 1 blkio2 8 1 memory5 28 1 devices9 87 1 freezer6 1 1 net_cls8 1 1 perf_event 11 1 1 net_prio 8 1 1 pids4 90 1 rdma7 1 1 So my broadest question is how do I get the system to do what the unit file asks for, which reduces to (I think) a narrower question of: how do I enable the cgroup memory controller on Armbian?

Thanks for the really useful discussion here about zram. I just wanted to add the symptoms I observed with Armbian (Stretch, no GUI) on a 512Mb Orange Pi One which I'm pretty sure (but cannot prove) was due to out of memory conditions, in case this report helps others with the same symptoms. Normal service with Opi1/Armbian for me is to get indefinite uptime (>>6 months). I was experiencing unexpected crashes after 1-2 weeks and as I run a UPS and am using an M2.SATA SSD to USB adapter its unlikely that powering or sdcard issues are a root cause. When observing the crashes roughly 80% seemed to occur 1-2minutes after the apt.daily timer fired (as reported by 'systemctl list-timers'), the remainder seemed to occur at random. As I've got an SSD I decided to add 512Mb swap on top of the zram automatically configured. I set the prioriy of the SSD swap below that of zram and vm.swappiness = 60 (suggestions as to correct setting in these circumstances much appreciated though, I haven't experimented). The system has now been up for approaching 1 month without further outage. swapon -s shows that just under 20Mb of swap on the SSD is in use. zram is used heavily. Filename Type Size Used Priority /swapfile1 file 524284 18308 2 /dev/zram1 partition 252000 198692 5 I think that for users with SSD like me it may be useful to supplement zram with normal swap in the case where they have a device with a small amount of memory such as an Opi1. Comparing Armbian Buster to Stretch memory footprint for my use case, I wonder if this may become more important going forward?

Thanks for the information in this thread, it worked....then after about 2 weeks 24x7 usage, I had a crash on my Orange Pi One (not related to USB functionality I don't think, the system was probably doing a database import at the time). After this, the OTG port didn't seem to work any more in host mode. I tracked it down to not being any internal power on the the port, the USB data lines were OK. Examining the board schematic shows the power for the OTG port comes through 'U11' which in turn is controlled by a line from the H3 chip, but as my board didn't have U11 on the silkscreen I didn't get much further than that. I assumed I'd blown up that part of the board as nothing seemed to fix it and the rest of the system continued to work flawlessly after a reboot. That was not the case however, as a complete reinstall (Armbian stretch) from scratch and hey presto, the internal USB power is restored. In case it happens again, anyone have any idea how to troubleshoot powering of the OTG port in USB host mode when/if it goes wrong?