Re: [PATCH v2] ACPI: PPTT: Dump PPTT table when error detected

From: Hanjun Guo

Date: Mon Jan 12 2026 - 06:19:11 EST


On 2026/1/10 23:04, Feng Tang wrote:
Hi Hanjun,

[...]

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.

Just a discussion, can we just dump the raw PPTT table via acpidump
in user space when we meet the problem? With the raw PPTT table, we
can go though the content to see if we have problems.

Good point! We can use iasl to decode the PPTT table. And this dump
is still useful as:
* when enabling new silicon or new firmware (APCI tables), sometimes it
can't make to boot to user space when the issue happens.
* This dump shows the processor and cache items separately and cleanly,
while the P[]/C[] index imply the numbers. In an 128 core product ARM
sever, the print with this patch is about 500 line, while the acpidump
is about 10,000 lines and harder to parse.

Thanks for the user case, it makes sense to me.


[...]
/**
* topology_get_acpi_cpu_tag() - Find a unique topology value for a feature
* @table: Pointer to the head of the PPTT table
@@ -565,6 +638,8 @@ static int topology_get_acpi_cpu_tag(struct acpi_table_header *table,
}
pr_warn_once("PPTT table found, but unable to locate core %d (%d)\n",
cpu, acpi_cpu_id);
+
+ acpi_dump_pptt_table(table);

I think it would be good to dump it as needed, as a debug feature.

Makes sense to me. Should I add a kernel config option or a module
parameter for it, or just change the pr_info to pr_debug (it's in
a unlikely error path)?

PPTT driver can not be compiled as a module, I would like to add a
kernel config for it.

Thanks
Hanjun