going

You can fix this using fsck. The errors will go away for a while. But with active I/O, they will return. This indicates that the SD card is very close to the end of its life cycle.

I've watched it. It looks like the OS has fallen asleep when the user is not doing anything. What kind of power supply is it now? And what is connected to the board besides the mouse and keyboard?

My guess: It can be a /boot/boot.cmd script. Source for sunxi64 config/bootscripts/boot-sun50i-next.cmd, for sunxi config/bootscripts/boot-sunxi.cmd The kernel command line parameters for the console and display are set in it. By default, in the settings file armbianEnv.txt It must be: console=both You can try to change console=display or any. Please keep me informed if you find an error in the script. P.S. In any case, the connection from the console service to other services seems strange to me. Maybe look in the system event log of the system in the order in which this happens during a crash?

I also noticed something similar when I was testing on bananapim64. I run without HDMI, only UART and Ethernet. The Ethernet starts working immediately, but the UART does not respond to the keyboard from the minicom. After a few minutes, everything magically starts working. These two boards of ours have not been tested for a long time. Perhaps something in u-boot needs to be fixed. Try to view the kernel messages by first adding debug level 10. sudo nano /boot/armbianEnv.tx verbosity=10 # sudo reboot sudo dmesg | grep -i ether Or something like that

I spent three days looking for a problem testing kernel variants on my bananapi-m64 (a64 core). I have no problem. Let's just test the new kernel: Orangepipc2-6.12-crust-mini + linux-image 6.12.4

You can try it. But you'd better wait. I'll do it on my own soon. Unfortunately, I have not found support in the 6.12 kernel for this device. drivers/gpu/drm/panel/Makefile:22:obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o drivers/gpu/drm/panel/Makefile:23:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o drivers/gpu/drm/panel/Makefile:24:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9805) += panel-ilitek-ili9805.o drivers/gpu/drm/panel/Makefile:25:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9806E) += panel-ilitek-ili9806e.o drivers/gpu/drm/panel/Makefile:26:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o drivers/gpu/drm/panel/Makefile:27:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9882T) += panel-ilitek-ili9882t.o .... drivers/gpu/drm/tiny/Kconfig:123: If M is selected the module will be called ili9163. drivers/gpu/drm/tiny/Kconfig:135: If M is selected the module will be called ili9225. drivers/gpu/drm/tiny/Kconfig:148: If M is selected the module will be called ili9341. drivers/gpu/drm/tiny/Kconfig:162: If M is selected the module will be called ili9486. drivers/gpu/drm/tiny/Makefile:11:obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o drivers/gpu/drm/tiny/Makefile:12:obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o drivers/gpu/drm/tiny/Makefile:13:obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o drivers/gpu/drm/tiny/Makefile:14:obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o .... drivers/staging/fbtft/Makefile:13:obj-$(CONFIG_FB_TFT_ILI9163) += fb_ili9163.o drivers/staging/fbtft/Makefile:14:obj-$(CONFIG_FB_TFT_ILI9320) += fb_ili9320.o drivers/staging/fbtft/Makefile:15:obj-$(CONFIG_FB_TFT_ILI9325) += fb_ili9325.o drivers/staging/fbtft/Makefile:16:obj-$(CONFIG_FB_TFT_ILI9340) += fb_ili9340.o drivers/staging/fbtft/Makefile:17:obj-$(CONFIG_FB_TFT_ILI9341) += fb_ili9341.o drivers/staging/fbtft/Makefile:18:obj-$(CONFIG_FB_TFT_ILI9481) += fb_ili9481.o drivers/staging/fbtft/Makefile:19:obj-$(CONFIG_FB_TFT_ILI9486) += fb_ili9486.o .... Maybe if you find a kernel patch to support this device, then I'll add it to the build system and we'll check it out.

Your processor is h616, which means you'll have to turn on everyone for h6, h616

On which platform did you launch the build system?

I will ask for a little more detail about this problem. Perhaps the translation was inaccurate.

Are we discussing this particular NVME here? If so, then publish the diagnostics from smartctl. This will help shed some light on some issues. There are two unpleasant moments here. 1) An old and actively used disk with a large number of failed memory cells. The internal disk controller will redistribute the exhausted memory cells from those used at the time of the write operation. Which greatly reduces the recording speed. Disk manufacturers warn about this. 2) The internal disk controller works well only for a few file systems such as FAT, NTFS, ISO. I have two such devices, a SD card and an SSD drive from Samsung. On EXT4 and BTRFS file systems, the speed of read and write operations is greatly reduced. This is my personal experience and this case is for devices that were manufactured in 2008, 2010.

This is the first step. This means that some patches have a negative effect on older processors. They need to be detected and corrected. I'll assemble another core and call you. Will you be able to continue testing?

Test what you need on core 6.12. If you have any questions or suggestions, just create a new topic and call me.

If you want to participate in testing the intermediate version, then add this branch to your build system: armbian/build> git remote add -t test-6.12 The-going https://github.com/The-going/armbian-build armbian/build> git fetch The-going armbian/build> git checkout -b test-6.12 The-going/test-6.12 # exclude patches armbian/build> egrep '^-' patch/kernel/archive/sunxi-6.12/series.conf # If you need them, just remove the minus sign

Orangepipc2-6.12-crust-mini I have excluded patches for h6 and newer processors. Just for the test.

Tomorrow I will post the download link and we will test the new kernel 6.12 I'm glad your board is in order.