public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Feng Tang <feng.tang@linux.alibaba.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	Jeremy Linton <jeremy.linton@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	James Morse <james.morse@arm.com>,
	Joanthan Cameron <Jonathan.Cameron@huawei.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ACPI: PPTT: Dump PPTT table when error detected
Date: Wed, 14 Jan 2026 15:06:09 +0000	[thread overview]
Message-ID: <aWew4SHS4c34z0AU@bogus> (raw)
In-Reply-To: <aWeoA7LDNSB_F38I@U-2FWC9VHC-2323.local>

On Wed, Jan 14, 2026 at 10:28:19PM +0800, Feng Tang wrote:
> 
> As for the original issue where kernel printed the error message
> " ACPI PPTT: PPTT table found, but unable to locate core 1 (1)",
> can we just printed out all the CPU entries of the PPTT table? 
> which is much cleaner and smaller, and have the enough information
> for quickly identifying the root cause. As the number of cache
> items is usually 3X of number of CPUs.

I am still not sure what additional value is gained by listing all those CPU
entries. On a 512-CPU system, for example, if an issue is identified with the
entry for CPU 256, what extra information is obtained by listing all the other
CPUs, such as those sharing the same L3 cache or entire list of CPUs on this
system?

The message above already indicates that something is wrong with core
(n = 1 in above case). If that is not sufficiently clear, it should be
improved to be more specific about the issue. Simply listing all CPUs in the
PPTT provides no additional insight and only results in an unnecessarily long
and distracting CPU list in the kernel log.

-- 
Regards,
Sudeep

  parent reply	other threads:[~2026-01-14 15:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-31 10:49 [PATCH v2] ACPI: PPTT: Dump PPTT table when error detected Feng Tang
2026-01-10  4:29 ` Hanjun Guo
2026-01-10 15:04   ` Feng Tang
2026-01-12 11:19     ` Hanjun Guo
2026-01-12 17:02 ` Sudeep Holla
2026-01-13  8:25   ` Feng Tang
2026-01-13 14:40     ` Sudeep Holla
2026-01-14  7:06       ` Feng Tang
2026-01-14 11:36         ` Rafael J. Wysocki
2026-01-14 14:28           ` Feng Tang
2026-01-14 14:55             ` Rafael J. Wysocki
2026-01-14 15:06             ` Sudeep Holla [this message]
2026-01-14 15:07               ` Rafael J. Wysocki
2026-01-15  9:05               ` Feng Tang
2026-01-15 10:02                 ` Sudeep Holla
2026-01-15 10:52                   ` Feng Tang
2026-01-13 16:21   ` Rafael J. Wysocki
2026-01-14  7:47     ` Feng Tang
2026-01-14 11:41       ` Rafael J. Wysocki

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=aWew4SHS4c34z0AU@bogus \
    --to=sudeep.holla@arm.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=feng.tang@linux.alibaba.com \
    --cc=guohanjun@huawei.com \
    --cc=james.morse@arm.com \
    --cc=jeremy.linton@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox