halfa

On my side I've been running 5.16.11 from linux-image-edge-rockchip64_22.02.1 and it has been rather stable, with occasional (once every 2 months?) lockups. I'm running on a jammy base. Just saw that the 6.6.2 kernel is available in the test repos, anyone gave it a try? armbian-bsp-cli-helios64/jammy 23.11.1 arm64 [upgradable from: 22.02.1] armbian-firmware/jammy,jammy,jammy 23.11.1 all [upgradable from: 22.05.1] linux-dtb-edge-rockchip64/jammy 23.11.1 arm64 [upgradable from: 22.02.1] linux-headers-edge-rockchip64/jammy 23.11.1 arm64 [upgradable from: 22.02.1] linux-image-edge-rockchip64/jammy 23.11.1 arm64 [upgradable from: 22.02.1]

I confirm that I have the same issue, on kernel 5.18.0 with the default armbian build the fans are not detected by the hwmon module: # uname Linux helios64 5.18.0-rockchip64 #22.05.1 SMP PREEMPT Sat May 28 08:41:43 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux # dmesg | grep hwmon [ 8.480887] hwmon hwmon2: temp1_input not attached to any thermal zone [ 8.480906] lm75 2-004c: hwmon2: sensor 'lm75' # # ll /sys/class/hwmon total 0 lrwxrwxrwx 1 root root 0 Jun 5 18:47 hwmon0 -> ../../devices/virtual/thermal/thermal_zone0/hwmon0 lrwxrwxrwx 1 root root 0 Jun 5 18:47 hwmon1 -> ../../devices/virtual/thermal/thermal_zone1/hwmon1 lrwxrwxrwx 1 root root 0 Jun 5 18:47 hwmon2 -> ../../devices/platform/ff120000.i2c/i2c-2/2-004c/hwmon/hwmon2 lrwxrwxrwx 1 root root 0 Jun 5 18:47 hwmon3 -> ../../devices/platform/ff3d0000.i2c/i2c-4/4-0022/power_supply/tcpm-source-psy-4-0022/hwmon3 lrwxrwxrwx 1 root root 0 Jun 5 18:47 hwmon4 -> ../../devices/platform/gpio-charger/power_supply/gpio-charger/hwmon4 On kernel 5.17 it was working fine. Now digging into what could have caused this...

@m11k can you run sudo apt info armbian-bsp-cli-helios64 and post the output? For those affected by the issue, the file has been patched to handle both the legacy and 5.10 kernel logic https://github.com/armbian/build/pull/3092

