public inbox for linux-ide@vger.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Bernard Drozd <bernid@interia.pl>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Niklas Cassel <cassel@kernel.org>
Subject: Re: [REGRESSION] libata: SATA LPM forcibly disabled on Intel Jasper Lake since Linux 6.13
Date: Mon, 15 Dec 2025 10:36:15 +0900	[thread overview]
Message-ID: <a7d59365-776f-4e92-9f70-98ad9d101f27@kernel.org> (raw)
In-Reply-To: <635cb04f-eda3-49ec-b8bc-62f4e8c7926f@interia.pl>

+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

  reply	other threads:[~2025-12-15  1:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-14 15:26 [REGRESSION] libata: SATA LPM forcibly disabled on Intel Jasper Lake since Linux 6.13 Bernard Drozd
2025-12-15  1:36 ` Damien Le Moal [this message]
2025-12-15  1:44 ` Damien Le Moal
2025-12-15  4:28   ` Bernard Drozd
2025-12-15  6:47     ` Damien Le Moal
2025-12-15  9:30       ` Bernard Drozd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a7d59365-776f-4e92-9f70-98ad9d101f27@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=bernid@interia.pl \
    --cc=cassel@kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox