Sander de Leeuw

Hi,
 
I am running the latest Armbian image with Noble + GNOME for the Rock 5C.
 
I have build it using the `compile.sh` script without altering the kernel, desktop enabled, based on Noble, with GNOME, no applications, no extensions.
Added the kisak PPA repo afterwards and enabled the panthor overlay for hardware acceleration.
Should be close to the `Armbian_24.11.1_Rock-5c_noble_vendor_6.1.75_gnome-kisak_desktop.img` image, I think.
 
With Chromium (few tabs), VSCodium (working on some code) and a couple of terminals open, things were crashing all the time.
 
Here is a reproducable example with Chromium, when navigating to the URL:
https://www.geeksforgeeks.org/ulimit-soft-limits-and-hard-limits-in-linux/
 
sander@rock-5c:~$ chromium  [3743:3743:1213/231308.263364:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.ScreenSaver.GetActive: object_path= /org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.NotSupported: This method is not part of the idle inhibition specification: https://specifications.freedesktop.org/idle-inhibit-spec/latest/ [3743:3795:1213/231308.438912:ERROR:backend_impl.cc(989)] Critical error found -8 [3743:3795:1213/231308.439341:ERROR:entry_impl.cc(955)] Failed to save user data [3743:3795:1213/231308.821432:ERROR:backend_impl.cc(989)] Critical error found -8 [3743:3795:1213/231308.821616:ERROR:entry_impl.cc(955)] Failed to save user data [3743:3743:1213/231308.821621:ERROR:gpu_disk_cache.cc(233)] Failed retry to open blob cache entry: -2 [3845:3861:1213/231317.658891:ERROR:ffmpeg_common.cc(970)] Unsupported pixel format: -1 [4052:4052:1213/231324.240574:ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11) [4057:4057:1213/231324.266795:ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11) [3743:3793:1213/231324.269115:ERROR:zygote_communication_linux.cc(164)] Did not receive ping from zygote child [3743:3793:1213/231324.269180:FATAL:check.cc(361)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry! [3764:3764:1213/231324.269109:ERROR:zygote_linux.cc(639)] Zygote could not fork: process_type renderer numfds 5 child_pid -1 [1213/231324.290657:ERROR:elf_dynamic_array_reader.h(64)] tag not found Trace/breakpoint trap  
I was also not able to use Firefox, at all. Every new tab ended up in a "Snap. Your page crashed" view.
 
The root cause seems to be this:
 
ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11)  
After some web searching, I found that the thread limits are set to a very low value.
(note "max user processes")
 
sander@rock-5c:~$ cat /proc/sys/kernel/threads-max 1685 sander@rock-5c:~$ ulimit -a real-time non-blocking time  (microseconds, -R) unlimited core file size              (blocks, -c) 0 data seg size               (kbytes, -d) unlimited scheduling priority                 (-e) 0 file size                   (blocks, -f) unlimited pending signals                     (-i) 842 max locked memory           (kbytes, -l) 1015884 max memory size             (kbytes, -m) unlimited open files                          (-n) 1024 pipe size                (512 bytes, -p) 8 POSIX message queues         (bytes, -q) 819200 real-time priority                  (-r) 0 stack size                  (kbytes, -s) 8192 cpu time                   (seconds, -t) unlimited max user processes                  (-u) 842 virtual memory              (kbytes, -v) unlimited file locks                          (-x) unlimited  
I searched through the Armbian build repository for code that sets these limits, but I didn't find any.
Seems that these limits are set or calculated by rockchip linux kernel.
 
After applying a few configuration changes, the system becomes much more stable and I have not had any crashes so far.
 
# /etc/rc.local  (updated) echo 16384 > /proc/sys/kernel/threads-max # /etc/security/limits.d/99-nproc.conf   (created) * soft nproc 4096 * hard nproc 4096 # /etc/systemd/system.conf  (updated) #DefaultTasksMax=15% DefaultTasksMax=infinity  
After a reboot, the changes are now applied. And no more crashes! And Firefox now works as well.
 
sander@rock-5c:~$ cat /proc/sys/kernel/threads-max 16384 sander@rock-5c:~$ ulimit -u 4096  
 
Hope this is useful to someone else.
 

It was caching. I cleared the `cache/initrd/` folder and rebuilt Armbian, then it worked fine.
 
@Igor I created a Pull Request go get this change into main.
https://github.com/armbian/build/pull/5901
 

Hi again @NicoD,
 
I tested this with a Full HD monitor and that works just fine!!!
Mistery solved, kind off ...
 
When booting Armbian with my Full HD monitor attached, the Simple DRM / "None-1" output is not present.
The `simpledrm.ko` kernel module is not detected or loaded, so only the /dev/card0 and /dev/card1 devices exists.
Both X.org and Wayland are working as expected.
 
When booting Armbian with my QHD monitor attached, the `simpledrm.ko` kernel module is (automatically) loaded.
(And therefore the None-1 output exists and that is selected as output instead of the HDMI-1-1 output.)
For some reason, the attached monitor causes the Simple DRM feature to be activated in the Linux kernel (or not).
 
I also installed sway / Wayland, while having the QHD monitor attached. Same issue there.
The monitor appears frozen, but when pressing CTRL-ALT-F2, another tty appears and I can kill sway and the first tty becomes responsive again.
Executing the `modprobe -r simpledrm` module fixes the issue and sway can be started normally.
 
@Walter Zambotti blacklisting the simpledrm kernel module (as described in my original post) might be a solution for you as well.
 
Well, issue closed, I guess. It would be nice if Armbian could somehow detect this situation and adapt to it.
But I have no clue where to start, to be honest.

