Message-ID: <a7d59365-776f-4e92-9f70-98ad9d101f27@kernel.org>
Date: Mon, 15 Dec 2025 10:36:15 +0900
From: Damien Le Moal <dlemoal@...nel.org>
To: Bernard Drozd <bernid@...eria.pl>, linux-ide@...r.kernel.org,
 linux-kernel@...r.kernel.org
Cc: Niklas Cassel <cassel@...nel.org>
Subject: Re: [REGRESSION] libata: SATA LPM forcibly disabled on Intel Jasper
 Lake since Linux 6.13

+Niklas

On 12/15/25 00:26, Bernard Drozd wrote:
> Hello,
> 
> I am reporting a power-management regression in libata affecting Intel 
> Jasper Lake platforms, introduced after Linux 6.12.
> 
> Hardware:
> - CPU / SoC: Intel Jasper Lake (Elkhart Lake class)
> - SATA controller: Intel Jasper Lake SATA AHCI Controller (PCI ID 8086:4d03)
> - Drives tested: SATA SSD + SATA HDD (multiple vendors)
> - Distribution: Debian 13 (Trixie)
> - Kernel versions tested:
>    - 6.12.x  → OK
>    - 6.17.x  → REGRESSION
> 
> Problem description:
> Since kernel >= 6.13, SATA Link Power Management (LPM) is forcibly disabled.
> The sysfs interface still exists but only reports:
> 
>    /sys/class/scsi_host/host*/link_power_management_policy = max_performance

That is normal if either the device connected to this host or the adapter itself
is identified as not supporting LPM.

> Attempts to change it fail silently or are ignored:
> 
> echo 'med_power_with_dipm' > 
> '/sys/class/scsi_host/host0/link_power_management_policy'
> echo 'med_power_with_dipm' > 
> '/sys/class/scsi_host/host1/link_power_management_policy'

Again, normal in the context described above.

> This worked correctly on kernel 6.12.x and earlier.

Which was a horrible bug: the ata subsystem was identifying the device or
adapter as not supporting LPM, but the sysfs knob was left open for chnages, and
systemd would happily set whatever power management policy it wanted, even if
the device or adapter did not support it. So this "worked correctly" is actually
"that was a really nasty bug".

The problem here is to understand why you adapter/device is identified as not
supporting LPM, even though it seems to do support it.

> Observed effects:
> - SATA devices never enter partial/slumber
> - CPU package C-states are limited (system mostly stuck in PC2 (before 
> the change i had C10))
> - Idle power consumption increases by ~5 W
> - powertop shows SATA LPM tunables as permanently "Bad"

Yes, all normal if LPM is disabled and you are stuck with max performance policy.

> Relevant dmesg output (6.17.x):
>    ata1: SATA link power management disabled due to platform quirk
>    ata2: SATA link power management disabled due to platform quirk

Please send everything that scsi/ahci/ata prints. That is not nearly enough to
understand what is going on here.

Looking at the ahci driver, I do not see any special quirks for PCI ID
8086:4d03. So we need all the messages from the latest kernel to understand this.

> This appears to be caused by the libata change disabling LPM on Intel 
> platforms
> without a per-platform whitelist. Jasper Lake does not exhibit 
> instability with
> LPM enabled and worked reliably on previous kernels.

There is no quirk applied to the adapter PCI ID 8086:4d03 that I can see. So it
will be initialized with board_ahci, meaning that LPM will be allowed, but only
if we detect that the adapter report that as supported. If the adapter does not
have the right bits set reporting LPM support, especially DIPM/HIPM, then LPM
will be disabled. Please send the full dmesg so that we can check.

> Expectation:
> - Either re-enable LPM for Intel Jasper Lake
> - Or provide a kernel parameter to override the forced LPM disable
>    (e.g. libata.allow_lpm=1)
> 
> This regression significantly impacts low-power systems and fanless mini-PCs
> based on Jasper Lake.
> 
> Please let me know if additional logs or testing are needed.
> 
> Best regards,
> bern
> 
> 


-- 
Damien Le Moal
Western Digital Research

Powered by blists - more mailing lists