Disk spin-down broken on proxmox kernel 6.17 with UGREEN DXP4800 Plus — ASM1164 regression

Hello, long-time lurker - been using OMV since right before the upgrade to 7. I've done everything to try to identify what could potentially be waking the disks, until I realized that the behavior changed after upgrading from proxmox-kernel 6.14 to 6.17 (all using the kernel plugin - I try to use the plugins and OMV features as much as possible. I don't want a hacked together system)

Hardware: UGREEN DXP4800 Plus, OMV 7.x, Proxmox kernel packages, 4x Seagate ST2000DM008 in ZFS RAIDZ1

Issue: After upgrading to kernel 6.17.13-1-pve, spinning disks no longer stay in standby — they spin back up within minutes regardless of spindown settings in OMV.

Root cause: The ASMedia ASM1164 SATA controller (built into the DXP4800 Plus) is being forced to [tt]max_performance[/tt] link power management by kernel 6.17, overriding firmware settings. On kernel 6.14 the policy correctly stays at [tt]keep_firmware_settings[/tt] and spin-down works normally.

Workaround: Either roll back to kernel 6.14, or disable spindown time in OMV under Storage → Disk to avoid constant spin-up/spin-down cycling while on 6.17.

I posted to the proxmox forums about this as well
Full technical details and kernel bug report here: https://forum.proxmox.com/thre…ng-disk-spin-down.181474/

For now I'm at 6.17 with spin down completely disabled (better to keep the disks spinning than to keep cycling them). I considered staying on 6.14 but then when I wanted to do more advanced zfs things the tooling was all broken because of the version mismatch between what was on the system and the userspace tooling.

By the way - proxmox kernel upgrades uninstall dkms - thats a pain in the ass, but workable.

I prefer to spin them down as my nas sits relatively idle during normal usage. It's more of an archive than a constantly accessed nas. The things I run on it that are constantly working are some containers doing media downloading and streaming, but I am using nvme as disk for that and back up only what I really care about periodically.

Just posting here to share the experience and if someone else runs into this. I know not everyone runs an aggressive spindown strategy.

Quote from ryecoaaron

You must have the zfs plugin installed then. I can stop the plugin from removing dkms and just remove zfs-dkms.

yes! i certainly do. that would be awesome! this way my custom modules will rebuild automatically everytime there is a kernel update.

My main reason is that the ugreen nas needs a module to interface with the LED controller. It's more of a vanity/nice to have thing, but one of those that triggers my ocd if not working.

GitHub - miskcoo/ugreen_leds_controller: An LED Controller for UGREEN's DX/DXP NAS Series

An LED Controller for UGREEN's DX/DXP NAS Series. Contribute to miskcoo/ugreen_leds_controller development by creating an account on GitHub.

github.com

I'm in no rush for the zfs update. I can rebuild the module if needed until then

Thanks for all the hard work! OMV is an awesome tool! Love it!

Update: Fixed in proxmox kernel 6.17.13-2-pve

Good news — after updating to [tt]6.17.13-2-pve[/tt], disk spin-down is working correctly again. The disks have been staying in standby for 10+ hours with no spurious wakeups, which is exactly the behavior I had on 6.14.

Interestingly the SATA link power management policy is still reporting [tt]max_performance[/tt] for the ASM1164, but the disks are now able to enter and stay in standby regardless. Something changed in the -2 rebuild that fixed the behavior without changing the reported policy. Attempting to manually set [tt]med_power_with_dipm[/tt] or [tt]min_power[/tt] still returns [tt]Operation not supported[/tt], but for practical purposes spin-down is working as expected.

If you're hitting this issue, upgrading to [tt]6.17.13-2-pve[/tt] should resolve it. Full technical details in the Proxmox forum thread: https://forum.proxmox.com/thre…ng-disk-spin-down.181474/