From patchwork Sat Sep 13 04:07:16 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 4899211 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 823F8BEEA5 for ; Sat, 13 Sep 2014 04:07:32 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8B27C20274 for ; Sat, 13 Sep 2014 04:07:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 625042022A for ; Sat, 13 Sep 2014 04:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751432AbaIMEHW (ORCPT ); Sat, 13 Sep 2014 00:07:22 -0400 Received: from mail-ie0-f182.google.com ([209.85.223.182]:56210 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751428AbaIMEHU (ORCPT ); Sat, 13 Sep 2014 00:07:20 -0400 Received: by mail-ie0-f182.google.com with SMTP id tr6so2091928ieb.27 for ; Fri, 12 Sep 2014 21:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Il1LWj79x9FEyNSUBdWtuZeuroKhlAvtinWwD7BMGz4=; b=ZwoF4+chjVltCpgnGyMfVQ6HMFi71ZHi1xXb2HBq40FbcaGQa2vWTAxu1HSy+V1gF0 NlC6uAoMEAigvEOroqdBFbA7GuD0WX/3cLm+gCuF+KfGNexbeIZQihREYy8giRT6XoIl k7aRKmUH/CBLDFIYcbdeioWbuphdjWxq+MMTLk9SHpmEcOaKvqTgembeeSADWk57xyo7 PqCFhRiazYk+qO4cwSOGRCKC8lX8gcMSwPyIm6FmnJB+6kmKG2ZnNJjg7VnJJRx1vnrB z2wNJpuxbyj/mj6ytwwbYseJqr4nAf04HMAKUxvOWDLeIWL9Qb4jow3l6CMoiuNp2pIK NI0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Il1LWj79x9FEyNSUBdWtuZeuroKhlAvtinWwD7BMGz4=; b=KtAG4HOdoYeq+2VEQMDJyri8YrO1Be5aGTVB674ta02UiLK3DsE0bRjnrOcFA3nJBs UaTAgCJ0z9gpJ+Qkiwfi6QNXEqmkN8eCofLpvoejOnHU1mqV/3Gy+gKmAwZGQ+YbKqsb 6lDAJfraxNdvO8Mt4H3Af/L+AXwXJRbrCqZUzsB/QEtqLe1qChd2hbc9niZ74xEzm4Dw tVN0TitytKtsgWC7E4WcuPsL0/N+RkjebpzDlFERJl6JCCNW94MK8hGmGyk71VMdl9Xx F6CxqV9AObSSR8x8ni8rZ/k5cWJlP3cmrm9NK58D9H96TAww5nOLsb3s84cSvkzAqJVm YLhg== X-Gm-Message-State: ALoCoQmV8xP36iibDXK6aA1bLvT+llX+Oi/zyXJmLMXplwEkGz5QK0F7VwhCdOqZhAanlVzSvqFG X-Received: by 10.50.143.65 with SMTP id sc1mr7150222igb.19.1410581239570; Fri, 12 Sep 2014 21:07:19 -0700 (PDT) Received: from google.com (173-8-252-97-Colorado.hfc.comcastbusiness.net. [173.8.252.97]) by mx.google.com with ESMTPSA id ij9sm3379027igb.10.2014.09.12.21.07.18 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 12 Sep 2014 21:07:18 -0700 (PDT) Date: Fri, 12 Sep 2014 22:07:16 -0600 From: Bjorn Helgaas To: Yinghai Lu Cc: Dirk Gouders , Linus Torvalds , Andreas Noever , Linux Kernel , "linux-pci@vger.kernel.org" Subject: Re: [BUG] Bisected Problem with LSI PCI FC Adapter Message-ID: <20140913040716.GA28080@google.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I want to fix this regression before v3.17. Dirk, can you test the following patch on top of v3.17-rc2? I'm hoping you can try this on your test machine in conjunction with your acpi_pci_root_add() and pci_scan_device() patches. If I understand correctly, you were able to reproduce the FC adapter not showing up, and if you can verify that it does show with those patches + this revert, I think that's good enough for now. I'm not committed to applying this yet, but I'd like to have a working fix in my back pocket in case we don't come up with a better solution soon. Bjorn commit 5945a8d28c416fc390a94c8e7fb8fd0a76f5d710 Author: Bjorn Helgaas Date: Fri Sep 12 21:58:19 2014 -0600 Revert "PCI: Make sure bus number resources stay within their parents bounds" This reverts commit 1820ffdccb9b ("PCI: Make sure bus number resources stay within their parents bounds") because it breaks some systems with LSI Logic FC949ES Fibre Channel Adapters, apparently by exposing a defect in those adapters. Dirk tested a Tyan VX50 (B4985) with this device that worked like this prior to 1820ffdccb9b: bus: [bus 00-7f] on node 0 link 1 ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-07]) pci 0000:00:0e.0: PCI bridge to [bus 0a] pci_bus 0000:0a: busn_res: can not insert [bus 0a] under [bus 00-07] (conflicts with (null) [bus 00-07]) pci 0000:0a:00.0: [1000:0646] type 00 class 0x0c0400 (FC adapter) Note that the root bridge [bus 00-07] aperture is wrong; this is a BIOS defect in the PCI0 _CRS method. But prior to 1820ffdccb9b, we didn't enforce that aperture, and the FC adapter worked fine at 0a:00.0. After 1820ffdccb9b, we notice that 00:0e.0's aperture is not contained in the root bridge's aperture, so we reconfigure it so it *is* contained: pci 0000:00:0e.0: bridge configuration invalid ([bus 0a-0a]), reconfiguring pci 0000:00:0e.0: PCI bridge to [bus 06-07] This effectively moves the FC device from 0a:00.0 to 07:00.0, which should be legal. But when we enumerate bus 06, the FC device doesn't respond, so we don't find anything. This is probably a defect in the FC device. Possible fixes (due to Yinghai): 1) Add a quirk to fix the _CRS information based on what amd_bus.c read from the hardware 2) Reset the FC device after we change its bus number 3) Revert 1820ffdccb9b Fix 1 would be relatively easy, but it does sweep the LSI FC issue under the rug. We might want to reconfigure bus numbers in the future for some other reason, e.g., hotplug, and then we could trip over this again. For that reason, I like fix 2, but we don't know whether it actually works, and we don't have a patch for it yet. This revert is fix 3, which also sweeps the LSI FC issue under the rug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84281 Reported-by: Dirk Gouders Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.15+ CC: Yinghai Lu --- 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/probe.c b/drivers/pci/probe.c index e3cf8a2e6292..f0badff77cff 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -775,7 +775,7 @@ int pci_scan_bridge(struct pci_bus *bus, struct pci_dev *dev, int max, int pass) /* Check if setup is sensible at all */ if (!pass && (primary != bus->number || secondary <= bus->number || - secondary > subordinate || subordinate > bus->busn_res.end)) { + secondary > subordinate)) { dev_info(&dev->dev, "bridge configuration invalid ([bus %02x-%02x]), reconfiguring\n", secondary, subordinate); broken = 1; @@ -853,8 +853,7 @@ int pci_scan_bridge(struct pci_bus *bus, struct pci_dev *dev, int max, int pass) child = pci_add_new_bus(bus, dev, max+1); if (!child) goto out; - pci_bus_insert_busn_res(child, max+1, - bus->busn_res.end); + pci_bus_insert_busn_res(child, max+1, 0xff); } max++; buses = (buses & 0xff000000) @@ -913,11 +912,6 @@ int pci_scan_bridge(struct pci_bus *bus, struct pci_dev *dev, int max, int pass) /* * Set the subordinate bus number to its real value. */ - if (max > bus->busn_res.end) { - dev_warn(&dev->dev, "max busn %02x is outside %pR\n", - max, &bus->busn_res); - max = bus->busn_res.end; - } pci_bus_update_busn_res_end(child, max); pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max); }