All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	hmh@hmh.eng.br
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	ibm-acpi-devel@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: WARNING at drivers/acpi/platform_profile.c:74 in platform_profile_show()
Date: Mon, 25 Sep 2023 09:19:31 +0200	[thread overview]
Message-ID: <beeab87b-820a-475a-b0c6-99b1b8e491ea@kernel.org> (raw)
In-Reply-To: <505264f5-cbbb-4ffe-a3e4-93d2397e80da@kernel.org>

On 25. 09. 23, 7:42, Jiri Slaby wrote:
> On 25. 09. 23, 7:35, Jiri Slaby wrote:
>> Hi,
>>
>> according to logs, since 6.3 (up to 6.5.4 now), I repeatedly see:
>>  > WARNING: CPU: 14 PID: 962 at drivers/acpi/platform_profile.c:74 
>> platform_profile_show+0xb1/0x100 [platform_profile]
>>  > Modules linked in: ccm michael_mic ...
>>  > CPU: 14 PID: 962 Comm: power-profiles- Kdump: loaded Not tainted 
>> 6.5.4-6-default #1 openSUSE Tumbleweed (unreleased) 
>> dd37106c593be78644bb80e3c1534d801bf4cb36
>>  > Hardware name: LENOVO 21CRS0K83K/21CRS0K83K, BIOS R22ET60W (1.30 ) 
>> 02/09/2023
>>  > RIP: 0010:platform_profile_show+0xb1/0x100 [platform_profile]
>>  > Code: d0 a8 ...
>>  > RSP: 0018:ffff9c1ac0b97db0 EFLAGS: 00010296
>>  > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000008fc35be0
>>  > RDX: 0000000000000000 RSI: ffff9c1ac0b97db4 RDI: ffffffffc0a8b0a0
>>  > RBP: ffff8955ca540000 R08: ffff895b9f1ed180 R09: ffff895559ea1bc0
>>  > R10: 00000000031a400e R11: 000000000003f680 R12: ffff895b9f1ed180
>>  > R13: ffff9c1ac0b97e50 R14: 0000000000000001 R15: ffff9c1ac0b97ee8
>>  > FS:  00007f71b0e71900(0000) GS:ffff895b9f100000(0000) 
>> knlGS:0000000000000000
>>  > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>  > CR2: 00007fe402ea3400 CR3: 000000012004c000 CR4: 0000000000750ee0
>>  > PKRU: 55555554
>>  > Call Trace:
>>  >  <TASK>
>>  >  sysfs_kf_seq_show+0xab/0x100
>>  >  seq_read_iter+0x123/0x480
>>  >  vfs_read+0x1b8/0x300
>>
>> It's:
>> WARN_ON((profile < 0) || (profile >= ARRAY_SIZE(profile_names))))
>>
>> So I put there one more print:
>> dev_warn(dev, "profile=%d profile_get=%ps\n",
>>           profile, cur_profile->profile_get);
>>
>> and I see:
>> : profile=-1883022368 profile_get=dytc_profile_get [thinkpad_acpi]
>> : profile=-1510173440 profile_get=dytc_profile_get [thinkpad_acpi]
>> : profile=-1510173440 profile_get=dytc_profile_get [thinkpad_acpi]
>> : profile=-966231712 profile_get=dytc_profile_get [thinkpad_acpi]
>> : profile=-1578420592 profile_get=dytc_profile_get [thinkpad_acpi]
>> : profile=-1578420592 profile_get=dytc_profile_get [thinkpad_acpi]
>> : profile=-1578420592 profile_get=dytc_profile_get [thinkpad_acpi]
>>
>> where the profile values in hex are like:
>> ffffffff8fc35be0
>> ffffffffa5fc9500
>> ffffffffc6687960
>>
>> Looking at simplicity of dytc_profile_get(), I wonder how that can 
>> happen.
>>
>> I also wonder about dev passed to dytc_profile_get() having empty name 
>> (nothing before colon above)? Is that expected?
> 
> I forgot to add:
>    cat /sys/firmware/acpi/platform_profile
> correctly returns:
>    low-power
> 
> without any WARNING. It looks like the warn often (but not exclusively) 
> happens around:
> PM: suspend exit
> 
>> Any ideas?
> 
> Ah, convert_dytc_to_profile()'s retval is not checked in 
> dytc_profile_refresh(). That's likely it, let me add the check and retry.

