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

[Feng Tang <feng.tang@linux.alibaba.com>]

On Wed, Jan 14, 2026 at 12:36:58PM +0100, Rafael J. Wysocki wrote:
> > > Sure, that could be an option as long as CONFIG_ACPI_PPTT_ERR_DUMP is default
> > > off and are enabled only when debugging and not always like in distro images.
> > > Does that work for you ?
> >
> > Yes. It sounds great to me.
> >
> > > > We have had this in our tree for a while, and the good part is it gives a
> > > > direct overview of all the processors and caches in system, you get to
> > > > know the rough number of them from the index, and items are listed side
> > > > by side so that some minor error could be very obvious in this comparing
> > > > mode.
> > > >
> > >
> > > Agreed, but all this info are available to userspace in some form already.
> > > What does this dump give other than debugging a broken PPTT ?
> >
> > It is mainly for debugging issues. Though we locally has option to dump it
> > on boot unconditionally to help kernel/BIOS devleoper to have a quick
> > overview of the PPTT table, as the table gets updated from time to time,
> > or sometime the kernel could fail before booting to user space.
> 
> The kernel message buffer is not a great place for dumping ACPI tables though.

Yes.

> If an invalid PPTT prevents the system from booting, print out enough
> information to identify the cause of the failure.

Good suggestion! We do have some cases that wrong or missing info
of some ACPI table entries cause boot failure like IORT table.

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.

> 
> For everything else, use the tools in user space.

OK.

Thanks,
Feng