From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F01E0C433E0 for ; Mon, 18 May 2020 10:26:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D11C120657 for ; Mon, 18 May 2020 10:26:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726270AbgERK0j (ORCPT ); Mon, 18 May 2020 06:26:39 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:57178 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726180AbgERK0i (ORCPT ); Mon, 18 May 2020 06:26:38 -0400 Received: from 89-64-86-21.dynamic.chello.pl (89.64.86.21) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.415) id 3ef8d7e6de62ea20; Mon, 18 May 2020 12:26:35 +0200 From: "Rafael J. Wysocki" To: Andy Shevchenko Cc: "larsh@apache.org" , "ibm-acpi-devel@lists.sourceforge.net" , "platform-driver-x86@vger.kernel.org" , ACPI Devel Maling List , David Box Subject: Re: Low Latency Tolerance preventing Intel Package from entering deep sleep states Date: Mon, 18 May 2020 12:26:34 +0200 Message-ID: <2952287.p5mUHPKNZq@kreacher> In-Reply-To: References: <1505028180.591737.1589564161284.ref@mail.yahoo.com> <1505028180.591737.1589564161284@mail.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Friday, May 15, 2020 11:41:16 PM CEST Andy Shevchenko wrote: > +Cc: ACPI ML and Rafael +Cc: David Box > On Fri, May 15, 2020 at 8:36 PM larsh@apache.org wrote: > > > > Hi. I hope this is the right forum to raise this... > > > > For a while I have noticed that my CPU (i9-9880H in a Lenovo X1 Extreme Gen2) never enters any sleep mode below pc2. > > (Confirmed with powertop and /sys/kernel/debug/pmc_core/package_cstate_show) > > > > Interestingly the CPU *can* reachers deeper C states *after* a resume from sleep (either S0ix or S3, i.e. freeze or mem). > > > > This article finally pointed me in the right direction: https://01.org/blogs/qwang59/2020/linux-s0ix-troubleshooting > > > > Somehow SOUTHPORT_A is requesting a max latency of 1 us. > > There are no external devices attached. > > > > This is before a resume: > > > > $ cat /sys/kernel/debug/pmc_core/ltr_show > > SOUTHPORT_A LTR: RAW: 0x88018c01 Non-Snoop(ns): 1024 Snoop(ns): 32768 <------- > > SOUTHPORT_B LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > SATA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > GIGABIT_ETHERNET LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > XHCI LTR: RAW: 0x13ff Non-Snoop(ns): 0 Snoop(ns): 0 > > Reserved LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > ME LTR: RAW: 0x8000800 Non-Snoop(ns): 0 Snoop(ns): 0 > > EVA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > SOUTHPORT_C LTR: RAW: 0x9f409f4 Non-Snoop(ns): 0 Snoop(ns): 0 > > HD_AUDIO LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > CNV LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > LPSS LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > SOUTHPORT_D LTR: RAW: 0x8c548c54 Non-Snoop(ns): 2752512 Snoop(ns): 2752512 > > SOUTHPORT_E LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > CAMERA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > ESPI LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > SCC LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > ISH LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > UFSX2 LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > EMMC LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > WIGIG LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > CURRENT_PLATFORM LTR: RAW: 0x40201 Non-Snoop(ns): 0 Snoop(ns): 0 > > AGGREGATED_SYSTEM LTR: RAW: 0x7fbfdfe Non-Snoop(ns): 0 Snoop(ns): 0 > > > > Notice the 1000ns max latency requirement for SOUTHPORT_A. > > > > Ignoring SOUTHPORT_A via /sys/kernel/debug/pmc_core/ltr_ignore subsequently allows the CPU to reach deep sleep states. > > > > After a resume it looks like suddenly SOUTHPORT_C is active and with a less tight latency requirement: > > > > $ cat /sys/kernel/debug/pmc_core/ltr_show > > SOUTHPORT_A LTR: RAW: 0x8010c01 Non-Snoop(ns): 0 Snoop(ns): 0 <-------- > > SOUTHPORT_B LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > SATA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > GIGABIT_ETHERNET LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > XHCI LTR: RAW: 0x13ff Non-Snoop(ns): 0 Snoop(ns): 0 > > Reserved LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > ME LTR: RAW: 0x8000800 Non-Snoop(ns): 0 Snoop(ns): 0 > > EVA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > SOUTHPORT_C LTR: RAW: 0x88468846 Non-Snoop(ns): 71680 Snoop(ns): 71680 <--------- > > HD_AUDIO LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > CNV LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > LPSS LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > SOUTHPORT_D LTR: RAW: 0x8c548c54 Non-Snoop(ns): 2752512 Snoop(ns): 2752512 > > SOUTHPORT_E LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > CAMERA LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > ESPI LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > SCC LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > ISH LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > UFSX2 LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > EMMC LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > WIGIG LTR: RAW: 0x0 Non-Snoop(ns): 0 Snoop(ns): 0 > > CURRENT_PLATFORM LTR: RAW: 0x40201 Non-Snoop(ns): 0 Snoop(ns): 0 > > AGGREGATED_SYSTEM LTR: RAW: 0x904824 Non-Snoop(ns): 0 Snoop(ns): 0 > > > > Does anybody know what's going on or how to debug this further? > > > > As stated above, I was able to work around this problem by ignoring SOUTHPORT_A via /sys/kernel/debug/pmc_core/ltr_ignore. > > There has to be a better way, and I'm sure I'm not the only one running into this. > > > > Thanks. > > > > -- Lars > > > >