From patchwork Mon Feb 4 20:28:04 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 2095111 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 8D3693FD56 for ; Mon, 4 Feb 2013 20:28:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754895Ab3BDU2N (ORCPT ); Mon, 4 Feb 2013 15:28:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52904 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754176Ab3BDU2M (ORCPT ); Mon, 4 Feb 2013 15:28:12 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r14KS5p8001123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Feb 2013 15:28:05 -0500 Received: from [10.3.113.8] ([10.3.113.8]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r14KS4Up016088; Mon, 4 Feb 2013 15:28:04 -0500 Message-ID: <1360009684.11144.539.camel@bling.home> Subject: Re: PCI warning on boot 3.8.0-rc1 From: Alex Williamson To: Stephen Hemminger Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, David Woodhouse , iommu@lists.linux-foundation.org Date: Mon, 04 Feb 2013 13:28:04 -0700 In-Reply-To: <20130204103645.38ae2d5e@nehalam.linuxnetplumber.net> References: <20130116143853.339dd89b@nehalam.linuxnetplumber.net> <20130204103645.38ae2d5e@nehalam.linuxnetplumber.net> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Mon, 2013-02-04 at 10:36 -0800, Stephen Hemminger wrote: > > I think drivers/pci/search.c is identical between 3.7 and 3.8-rc1. Is > > this the first time you've turned on the IOMMU on that box? > > It exists in 3.7 and earlier kernels, just haven't turned on same config. > > > It's the same warning as in this bugzilla: > > https://bugzilla.kernel.org/show_bug.cgi?id=44881, and there's a patch > > there at https://bugzilla.kernel.org/show_bug.cgi?id=44881#c11, but > > it's just a quirk that turns off VT-d if we find certain broken > > bridges. It doesn't look like you have any of those (although I don't > > know what you have at 05:00.0). > > > > Bjorn > > This is a standard ASUS motherboard, and don't want to disable VT-d. Stephen, Can you give the lspci -vvv of device 5:00.0 to see if it's one we've seen before? Does the patch below help? Bjorn, I think we need to quirk it somehow. So far they've all been PCI-to-PCI bridges attached to root ports where we expect it's actually a PCIe-to-PCI bridge. Seems like maybe we could have the same attached to a downstream port. The patch below avoids the WARN and gives us a device, but of course pci_is_pcie reports wrong for this device and may cause some trickle down breakage. A more complete option might be to add a is_pcie flag to the device that can be set independent of pcie_cap. We'd need to check all the callers for assumptions, but then we could put the quirk in one place and hopefully fix everything. Thoughts? Thanks, Alex --- 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/drivers/pci/search.c b/drivers/pci/search.c index bf969ba..65ae270 100644 --- a/drivers/pci/search.c +++ b/drivers/pci/search.c @@ -42,6 +42,15 @@ pci_find_upstream_pcie_bridge(struct pci_dev *pdev) } /* PCI device should connect to a PCIe bridge */ if (pci_pcie_type(pdev) != PCI_EXP_TYPE_PCI_BRIDGE) { + /* + * Not all PCIe-to-PCI bridges expose a PCIe + * capability. If we make it to a PCIe root port + * and the previous device was a PCI-to-PCI bridge, + * assume it was really a PCIe-to-PCI bridge. + */ + if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT && + tmp && tmp->hdr_type == PCI_HEADER_TYPE_BRIDGE) + return tmp; /* Busted hardware? */ WARN_ON_ONCE(1); return NULL;