From patchwork Wed May 21 23:18:03 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 351346 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 EBD7D140084 for ; Thu, 22 May 2014 09:18:34 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753361AbaEUXSN (ORCPT ); Wed, 21 May 2014 19:18:13 -0400 Received: from mail-ig0-f171.google.com ([209.85.213.171]:56719 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752710AbaEUXSG (ORCPT ); Wed, 21 May 2014 19:18:06 -0400 Received: by mail-ig0-f171.google.com with SMTP id c1so6887660igq.10 for ; Wed, 21 May 2014 16:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:to:from:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; bh=GEZF+nn9CRZMxcYp/8yAFyyFRXzqUg5IwvkSQAh/Yu8=; b=d29f1SaYbe4mFx48tP26fjefE9vZN/Zd0tAMCubD94NDbn+PdTZDnlaI+w5SYf+XOF E3GmsaAcYP5Iwka8RsRuzXjNQavTZM0T78Jh4bGClgrQGbOXDK2BeZzWipiYgHfawMO1 wbPRQLdoi5OxwESpT2u/RXHl9gd6oixnSAkKNtFq7Bo50bqZzNi9XBQhdlC5Vj1+ElSM 5GEPkLLPxCUPHGJeP6EULrCnmYE0xBICQ1JemYN8q+ENzGFIu/LV6STMW394RwUg4UQX o+gGupXnsSLucnuQZn9z3Byx5IFFw1v1TkCJvYA4t6i62i/FHSBT3UsK3uc2N5LRpZ/r 0rhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:from:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-type :content-transfer-encoding; bh=GEZF+nn9CRZMxcYp/8yAFyyFRXzqUg5IwvkSQAh/Yu8=; b=RBYLoY2xrxiSpw8sKyaHH/dx4hYkyU6XRnSUN0VtaXxQ0DHamztPhQ9XZGf9Txg2eX WLrhnu9GT7z3mdzpRiwN/oMcGNcTedOHwne/Txqxo+k33H9wfVa3A69vY/e4WolcP3Sy mvEcU47ft4uNaVPLUpEE2/vz2SWLt8kN1v1aFKOFGB1uG5AUuLerOitOWFG+bqtzf9vE bE3Tym54EkHkRhptxadVTSEua8QYcL/fXki4MH/tu2DcaxFalDhju7ymG5fJg3IN9xik JHXd3m8JMaEfVPBNX42lgbrdRT8Cqpa5Y4LrD84W1xz7Td0g4IEN9v6YFcR2Zed8II2B cXqg== X-Gm-Message-State: ALoCoQmACXa8UYvkamtyHq7jU768Rnt0Bx7NYALTGr9P/IEjqRGDo6j5mFCLJg3GoMbB+CAnu1Qq X-Received: by 10.50.2.8 with SMTP id 8mr17690078igq.32.1400714285453; Wed, 21 May 2014 16:18:05 -0700 (PDT) Received: from localhost ([172.16.49.204]) by mx.google.com with ESMTPSA id bc6sm8649339igb.9.2014.05.21.16.18.04 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 21 May 2014 16:18:04 -0700 (PDT) Subject: [PATCH V5 1/4] x86/PCI: Warn if we have to "guess" host bridge node information To: Suravee Suthikulpanit From: Bjorn Helgaas Cc: Robert Richter , Daniel J Blueman , Andreas Herrmann , linux-kernel@vger.kernel.org, Aravind Gopalakrishnan , linux-pci@vger.kernel.org, Borislav Petkov , Myron Stowe Date: Wed, 21 May 2014 17:18:03 -0600 Message-ID: <20140521231803.26447.42420.stgit@bhelgaas-glaptop.roam.corp.google.com> In-Reply-To: <20140521231615.26447.38060.stgit@bhelgaas-glaptop.roam.corp.google.com> References: <20140521231615.26447.38060.stgit@bhelgaas-glaptop.roam.corp.google.com> User-Agent: StGit/0.16 MIME-Version: 1.0 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): # 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) Link: https://bugzilla.kernel.org/show_bug.cgi?id=72051 Signed-off-by: Myron Stowe Signed-off-by: Suravee Suthikulpanit Signed-off-by: Bjorn Helgaas --- arch/x86/pci/acpi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index 01edac6c5e18..5075371ab593 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;