From patchwork Wed May 7 18:58:46 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suravee Suthikulpanit X-Patchwork-Id: 346774 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 4B9631401B1 for ; Thu, 8 May 2014 04:59:37 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751331AbaEGS7X (ORCPT ); Wed, 7 May 2014 14:59:23 -0400 Received: from mail-bn1lp0141.outbound.protection.outlook.com ([207.46.163.141]:11944 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751632AbaEGS7T (ORCPT ); Wed, 7 May 2014 14:59:19 -0400 Received: from DM2PR02CA001.namprd02.prod.outlook.com (10.141.52.139) by BN1PR02MB118.namprd02.prod.outlook.com (10.255.204.19) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 18:59:17 +0000 Received: from BL2FFO11FD005.protection.gbl (2a01:111:f400:7c09::107) by DM2PR02CA001.outlook.office365.com (2a01:111:e400:2414::11) with Microsoft SMTP Server (TLS) id 15.0.939.12 via Frontend Transport; Wed, 7 May 2014 18:59:15 +0000 Received: from atltwp01.amd.com (165.204.84.221) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server id 15.0.929.8 via Frontend Transport; Wed, 7 May 2014 18:59:06 +0000 X-WSS-ID: 0N57WQF-07-NDZ-02 X-M-MSG: Received: from satlvexedge02.amd.com (satlvexedge02.amd.com [10.177.96.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by atltwp01.amd.com (Axway MailGate 5.3.1) with ESMTPS id 2F335CAE7F5; Wed, 7 May 2014 13:59:03 -0500 (CDT) Received: from SATLEXDAG05.amd.com (10.181.40.11) by SATLVEXEDGE02.amd.com (10.177.96.29) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 7 May 2014 13:59:33 -0500 Received: from ssuthiku-fedora-lt.amd.com (10.180.168.240) by satlexdag05.amd.com (10.181.40.11) with Microsoft SMTP Server id 14.2.328.9; Wed, 7 May 2014 14:58:13 -0400 From: To: , CC: , Aravind Gopalakrishnan , Borislav Petkov , "Robert Richter" , Daniel J Blueman , Andreas Herrmann , Myron Stowe , Suravee Suthikulpanit Subject: [PATCH V3 2/3] ACPI/PCI: Warn if we have to "guess" host bridge node information Date: Wed, 7 May 2014 13:58:46 -0500 Message-ID: <1399489127-6961-3-git-send-email-suravee.suthikulpanit@amd.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1399489127-6961-1-git-send-email-suravee.suthikulpanit@amd.com> References: <1399489127-6961-1-git-send-email-suravee.suthikulpanit@amd.com> MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:165.204.84.221; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(428001)(46034005)(199002)(189002)(50986999)(77156001)(4396001)(36756003)(80022001)(21056001)(46102001)(20776003)(53416003)(575784001)(33646001)(86362001)(93916002)(79102001)(64706001)(2009001)(50226001)(76176999)(101416001)(84676001)(86152002)(92566001)(89996001)(50466002)(99396002)(76482001)(92726001)(15975445006)(62966002)(88136002)(87936001)(68736004)(44976005)(19580395003)(19580405001)(97736001)(74662001)(83322001)(77982001)(47776003)(31966008)(83072002)(81542001)(48376002)(74502001)(85852003)(81342001)(87286001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR02MB118; H:atltwp01.amd.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Forefront-PRVS: 0204F0BDE2 Received-SPF: None (: amd.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 165.204.84.221) smtp.mailfrom=Suravee.Suthikulpanit@amd.com; X-OriginatorOrg: amd4.onmicrosoft.com Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Myron Stowe The vast majority of platforms are not supplying ACPI _PXM (proximity) information corresponding to host bridge (PNP0A03/PNP0A08) devices resulting in sysfs "numa_node" values of -1 (NUMA_NO_NODE) [1]: # for i in /sys/devices/pci0000\:00/*/numa_node; do cat $i; done | uniq -1 # find /sys/ -name "numa_node" | while read fname; do cat $fname; \ done | uniq -1 AMD based platforms provide a fall-back for this situation via amd_bus.c. These platforms snoop out the information by directly reading specific registers from the Northbridge and caching them via 'alloc_pci_root_info'. Later during boot processing when host bridges are discovered - 'pci_acpi_scan_root' - the kernel looks for their corresponding ACPI _PXM method - drivers/acpi/numa.c::acpi_get_node(). If the BIOS supplied a _PXM method then that node (proximity) value is associated. If the BIOS did not supply a _PXM method *and* the platform is AMD based, the fall-back cached values obtained directly from the Northbridge are used; otherwise, "NUMA_NO_NODE" is associated. There are a number of issues with this fall-back mechanism the most notable being that amd_bus.c extracts a 3-bit number from a CPU register and uses it as the node number. The node numbers used by Linux are logical and there's no reason they need to be identical to settings in the CPU registers. So if we have some node information obtained in the normal way (from _PXM, SLIT, SRAT, etc.) and some from amd_bus.c, there's no reason to believe they will be compatible. This patch warns when this situation occurs: pci_root PNP0A08:00: [Firmware Bug]: no _PXM; falling back to node 0 from hardware (may be inconsistent with ACPI node numbers) [1] https://bugzilla.kernel.org/show_bug.cgi?id=72051 Signed-off-by: Myron Stowe Signed-off-by: Suravee Suthikulpanit --- arch/x86/pci/acpi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index 01edac6..5075371 100644 --- a/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -489,8 +489,12 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root) } node = acpi_get_node(device->handle); - if (node == NUMA_NO_NODE) + if (node == NUMA_NO_NODE) { node = x86_pci_root_bus_node(busnum); + if (node != 0 && node != NUMA_NO_NODE) + dev_info(&device->dev, FW_BUG "no _PXM; falling back to node %d from hardware (may be inconsistent with ACPI node numbers)\n", + node); + } if (node != NUMA_NO_NODE && !node_online(node)) node = NUMA_NO_NODE;