From nobody Sun Feb 8 05:28:53 2026 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (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 11B96225417; Wed, 31 Dec 2025 10:49:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767178162; cv=none; b=BdDQNJNQn8TB3+mJoI7rbV/bt92Y3GGzSy2GUu76IJ6U/d36+F+nAjDyvbESIbNAeaKzZ5k27RP+KemuOPttq9gQT9nakxvKeLm22g7l2/IhLaOM9mJXf5L/nhg1JWGYEbxIr8uP+5HAplUEJVk+sqJjMWjwRhbO9UEPvXKpxdI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767178162; c=relaxed/simple; bh=wesGWpaFZfLfc/qcrebn5WJGQNMib4kGF7+MrpA0JXk=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=MftRFR5M8N8WkvAmXe4lP2E/14E6V+5TX8KHUFfw1GP72xororNVYDG07DQw0WEby/ZHZNR65TgGQX1slk4nclc9ZazTQW5+0Lh4x51jctOe3E0DfsOouEY+7zLP5aMw+3G5vbGx4HMoko8UonHZjcMabZlJied9FiYrETI3O7o= 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=WNAkSFxD; arc=none smtp.client-ip=115.124.30.113 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="WNAkSFxD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1767178150; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=Bb1n0ZhpW/PPrNYcQOofvr3GIFzDTWK4I+Gn+/f9wYo=; b=WNAkSFxDFhf3yZ4UGHXzxPyWChoPC6k+pP8faRZTxGKDWPkgCZmJx0Jvx4kbEdvsrFIyjXbx4GsqU5v/VoO45lNjj9C7RVhbeYCHN+crifpNJ0kIjNKcnHOTKOgf+SFUj6dfGVBTHCpumxB87CqLA/idG41XSg7nunwFyo6ObbU= Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0Ww0smfC_1767178149 cluster:ay36) by smtp.aliyun-inc.com; Wed, 31 Dec 2025 18:49:10 +0800 From: Feng Tang To: "Rafael J . Wysocki" , Len Brown , Jeremy Linton , Hanjun Guo , James Morse Cc: Joanthan Cameron , Sudeep Holla , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Feng Tang Subject: [PATCH v2] ACPI: PPTT: Dump PPTT table when error detected Date: Wed, 31 Dec 2025 18:49:09 +0800 Message-Id: <20251231104909.80362-1-feng.tang@linux.alibaba.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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=3D0x0000 acpi_proc_id=3D 0 num_res=3D1 flags=3D= 0x11(package) P[ 1][0x005a]: parent=3D0x0024 acpi_proc_id=3D 0 num_res=3D1 flags=3D= 0x12() P[ 2][0x008a]: parent=3D0x005a acpi_proc_id=3D 0 num_res=3D3 flags=3D= 0x1a(leaf) P[ 3][0x00f2]: parent=3D0x005a acpi_proc_id=3D 1 num_res=3D3 flags=3D= 0x1a(leaf) P[ 4][0x015a]: parent=3D0x005a acpi_proc_id=3D 2 num_res=3D3 flags=3D= 0x1a(leaf) ... ACPI PPTT: Caches: C[ 0][0x0072]: flags=3D0x7f next_level=3D0x0000 size=3D0x4000000 set= s=3D65536 way=3D16 attribute=3D0xa line_size=3D64 C[ 1][0x00aa]: flags=3D0x7f next_level=3D0x00da size=3D0x10000 set= s=3D256 way=3D4 attribute=3D0x4 line_size=3D64 C[ 2][0x00c2]: flags=3D0x7f next_level=3D0x00da size=3D0x10000 set= s=3D256 way=3D4 attribute=3D0x2 line_size=3D64 C[ 3][0x00da]: flags=3D0x7f next_level=3D0x0000 size=3D0x100000 set= s=3D2048 way=3D8 attribute=3D0xa line_size=3D64 ... 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. Signed-off-by: Feng Tang --- Changelog: v2 * rebase againt 6.19 and refine the commit log drivers/acpi/pptt.c | 75 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c index de5f8c018333..e00abedcd786 100644 --- a/drivers/acpi/pptt.c +++ b/drivers/acpi/pptt.c @@ -529,6 +529,79 @@ static void acpi_pptt_warn_missing(void) pr_warn_once("No PPTT table found, CPU and cache topology may be inaccura= te\n"); } =20 +static void acpi_dump_pptt_table(struct acpi_table_header *table_hdr) +{ + struct acpi_subtable_header *entry, *entry_start; + unsigned long end; + struct acpi_pptt_processor *cpu; + struct acpi_pptt_cache *cache; + u32 entry_sz, i; + u8 len; + static bool dumped; + + /* PPTT table could be pretty big, no need to dump it twice */ + if (dumped) + return; + dumped =3D true; + + end =3D (unsigned long)table_hdr + table_hdr->length; + entry_start =3D ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, + sizeof(struct acpi_table_pptt)); + + pr_info("Processors:\n"); + entry_sz =3D sizeof(struct acpi_pptt_processor); + entry =3D entry_start; + i =3D 0; + while ((unsigned long)entry + entry_sz <=3D end) { + len =3D entry->length; + if (!len) { + pr_warn("Invalid zero length subtable\n"); + return; + } + + cpu =3D (struct acpi_pptt_processor *)entry; + entry =3D ACPI_ADD_PTR(struct acpi_subtable_header, entry, len); + + if (cpu->header.type !=3D ACPI_PPTT_TYPE_PROCESSOR) + continue; + + printk(KERN_INFO "P[%3d][0x%04lx]: parent=3D0x%04x acpi_proc_id=3D%3d nu= m_res=3D%d flags=3D0x%02x(%s%s%s)\n", + i++, (unsigned long)cpu - (unsigned long)table_hdr, + cpu->parent, cpu->acpi_processor_id, + cpu->number_of_priv_resources, cpu->flags, + cpu->flags & ACPI_PPTT_PHYSICAL_PACKAGE ? "package" : "", + cpu->flags & ACPI_PPTT_ACPI_LEAF_NODE ? "leaf" : "", + cpu->flags & ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD ? ", thread" : "" + ); + + } + + pr_info("Caches:\n"); + entry_sz =3D sizeof(struct acpi_pptt_cache); + entry =3D entry_start; + i =3D 0; + while ((unsigned long)entry + entry_sz <=3D end) { + len =3D entry->length; + if (!len) { + pr_warn("Invalid zero length subtable\n"); + return; + } + + cache =3D (struct acpi_pptt_cache *)entry; + entry =3D ACPI_ADD_PTR(struct acpi_subtable_header, entry, len); + + if (cache->header.type !=3D ACPI_PPTT_TYPE_CACHE) + continue; + + printk(KERN_INFO "C[%4d][0x%04lx]: flags=3D0x%02x next_level=3D0x%04x si= ze=3D0x%-8x sets=3D%-6d way=3D%-2d attribute=3D0x%-2x line_size=3D%d\n", + i++, (unsigned long)cache - (unsigned long)table_hdr, + cache->flags, cache->next_level_of_cache, cache->size, + cache->number_of_sets, cache->associativity, + cache->attributes, cache->line_size + ); + } +} + /** * 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); return -ENOENT; } =20 base-commit: c8ebd433459bcbf068682b09544e830acd7ed222 --=20 2.39.5 (Apple Git-154)