All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Dieter Mummenschanz <dmummenschanz@web.de>
Cc: linux-ide@vger.kernel.org, Damien Le Moal <dlemoal@kernel.org>
Subject: Re: Re: Re:  Re: Re: [PATCH 0/2] Power management fixes
Date: Mon, 5 Feb 2024 20:00:59 +0100	[thread overview]
Message-ID: <ZcEwa4fOzMif8lCd@x1-carbon> (raw)
In-Reply-To: <trinity-78c294c6-cd07-4a27-befa-3f3fc9bd79da-1706885616508@3c-app-webde-bs04>

Hello Dieter,

On Fri, Feb 02, 2024 at 03:53:36PM +0100, Dieter Mummenschanz wrote:
> 
> > Yes, this part of the problem can be avoided by adding an explicit entry
> > that uses "board_ahci_low_power", as I explained in:
> > https://lore.kernel.org/linux-ide/ZaATdGDOo5jiBqCR@x1-carbon/T/#u[https://lore.kernel.org/linux-> ide/ZaATdGDOo5jiBqCR@x1-carbon/T/#u]
> 
> > We seem to have a problem with Tiger Lake, but that problem seems to be
> > related to Intel VMD.
> 
> > From looking at your logs, you don't seem to have Intel VMD, however
> > I'm guessing that some other motherboards that uses Cannon Lake might
> > have Intel VMD, so I guess the safest thing is to wait until that issue
> > has been resolved before adding a "board_ahci_low_power" entry for
> > Cannon Lake.
> 
> This mighht be kind of naive but what about adding an kernel option to force LPM even if the chipset/board is not oficially supported?

That is a good suggestion.
However, I'm hoping that this series:
https://lore.kernel.org/linux-ide/3e50681d-7a68-4c4a-91f6-278a3cfe23f8@amd.com/T/

Will avoid the need for that, as it would kill the
"board_ahci_low_power" board type completely.


> 
> > I see now that Damien's revert (patch 2/2 in this series) is not a simple
> > $ git revert fd3a6837d8e18cb7be80dcca1283276290336a7a
> > it seems to have some other small changes in the same patch as well.
> 
> > Sorry for asking you to test something once more...
> > But could you please test with:
> > v6.6-rc2 + git revert fd3a6837d8e18cb7be80dcca1283276290336a7a
> 
> No problem. I've explicitly reverted with 6.8-rc2 and have the kernel running for 1 1/2 days now with 3 suspends and on all of them my system transitions to pc8 so I guess we're good but I'll keep on testing to be sure. Hope this helps.

After talking with Damien, we are still completely lost.

commit fd3a6837d8e1 ("ata: libata-core: Fix ata_pci_shutdown_one()")
only modifies the ata_pci_shutdown_one(), which is only called on shutdown.

It is not called in the system suspend / system resume path,
so it should not be possible for this commit to have an impact.


Reading all the emails and bugzilla again, what you are seeing is that:

On a fresh boot, and leaving the computer untouched for a few minutes,
and looking at e.g. turbostat, some of your CPUs have spent time in
the lower-power C-states, e.g. C8/C9/C10.

However, if you do a system suspend + system resume, and then leave
the computer untouched for a few minutes, and look at e.g. turbotstat,
_none_ of your CPUs have spend time in the lower-power C-states.

Is this correct?


If so, it seems that suspend/resume must have messed up some setting...

The commit that added the code to ata_pci_shutdown_one()
was added in:
5b6fba546da2 ("ata: libata-core: Detach a port devices on shutdown")
This was first added in v6.7-rc1.
(So this commit was never included in v6.6.)

The code added in 5b6fba546da2 was later removed in:
commit fd3a6837d8e1 ("ata: libata-core: Fix ata_pci_shutdown_one()")
which was first added in v6.7-rc1.

Are you certain that v6.6 works and v6.7 is bad?

There are quite few libata patches between v6.6 and v6.7:
$ git log --oneline v6.7 --not v6.6 -- drivers/ata

Damien has sent many libata patches related to suspend/resume in the
last couple of kernel releases, so it is possible that something has
regressed. We just have a really hard time seeing how fd3a6837d8e1
could be the bad commit.


Kind regards,
Niklas

  reply	other threads:[~2024-02-05 19:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 11:51 [PATCH 0/2] Power management fixes Damien Le Moal
2024-01-11 11:51 ` [PATCH 1/2] ata: libata-core: Do not try to set sleeping devices to standby Damien Le Moal
2024-02-14 11:03   ` Niklas Cassel
2024-01-11 11:51 ` [PATCH 2/2] ata: libata-core: Revert "ata: libata-core: Fix ata_pci_shutdown_one()" Damien Le Moal
2024-01-11 18:10   ` Sergei Shtylyov
2024-01-11 23:13     ` Damien Le Moal
2024-02-19 15:29     ` Niklas Cassel
2024-02-23 21:04       ` Sergey Shtylyov
2024-02-26  9:28         ` Niklas Cassel
     [not found] ` <DU0P251MB082515FC8FE77424231B475CF4682@DU0P251MB0825.EURP251.PROD.OUTLOOK.COM>
2024-01-22  8:49   ` [PATCH 0/2] Power management fixes Damien Le Moal
     [not found]     ` <trinity-0be6e8a8-e6d3-4d60-be0d-59592a9edd65-1706010022623@3c-app-webde-bap10>
2024-01-23 11:52       ` Aw: " Damien Le Moal
     [not found]         ` <trinity-0df92d73-be55-433c-bdb2-4387f7ea590b-1706686178879@3c-app-webde-bap43>
2024-01-31  7:38           ` Aw: " Damien Le Moal
2024-01-31 11:49             ` Niklas Cassel
2024-01-31 12:09               ` Damien Le Moal
2024-02-01  7:12                 ` Aw: " Dieter Mummenschanz
2024-02-01  8:09                   ` Damien Le Moal
2024-02-01  7:10               ` Dieter Mummenschanz
2024-02-01 10:51                 ` Niklas Cassel
2024-02-02 14:53                   ` Aw: " Dieter Mummenschanz
2024-02-05 19:00                     ` Niklas Cassel [this message]
     [not found]                       ` <trinity-0bc8e6ea-7808-4508-af3a-be22281abf24-1707231996854@3c-app-webde-bs42>
2024-02-06 21:46                         ` Niklas Cassel
2024-02-08 14:37                           ` Aw: " Dieter Mummenschanz
2024-02-13 20:02                             ` Niklas Cassel

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=ZcEwa4fOzMif8lCd@x1-carbon \
    --to=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=dmummenschanz@web.de \
    --cc=linux-ide@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.