Hi,
 
I just wanted to report how I got Armbian 23.8.1 working on my Khadas VIM3 Pro board.
It was not an out-of-the-box success story, but after a few nights of debugging, I found the cause and fix of the issue.
Hopefully this post will save debugging time of somebody else and maybe this can be fixed in future Armbian releases.
 
The issue is as follows: After flashing the Armbian 23.8.1 image to the VIM3's internal EMMC storage, the SBC boots fine initially.
I walk through the setup-process of users/passwords/network/locale, etc...
After the set-up completes, I reboot the SBC. It starts booting as usual, but when X.org starts, my monitor stops receiving any signal and goes to sleep.
 
I tried these images:
1. Armbian_23.8.1_Khadas-vim3_bookworm_current_6.1.50_cinnamon_desktop.oowow.img.xz
2. Armbian_23.8.1_Khadas-vim3_bookworm_current_6.1.50.oowow.img.xz (installed X.org and XFCE manually afterwards)
3. Pretty sure I had the same problem with Jammy based images, however I saw @NicoD using them without issues on Youtube.
 
Eventually, I found out from the X.org logs that it was displaying to another output device:
[ 37.633] (II) xfree86: Adding drm device (/dev/dri/card1) [ 37.633] (II) Platform probe for /sys/devices/platform/f4e5b000.framebuffer/drm/card1 [ 37.634] (II) xfree86: Adding drm device (/dev/dri/card0) [ 37.634] (II) Platform probe for /sys/devices/platform/soc/ff900000.vpu/drm/card0 [ 37.643] (II) xfree86: Adding drm device (/dev/dri/card2) [ 37.643] (II) Platform probe for /sys/devices/platform/soc/ffe40000.gpu/drm/card2 [ 37.647] (II) no primary bus or device found [ 37.647] falling back to /sys/devices/platform/f4e5b000.framebuffer/drm/card1 ... [ 37.665] (II) modeset(0): using drv /dev/dri/card1 [ 37.676] (II) modeset(G0): using drv /dev/dri/card0 [ 37.676] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 37.676] (**) modeset(0): Option "AccelMethod" "glamor"  
It defaulted to /dev/dri/card1 which is the simpledrm framebuffer output introduced in recent kernel versions.
By updating the X.org config file, I was able to force it selecting /dev/dri/card0 instead, however, according to the modeset man page this should be the default.
Section "Device" Identifier "DRM Graphics Acclerated" ## Use modesetting and glamor Driver "modesetting" Option "AccelMethod" "glamor" ### "glamor" to enable 3D acceleration, "none" to disable. Option "DRI" "2" Option "Dri2Vsync" "true" Option "TripleBuffer" "True" ## End glamor configuration Option "kmsdev" "/dev/dri/card0" EndSection ...  
I still found the performance of the desktop a bit sluggish. Maybe this is because the second Glamor/DRM enabled output still exists.
I was able to completely get rid of the SimpleDRM output using the following commands and reboot:
 
echo "blacklist simpledrm" | sudo tee /etc/modprobe.d/simpledrm.conf sudo update-initramfs -u  
Now, X.org works as expected.
 
I also disabled the XFCE Compositor, which made de desktop perform much better.
Firefox (with GPU enabled) shows some graphics artifacts which are gone after disabling hardware acceleration.
 
Hope that this will help somebody.
 

Motivated by Igor's "no crew" argument, I gave it a shot myself, but without much success yet.
 
I have removed "panic=10" from /boot/boot.cmd and ran mkimage.
This allowed me to enter the busybox shell from u-boot.
 
$ cat /proc/partitions
1 0 4096 ram0
 
So the eMMC modules does not seem to be recognized by the kernel.
When I plugin a SD-card, it's immediately detected and available for use.
 
***
 
It seems to me that eMMC support is not (completely) functional in the kernel.
Checked the kernel configuration files, but in both versions, MMC/eMMC support is enabled:
 
[sander@thinkpad-t480 Work]$ grep EMMC config-4.4.190-rockchip
CONFIG_PWRSEQ_EMMC=y
CONFIG_PHY_ROCKCHIP_EMMC=y
[sander@thinkpad-t480 Work]$ grep EMMC config-5.3.11-rockchip
CONFIG_PWRSEQ_EMMC=y
CONFIG_PHY_ROCKCHIP_EMMC=y
[sander@thinkpad-t480 Work]$ grep MMC= config-4.4.190-rockchip
CONFIG_MMC=y
CONFIG_PWRSEQ_EMMC=y
CONFIG_PHY_ROCKCHIP_EMMC=y
[sander@thinkpad-t480 Work]$ grep MMC= config-5.3.11-rockchip
CONFIG_MMC=y
CONFIG_PWRSEQ_EMMC=y
CONFIG_PHY_ROCKCHIP_EMMC=y
 
I noticed a bunch of new kernel modules (configured as modules) in the u-boot initrd of 5.3.11-rockchip.
Tried to load them, but that didn't change a thing. For reference, here's a list of modules I tried/loaded:
 
/usr/lib/modules/5.3.11-rockchip/kernel/drivers/mmc/
 * core/pwrseq_sd8787.ko,
 * host/dw_mmc-bluefield.ko,
 * host/rtsx_usb_sdmmc.ko,
 * host/sdhci-cadence.ko,
 * host/sdhci-of-dwcmshc.ko
 
***
 
Also compared the init and other scripts under /scripts in the u-boot initramfs between Armbian_5.95 (ok) and Armbian_19.11.3 (not booting).
Did not find a significant difference there.
 
So far no good ;-) Will give it another try later on.