From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10579286416; Wed, 14 Jan 2026 14:28:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768400906; cv=none; b=MkYZTJuOHcPNptNo7zP//ZI2HiHQO9TwWjyh0WdSKmVm0UxJEre5mev9RoDe1gEGVyqj4SRm+27PTnqfoDtsLuxXiruZ3u2YT842koWeDGw70+weC6Dl4RIzKv43w27D5EKeQwoMH21678fGjr9RlJdtgNrqX5gHOVuhCrReuWg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768400906; c=relaxed/simple; bh=dEgz23FFfu4f1kLXVWZPzTpFA+XngIDOaxOHF32UHnE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ucKuORcRf5DMon7VvNN15NwkhhUIVvEDd81ncG+/U3VX4IIf278//Utiu85U1E9yO7wK+/j3sLXF0gJ8S0eDWQfKRXI1dFhEoavjCx5WnV/EnomdpOC30lIBRxVKBPiWbvVnUzwiEd/wlb0151T07NZBoTyR38ItYmDi1AHzupo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=LHm6Y8m7; arc=none smtp.client-ip=115.124.30.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="LHm6Y8m7" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1768400901; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=uHmQCxSU+Nsl2SI1GGnceOYZhOceZM7EOZK5RO7J8Pg=; b=LHm6Y8m7PEA17DzqSAOE9Kj2TbUinQZ0nff2y3kmY5zaRkFp09ootFBPi4Adk06Oz9i6aEi2A/By8a6e3woDUa6OTjpBNxv5A+JDec1IDh3eVNxic0RoeJTOAUEuZ+e3l+1vFz40wxuDVIY8vds6WSPXnQEtWkPBQBHuADQ1+fw= Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0Wx2jRmn_1768400899 cluster:ay36) by smtp.aliyun-inc.com; Wed, 14 Jan 2026 22:28:20 +0800 Date: Wed, 14 Jan 2026 22:28:19 +0800 From: Feng Tang To: "Rafael J. Wysocki" Cc: Sudeep Holla , Len Brown , Jeremy Linton , Hanjun Guo , James Morse , Joanthan Cameron , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] ACPI: PPTT: Dump PPTT table when error detected Message-ID: References: <20251231104909.80362-1-feng.tang@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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