@ebin-dev I have 0 ideas how you ended up in that situation but on my side the version 21.05.8 is installed and it indeed contain the legacy udev rule (and you can confirm for yourself by looking at the package in the mirror at http://mirrors.dotsrc.org/armbian-apt/pool/focal-utils/a/armbian-bsp-cli-helios64/) root@helios64 $ dpkg -s armbian-bsp-cli-helios64 Package: armbian-bsp-cli-helios64 Status: install ok installed Priority: optional Section: kernel Installed-Size: 1 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Architecture: arm64 Version: 21.05.8 Replaces: zram-config, base-files, armbian-tools-focal, linux-focal-root-legacy-helios64 (<< 21.05.8~), linux-focal-root-current-helios64 (<< 21.05.8~), linux-focal-root-edge-helios64 (<< 21.05.8~) Provides: linux-focal-root-legacy-helios64, linux-focal-root-current-helios64, linux-focal-root-edge-helios64 Depends: bash, linux-base, u-boot-tools, initramfs-tools, lsb-release, fping Recommends: bsdutils, parted, util-linux, toilet Suggests: armbian-config Breaks: linux-focal-root-legacy-helios64 (<< 21.05.8~), linux-focal-root-current-helios64 (<< 21.05.8~), linux-focal-root-edge-helios64 (<< 21.05.8~) Description: Tweaks for Armbian focal on helios64 root@helios64 $ dpkg -L armbian-bsp-cli-helios64 | grep legacy /etc/udev/rules.d/90-helios64-hwmon-legacy.rules

I don't think keeping the old file around would be an issue anyway, if somebody can hand me the resulting deb package I can test it on my helios64. Else I would need to find a way to build the whole image (which may not be a bad thing? )

For anybody here looking for a solution, see the other thread (where you will find a manual fix) @ebin-dev you need to look at what file you have in /etc/udev/rules.d/, as long as you didn't reboot you'll not have the issue. Hello back @Heisath! I updated to armbian 21.05.8 and indeed I'm back on the old udev rule. If we still don't now why sometime the build mess up with the legacy settings, but if it's the ONLY thing that is related to the legacy switch, we might as well either merge both files into one, accommodating both CPU device tree thermal tree path. @Igor what do you think? I think I can make a PR for that.

The 21.05.6 release fixed the regression in the package build process (couldn't find a related commit, maybe during the build targets reworks?), removing the "legacy" udev rule and adding the correct one. root@helios64:~ # apt info armbian-bsp-cli-helios64 Package: armbian-bsp-cli-helios64 Version: 21.05.6 Given that this is fixed, I don't know if there is a need to patch the upstream Heisath. I'm willing to test you're version of the merged udev rule but I don't have a legacy env. to properly test the other one.

One solution to this would be to merge both the old and the new rule into the same file (like I ended up doing above), but I would highly suggest that we package a new version of the bsp with the correct rule in a 21.05.3 version to avoid issues with non-spinning fans. Let me know if I can assist by any means.

It is STILL an issue in the 21.05.2 package in the repo https://armbian.hosthatch.com/apt/pool/focal-utils/a/armbian-bsp-cli-helios64/armbian-bsp-cli-helios64_21.05.2_arm64.deb so anybody upgrading to 21.05.2 will get the old udev rule and the fancontrol issue

For anybody passing by, the issue is due to the fact that for some reason the armbian-bsp-cli-helios64 package for 21.05.2 (EDIT: clarify, 21.05.1 is fine as seen below) was build with the old udev rule (for 4.4 kernels): $ ls armbian-bsp-cli-helios64_21.05.1_arm64.deb\data.tar\.\etc\udev\rules.d\ 10-wifi-disable-powermanagement.rules 50-mali.rules 50-rk3399-vpu.rules 50-usb-realtek-net.rules 70-keep-usb-lan-as-eth1.rules 90-helios64-hwmon.rules 90-helios64-ups.rules $ ls armbian-bsp-cli-helios64_21.05.2_arm64.deb\data.tar\.\etc\udev\rules.d\ 10-wifi-disable-powermanagement.rules 50-mali.rules 50-rk3399-vpu.rules 50-usb-realtek-net.rules 70-keep-usb-lan-as-eth1.rules 90-helios64-hwmon-legacy.rules 90-helios64-ups.rules The content of the 90-helios64-hwmon.rules is indeed correct and match the 5.10.x kernel device tree: https://github.com/armbian/build/blob/master/packages/bsp/helios64/90-helios64-hwmon.rules I tried reversing the build system to find why the old file was used instead of the other, but the best I could find is # in config/sources/families/include/rockchip64_common.inc 395 ### Fancontrol tweaks 396 # copy hwmon rules to fix device mapping 397 if [[ $BRANCH == legacy ]]; then 398 install -m 644 $SRC/packages/bsp/helios64/90-helios64-hwmon-legacy.rules $destination/etc/udev/rules.d/ 399 else 400 install -m 644 $SRC/packages/bsp/helios64/90-helios64-hwmon.rules $destination/etc/udev/rules.d/ 401 fi

Posting here following what was recommended on twitter. After updating my helios64 earlier this week and rebooting to get the new kernel, I realized it was suspiciously silent. A quick check to sensor temps readings and physical check made me realize the fan were not spinning. After a quick read on the wiki, I checked fancontrol which was indeed failing: root@helios64:~ # systemctl status fancontrol.service ● fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/fancontrol.service.d └─pid.conf Active: failed (Result: exit-code) since Fri 2021-05-28 00:08:13 CEST; 1min 42s ago Docs: man:fancontrol(8) man:pwmconfig(8) Process: 2495 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=0/SUCCESS) Process: 2876 ExecStart=/usr/sbin/fancontrol (code=exited, status=1/FAILURE) Main PID: 2876 (code=exited, status=1/FAILURE) May 28 00:08:13 helios64 fancontrol[2876]: MINPWM=0 May 28 00:08:13 helios64 fancontrol[2876]: MAXPWM=255 May 28 00:08:13 helios64 fancontrol[2876]: AVERAGE=1 May 28 00:08:13 helios64 fancontrol[2876]: Error: file /dev/thermal-cpu/temp1_input doesn't exist May 28 00:08:13 helios64 fancontrol[2876]: Error: file /dev/thermal-cpu/temp1_input doesn't exist May 28 00:08:13 helios64 fancontrol[2876]: At least one referenced file is missing. Either some required kernel May 28 00:08:13 helios64 fancontrol[2876]: modules haven't been loaded, or your configuration file is outdated. May 28 00:08:13 helios64 fancontrol[2876]: In the latter case, you should run pwmconfig again. May 28 00:08:13 helios64 systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE May 28 00:08:13 helios64 systemd[1]: fancontrol.service: Failed with result 'exit-code'. Basically fancontrol expect a device in /dev to read the sensors value from, and that device seems to be missing. After a bit of poking around and learning about udev, I managed to manually solve the issue by recreating the device symlink manually: /usr/bin/mkdir /dev/thermal-cpu/ ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /dev/thermal-cpu/temp1_input systemctl restart fancontrol.service systemctl status fancontrol.service Now digging more this issue happen because udev is not creating the symlink like it should for some reason. After reading the rule in /etc/udev/rules.d/90-helios64-hwmon-legacy.rules and a bit of udev documentation, I managed to find how to test it: root@helios64:~ # udevadm test /sys/devices/virtual/thermal/thermal_zone0 [...] Reading rules file: /etc/udev/rules.d/90-helios64-hwmon-legacy.rules Reading rules file: /etc/udev/rules.d/90-helios64-ups.rules [...] DEVPATH=/devices/virtual/thermal/thermal_zone0 ACTION=add SUBSYSTEM=thermal IS_HELIOS64_HWMON=1 HWMON_PATH=/sys/devices/virtual/thermal/thermal_zone0 USEC_INITIALIZED=7544717 run: '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0 ' <-- something is wrong here, there is no target Unload module index Unloaded link configuration context. After spending a bit more time reading the udev rule, I realized that the second argument was empty because we don't match the ATTR{type}=="soc-thermal" condition. We can look up the types like this: root@helios64:~ # find /sys/ -name type | grep thermal /sys/devices/virtual/thermal/cooling_device1/type /sys/devices/virtual/thermal/thermal_zone0/type /sys/devices/virtual/thermal/cooling_device4/type /sys/devices/virtual/thermal/cooling_device2/type /sys/devices/virtual/thermal/thermal_zone1/type /sys/devices/virtual/thermal/cooling_device0/type /sys/devices/virtual/thermal/cooling_device3/type /sys/firmware/devicetree/base/thermal-zones/gpu/trips/gpu_alert0/type /sys/firmware/devicetree/base/thermal-zones/gpu/trips/gpu_crit/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_crit/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_alert0/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_alert1/type root@helios64:~ # cat /sys/devices/virtual/thermal/thermal_zone0/type cpu <-- we were expecting soc-thermal! and after rewriting the line with the new type, udev is happy again # Edit in /etc/udev/rules.d/90-helios64-hwmon-legacy.rules and add the following line after the original one ATTR{type}=="cpu", ENV{HWMON_PATH}="/sys%p/temp", ENV{HELIOS64_SYMLINK}="/dev/thermal-cpu/temp1_input", RUN+="/usr/bin/mkdir /dev/thermal-cpu/" root@helios64:~ # udevadm control --reload root@helios64:~ # udevadm test /sys/devices/virtual/thermal/thermal_zone0 [...] DEVPATH=/devices/virtual/thermal/thermal_zone0 ACTION=add SUBSYSTEM=thermal IS_HELIOS64_HWMON=1 HWMON_PATH=/sys/devices/virtual/thermal/thermal_zone0/temp HELIOS64_SYMLINK=/dev/thermal-cpu/temp1_input USEC_INITIALIZED=7544717 run: '/usr/bin/mkdir /dev/thermal-cpu/' run: '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0/temp /dev/thermal-cpu/temp1_input' Unload module index Unloaded link configuration context. Apparently for some reason the device-tree changed upstream and the thermal type changed from soc-thermal to cpu?