lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cc94bc84-c5a0-4c29-a249-d0ab99abdc17@interia.pl>
Date: Mon, 15 Dec 2025 05:28:36 +0100
From: Bernard Drozd <bernid@...eria.pl>
To: Damien Le Moal <dlemoal@...nel.org>, 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

Hi Damien,
Thank you for the explanation – I understand now that pre-6.13 behaviour 
was relying on a bug allowing userspace to override unsupported LPM.
I have collected full diagnostics comparing a *working* kernel (6.12) 
and a *regressed* kernel (6.17), both tested with **no SATA devices 
connected**.

Important correction:
The correct SATA controller PCI ID is:
Intel Jasper Lake SATA AHCI Controller [8086:4dd3]
This was mistakenly reported earlier as 4d03.

Key observation:
The LPM disable happens even with no SATA devices attached, so this 
appears to be a **platform-level decision**, not device capability.

Data provided:
1) Full dmesg, Linux 6.12 (LPM works, CPU reaches PC10):
https://www.dropbox.com/scl/fi/pwc0bfgoqgb607babczg9/dmesg-6.12-full.txt?rlkey=o8j88lzeq3rw3cbx2q65oyblv&st=u4dwqv0p&raw=1

2) Full dmesg, Linux 6.17 (LPM forced to max_performance, CPU stuck in PC2):
https://www.dropbox.com/scl/fi/twbyjm7h5ewgmllit02h8/dmesg-6.17-full.txt?rlkey=p3b97lli6ruo5ypg4c2d4jnc2&st=3o3xo47m&raw=1

3) AHCI/SATA diagnostics, Linux 6.12 (no disks attached):
https://www.dropbox.com/scl/fi/mve88utfnrzdilut364p1/6.12.txt?rlkey=zz7x8nqafdslvfjovinzbw26d&st=h0n95d75&raw=1

4) AHCI/SATA diagnostics, Linux 6.17 (no disks attached):
https://www.dropbox.com/scl/fi/viedk35gor5mry49qlkby/6.17.txt?rlkey=fmp4zaizbl22hd2fh6jg4rx8w&st=alwlux85&raw=1

Summary of difference:
- 6.12:
     lpm-pol = 0
     link_power_management_policy = med_power_with_dipm
     ahci.mobile_lpm_policy=3 works
- 6.17:
     lpm-pol = 1 ext
     link_power_management_policy = max_performance (write rejected)
     ahci.mobile_lpm_policy ignored
     CPU package cannot enter deep C-states

This results in ~5W higher idle power on fanless Jasper Lake systems.

Please let me know:
- which capability/quirk check changed after 6.12
- and whether a kernel parameter or quirk override could be used for testing

Best regards,
Bernard

On 15/12/2025 02:44, Damien Le Moal wrote:
> 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)
> Byt the way, I see this:
>
> ahci.c: /* Elkhart Lake IDs 0x4b60 & 0x4b62 https://sata-io.org/product/8803 not
> tested yet */
> ahci.c: { PCI_VDEVICE(INTEL, 0x4b63), board_ahci_pcs_quirk }, /* Elkhart Lake
> AHCI */
>
> So the same "Elkhart Lake", but different PCI ID. Looking at PCI IDs databases,
> I do not find anything with ID 8086:4d03. Can you please check your PCI ID ?
>
> Though board_ahci_pcs_quirk does not disable LPM...
>
>
>> - 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
>>
>> 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'
>>
>> This worked correctly on kernel 6.12.x and earlier.
>>
>> 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"
>>
>> 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
>>
>> 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.
>>
>> 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
>>
>>
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