OK,
so adding:
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -10418,7 +10418,14 @@ static void dytc_profile_refresh(void)
                 return;

         perfmode = (output >> DYTC_GET_MODE_BIT) & 0xF;
-       convert_dytc_to_profile(funcmode, perfmode, &profile);
+       err = convert_dytc_to_profile(funcmode, perfmode, &profile);
+       if (err) {
+               pr_warn("%s: mmc=%u psc=%u mmc_get=%u funcmode=%d 
output=0x%x perfmode=%d\n",
+                          __func__, !!(dytc_capabilities & 
BIT(DYTC_FC_MMC)),
+                          !!(dytc_capabilities & BIT(DYTC_FC_PSC)),
+                          dytc_mmc_get_available, funcmode, output, 
perfmode);
+               return;
+       }
         if (profile != dytc_current_profile) {
                 dytc_current_profile = profile;
                 platform_profile_notify();

fixes the warning, of course.

The output is:
dytc_profile_refresh: mmc=0 psc=1 mmc_get=0 funcmode=0 output=0x1f001 
perfmode=15

So using psc mode, it retrieves DYTC (0x1f001) as follows:
0x1.... -> VSTD=1 -> STD mode
0x.f... -> CICM=0xf, DYTC_GET_MODE_BIT(12) -> dunno what it is in STD
0x..0.. -> CICF=0x0, DYTC_GET_FUNCTION_BIT(8) -> DYTC_FUNCTION_STD
0x....1 -> GOOD

But convert_dytc_to_profile() doesn't handle this at all. Do I have a 
newer DYTC interface? Or a broken one?

My DYTC for CMD_GET looks like:
    Case (0x02)
    {
        Local5 = VSTD /* \VSTD */
        Local5 |= (VCQL << 0x01)
        Local5 |= (VSTP << 0x04)
        Local5 |= (VADM << 0x07)
        Local5 |= (VTMS << 0x09)
        Local5 |= (VDLS << 0x0A)
        Local5 |= (VMSC << 0x0C)
        Local5 |= (VPSC << 0x0D)
        Local1 = (CICF << 0x08)
        If ((CICF == 0x03))
        {
            CICM = SMYH /* \SMYH */
        }
        ElseIf ((CICF == 0x0B))
        {
            CICM = SMMC /* \SMMC */
        }
        ElseIf ((CICF == 0x0D))
        {
            CICM = SPSC /* \SPSC */
        }
        ElseIf ((CICF == 0x0F))
        {
            CICM = SAMT /* \SAMT */
        }
        ElseIf ((CICF == 0x07))
        {
            CICM = SADM /* \SADM */
        }
        Else
        {
            CICM = 0x0F
        }

        Local1 |= (CICM << 0x0C)
        Local1 |= (Local5 << 0x10)
        Local1 |= 0x01
    }

>> thanks,
> 

-- 
js
suse labs


  reply	other threads:[~2023-09-25  7:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-25  5:35 WARNING at drivers/acpi/platform_profile.c:74 in platform_profile_show() Jiri Slaby
2023-09-25  5:42 ` Jiri Slaby
2023-09-25  7:19   ` Jiri Slaby [this message]
2023-09-25  7:38     ` Jiri Slaby
2023-09-25  8:57       ` Hans de Goede
2023-09-25  9:15         ` Jiri Slaby
2023-09-25 12:56           ` Mark Pearson
2023-09-25 12:58         ` Mark Pearson

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=beeab87b-820a-475a-b0c6-99b1b8e491ea@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=hmh@hmh.eng.br \
    --cc=ibm-acpi-devel@lists.sourceforge.net \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@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.