https://bugzilla.kernel.org/show_bug.cgi?id=218198 --- Comment #19 from Dieter Mummenschanz (dmummenschanz@xxxxxx) --- Hallo Niklas, thanks for getting back to me on that. > Please consider writing to the libata mailing list instead of using > bugzilla, I'm quite sure that you will get more eyes on your problem > that way. Could point me to that mailing list please. I can't seem to find it. Do you want me to repost the issue there or is it okay to just copy & past the messages from this bug? > It appears that you have built your kernel with: > CONFIG_SATA_MOBILE_LPM_POLICY=0 Definately not! I've attached my kernel config. LPM policy is definately set tp "3" CONFIG_SATA_MOBILE_LPM_POLICY=3. Thats puzzles me because after booting the link_power_management_policy is set to performance. Somehow the kernel overrides the config or uses parameters suggested by the BIOS I don't know. I've also tried to to switch the ASPM polity to Powersave instead of BIOS default. Didn't help. > In your v6.7-rcX dmesg, we don't see any: > "port does not support device sleep" or > "setting devsleep to %d" (from my debug patch) > prints in your dmesg from v6.7-rcX, so set_lpm() is never called at all, > most likely because you have built with CONFIG_SATA_MOBILE_LPM_POLICY=0, > so DevSleep could be enabled if platform firmware enabled it. The print is not called, right but not because of CONFIG_SATA_MOBILE_LPM_POLICY=0 since It is set to "3". However when I force link_power_management_policy to "echo med_power_with_dipm" the message appears in dmesg: [ 9.434663] ahci 0000:00:17.0: setting devsleep to: 0 port support 0 [ 9.434668] ahci 0000:00:17.0: port does not support device sleep [ 9.434674] ahci 0000:00:17.0: setting devsleep to: 0 port support 0 [ 9.434678] ahci 0000:00:17.0: port does not support device sleep so somehow the LPM Policy is either not set or reset by the kernel I assume. > However, the fact that you see "port does not support device sleep" > suggests that you either built your kernel with > CONFIG_SATA_MOBILE_LPM_POLICY set to something other than 0, > or you have manually overriden the policy via sysfs. > > Note that since your platform firmware claims that the port does > not support DevSleep (PxDEVSLP.DSP is set to 0), this means that > ahci_set_aggressive_devslp() will return early: > https://github.com/torvalds/linux/blob/v6.6/drivers/ata/libahci.c#L2258-L2262 > So it will neither enable nor disable DevSleep in the device, > so DevSleep could be enabled if platform firmware enabled it. > > > In both of your cases, it looks like you should have DevSleep set > to whatever platform firmware has set it to. > But you say that, for these logs, v6.6 can enter low CPU power states, > but v6.7-rcX can not? Not quite. In 6.6 the PC8 transition worked only when forcing link_power_management_policy to "echo med_power_with_dipm". The policy was still performance after bootup like it is in 6.7-rc. The only difference I see is that after resume my laptop won't enter PC8 again. For 6.7-rc I have to call hdparm -Y for sda and sdb after resume to enable the transition. > You can run: > hdparm -I /dev/<your_device> > to see if DEVSLP is enabled in your device (hdparm prints a * in front > of the feature if the feature is enabled). Attached to this bug for both (identical) drives. > It could also be worth checking your BIOS, I've seen some cases where you had > to enable aggressive devsleep in BIOS for it to get enabled for the port. My Laptop BIOS (INSYDE) does not offer any knobs to tune dleep for any ATA or PCI devices. Only thing I have set is the powersave profile. > The sysfs reporting for LPM is really broken in libata... > > $ git grep max_performance drivers/ata/libata-sata.c > drivers/ata/libata-sata.c: [ATA_LPM_UNKNOWN] = > "max_performance", > drivers/ata/libata-sata.c: [ATA_LPM_MAX_POWER] = > "max_performance", > > So it reports "max_performance" both for LPM_POLICY == 0 (ATA_LPM_UNKNOWN) > and LPM_POLICY == 1 (ATA_LPM_MAX_POWER). > > In your case, it is because of ATA_LPM_UNKNOWN, which means use whatever > platform firmware has configured. Thats confusing :( > ahci_update_initial_lpm_policy() will only override your policy if your > LPM_POLICY >= 3, so it will not override it for your case. > > I understand however I do not know of any other way to enable lower package > > states on my machine. > > I do not understand why that helps you. Me neither but it works. :( > If you set: > ATA_LPM_MED_POWER_WITH_DIPM (LPM_POLICY=3) on v6.6 in sysfs, > you can enter low CPU power states? > If you set > CONFIG_SATA_MOBILE_LPM_POLICY=3 on v6.6, > can you enter low CPU power states? As described above I'm doing this for years during bootup otherwise I'm stuck at PC2. > > Looking at AHCI 1.3.1 > PM:Aggr: > > State PM:DevSleep is gated with: > > PxDEVSLP.ADSE = ‘1’ and CAP2.SDS = ‘1’ and CAP2.SADM > = ‘1’ and PxDEVSLP.DSP = 1’ and PxSCTL.IPM != ‘4h’ and > PxSCTL.IPM != ‘5h’ and PxSCTL.IPM != ‘6h’ and PxSCTL.IPM > != ‘7h’ and CAP2.DESO = ‘0’ and pDitoTimeout = ‘1’ > > So AFAICT, ALPM by the HBA should never be able to transition > to DevSleep if PxDSP.DSP == 0. > > Perhaps your platform actually does NOT support devsleep and > simply requires the device to enter slumber or partial in order > to enter the lower CPU power states? How can I tell? > We could test this by you disabling devslp on the device via hdparm, > and see if you can still enter the lower CPU power states. Okay and how do I so that? Kind regards, Dieter -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
