linux-kernel - Re: [REGRESSION] libata: SATA LPM forcibly disabled on Intel Jasper Lake since Linux 6.13

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: <be700824-09a2-4ebe-bc87-0b5bd71c20b7@kernel.org>
Date: Mon, 15 Dec 2025 15:47:34 +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

On 12/15/25 13:28, Bernard Drozd wrote:
> 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

Got it: your AHCI adapter has:

ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
ahci 0000:00:17.0: 2/2 ports implemented (port mask 0x3)
ahci 0000:00:17.0: flags: 64bit ncq sntf pm led clo only pio slum part deso sadm sds

Partial and slumber are supported, so all good.

BUT ! your ports are...

ata1: SATA max UDMA/133 abar m2048@...0102000 port 0x80102100 irq 142 lpm-pol 1 ext
ata2: SATA max UDMA/133 abar m2048@...0102000 port 0x80102180 irq 142 lpm-pol 1 ext

...external. That is, the adapter is saying that these are
external/hot-pluggable ports, and for these, power management is a bad
idea/should be disabled, which we do. The reason is that otherwise, we cannot
catch hot-plug/unplug events (IRQs).

So to enable low-power policies, you need to go into your BIOS settings and
disable the hot-plugging capability for the ports. Many BIOSes have such setting
for SATA ports. If your BIOS does not have this, yu can use the mask_port_ext
AHCI module parameter. Simply add:

ahci.mask_port_ext=0x3 to your kernel command line and the "ext" flag of the
ports will be ignored and LPM enabled.


-- 
Damien Le Moal
Western Digital Research