Sander de Leeuw

Good to hear!

It has been resolved by @nyanmisaka in this commit. Thanks a lot!

Issue opened here: https://github.com/armbian/linux-rockchip/issues/307

I did some more testing. On the Rock 5C: The current "Armbian_24.11.1_Rock-5c_noble_edge_6.11.7_gnome-kisak_desktop.img.xz" image has the same problem. The vendor "rock-5c_bookworm_kde_b1.output.img.xz" does not have this problem. On the Orange Pi 5: The current "Armbian_24.11.2_Orangepi5_noble_vendor_6.1.75_gnome-kisak_desktop.img.xz" image has the same problem. (Slightly different values, see console log below) Joshua Riek's Ubuntu image does not have this problem. # Orange Pi 5: Armbian_24.11.2_Orangepi5_noble_vendor_6.1.75_gnome-kisak_desktop.img.xz sander@orangepi5:~$ free -h total used free shared buff/cache available Mem: 7.8Gi 844Mi 6.5Gi 242Mi 779Mi 6.9Gi Swap: 3.9Gi 0B 3.9Gi sander@orangepi5:~$ cat /proc/sys/kernel/threads-max 2378 sander@orangepi5:~$ 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) 1189 max locked memory (kbytes, -l) 1015872 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) 1189 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited This is how it looks on Joshua Riek's Ubuntu image # Orange Pi 5: Joshua Riek's Ubuntu image sander@orangepi5:~$ free -h total used free shared buff/cache available Mem: 7.7Gi 1.7Gi 5.6Gi 100Mi 629Mi 6.1Gi Swap: 1.0Gi 0B 1.0Gi sander@orangepi5:~$ cat /proc/sys/kernel/threads-max 61133 sander@orangepi5:~$ 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) 30566 max locked memory (kbytes, -l) 1014084 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) 30566 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited So it seems to be specific to Armbian and occur on multiple RK3588 boards. I will create an issue at Armbian's linux-rockchip project.

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.

I can confirm this issue. Tested on the following images: * Armbian_24.11.1_Rock-5c_noble_vendor_6.1.75_gnome-kisak_desktop.img.xz * Custom build image (vendor kernel 6.1 + GNOME) When updating the kernel, the aic8800-usb DKMS driver is removed from the old kernel, but not reinstalled on the new kernel. This can easily be fixed afterwards by running the following command: `sudo dpkg-reconfigure aic8800-usb-dkms`, which will recompile and install the kernel module again. I was playing around with Radxa's own Debian based image as well. When compiling a custom kernel with their `bsp` tool and installing it, the same thing happens. Therefore I believe this to be an upstream issue with the aic8800 deb packages. Maybe with the way they register the driver using DKMS...

@Erica I did a fresh install of Armbian 24.5.1 Minimal on my Khadas VIM3 Pro last night, and everything worked smoothly: https://dl.armbian.com/khadas-vim3/archive/Armbian_24.5.1_Khadas-vim3_bookworm_current_6.6.31_minimal.oowow.img.xz Did you actually erase the SPI, as Igor suggested? I was not able to do that with oowow. That gave an error about the SPI not being found. However, with krescue, the SPI was cleared out successfully. Someone else provided a link to krescue for you in the other thread, if you do not have it anymore: https://web.archive.org/web/20240426161033/https://dl.khadas.com/firmware/Krescue/system/versions/VIM3.krescue.sd.220110_266.img.gz Another thing you can try is to connect a different monitor. I think that krescue uses a text mode, while most other images around initialize a graphics mode early in the boot process. Older versions of Armbian did not send HDMI signal to my monitor once it went to graphics mode in the past. But that has been resolved now.

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

@Igor No, specifically for the VIM3, at least for now. Topics that relate to SimpleDRM (here and here) always refer to Panfrost as well. I think that there is a conflict between SimpleDRM and Panfrost. I can imagine that SimpleDRM does work out well for other boards, where an accelerated 3D driver is not available. Thanks for that suggestion. I think that blacklisting the module is preferred over not building/including it in the image, so that advanced users have can still have access to SimpleDRM if they require. I just gave it a try: https://github.com/armbian/build/compare/main...sdeleeuw:armbian-build:fix/khadas-vim3-blacklist-simpledrm The resulting image does contain the blacklist file in /etc/modprobe.d, but the simpledrm is still loaded (early) in the initramfs. Just executing `update-initramfs -u` and rebooting fixes the issue. I noticed that there is some caching mechanism inside the Armbian build scripts. Perhaps the initramfs is taken from cache rather that being re-build with the blacklist file in place?

Perhaps `simpledrm` should be disabled in the Linux kernel? I also noticed another bug report and related forum thread about this kernel module.

I have also tried to completely disable the simplefb: https://github.com/armbian/build/compare/main...sdeleeuw:armbian-build:fix/khadas-vim3-meson64-disable-framebuffer But again, I don't see any difference in the resulting image. I don't feel confident anymore about this having anything to do with U-Boot now.

The patch mentioned above can still be applied to U-Boot 2023.10, but it doesn't seem to make any difference. I forked the Armbian GitHub repo and refreshed the patch using "./compile.sh BOARD=khadas-vim3 BRANCH=current uboot-patch". After which I applied the original patch and fixed some typo's. The result is here: https://github.com/armbian/build/compare/main...sdeleeuw:armbian-build:fix/khadas-vim3-hdmi-fail-safe So I build a desktop image with this patch applied. The first time after finishing the Armbian initial boot script, I got to the desktop in a super low resolution. After rebooting, my monitor went to sleep after launching X.org, just as it does on the current images. Blacklisting the simpledrm kernel module does solve the problem, as mentioned above: echo "blacklist simpledrm" | sudo tee /etc/modprobe.d/simpledrm.conf sudo update-initramfs -u

Maybe this patch from Khadas' version of UBoot is related: https://github.com/khadas/khadas-uboot/blob/master/packages/u-boot-mainline/patches/v2021.10/meson64.patches/0029-video-meson-add-HDMI-fail-save-FullHD-option.patch

A couple of research notes: Armbian uses UBoot 2023.10 for Khadas VIM3 (source) UBoot config sets CONFIG_VIDEO_MESON=y and CONFIG_VIDEO_DT_SIMPLEFB=y (source) UBoot Meson driver probes the HDMI display (and calls `meson_vpu_setup_mode` with the probe result) (source) meson_vpu_setup_mode function configures the `meson_fb` struct (source) meson_vpu_setup_simplefb utilizes the `meson_fb` struct (source) There is also code in the Meson driver that processes the HDMI EDID meta data; not sure if this impacts SIMPLE_FB (source) The SimpleDRM driver in the Linux kernel probably gets activated if SIMPLE_FB is prepared by UBoot The summary of this is that UBoot probes the display early in the boot process and sets up a framebuffer device if the attached HDMI device has certain capabilities. If this framebuffer device is available, then the Linux kernel loads the SimpleDRM driver against it. I am not very familiar with this topic, so perhaps somebody else can review/challenge the notes above. Maybe the power cord was plugged in before the HDMI-cable. UBoot doesn't setup the framebuffer in that case. After installing to EMMC and rebooting, UBoot runs again, but then the HDMI-cable is already plugged in. If the above is true, this might be the case with other board with CONFIG_VIDEO_MESON=y and CONFIG_VIDEO_DT_SIMPLEFB=y

@Walter Zambotti If this is still an issue for you, you might want to look into this: