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>, Sudeep Holla <sudeep.holla@arm.com>,
Jeremy Linton <jeremy.linton@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: Mon, 12 Jan 2026 17:02:59 +0000 [thread overview]
Message-ID: <aWUpQ04uNcXtp0wR@bogus> (raw)
In-Reply-To: <20251231104909.80362-1-feng.tang@linux.alibaba.com>
On Wed, Dec 31, 2025 at 06:49:09PM +0800, Feng Tang wrote:
> There was warning message about PPTT table:
>
> "ACPI PPTT: PPTT table found, but unable to locate core 1 (1)",
>
> and it in turn caused scheduler warnings when building up the system.
> It took a while to root cause the problem be related a broken PPTT
> table which has wrong cache information.
>
> To speedup debugging similar issues, dump the PPTT table, which makes
> the warning more noticeable and helps bug hunting.
>
> The dumped info format on a ARM server is like:
>
> ACPI PPTT: Processors:
> P[ 0][0x0024]: parent=0x0000 acpi_proc_id= 0 num_res=1 flags=0x11(package)
> P[ 1][0x005a]: parent=0x0024 acpi_proc_id= 0 num_res=1 flags=0x12()
> P[ 2][0x008a]: parent=0x005a acpi_proc_id= 0 num_res=3 flags=0x1a(leaf)
> P[ 3][0x00f2]: parent=0x005a acpi_proc_id= 1 num_res=3 flags=0x1a(leaf)
> P[ 4][0x015a]: parent=0x005a acpi_proc_id= 2 num_res=3 flags=0x1a(leaf)
> ...
> ACPI PPTT: Caches:
> C[ 0][0x0072]: flags=0x7f next_level=0x0000 size=0x4000000 sets=65536 way=16 attribute=0xa line_size=64
> C[ 1][0x00aa]: flags=0x7f next_level=0x00da size=0x10000 sets=256 way=4 attribute=0x4 line_size=64
> C[ 2][0x00c2]: flags=0x7f next_level=0x00da size=0x10000 sets=256 way=4 attribute=0x2 line_size=64
> C[ 3][0x00da]: flags=0x7f next_level=0x0000 size=0x100000 sets=2048 way=8 attribute=0xa line_size=64
> ...
>
> It provides a global and straightforward view of the hierarchy of the
> processor and caches info of the platform, and from the offset info
> (the 3rd column), the child-parent relation could be checked.
>
> With this, the root cause of the original issue was pretty obvious,
> that there were some caches items missing which caused the issue when
> building up scheduler domain.
>
While this may sound like a good idea, it deviates from how errors in other
table-parsing code are handled. Instead of dumping the entire table, it would
be preferable to report the specific issue encountered during parsing.
I do not have a strong objection if Rafael is comfortable with this approach;
however, it does differ from the established pattern used by similar code.
Dumping the entire table in a custom manner is not the standard way of
handling parsing errors. Just my opinion.
--
Regards,
Sudeep
next prev parent reply other threads:[~2026-01-12 17:03 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 [this message]
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
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=aWUpQ04uNcXtp0wR@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 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.