From patchwork Fri Jan 29 16:24:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 8164691 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.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id BF3ACBEEE5 for ; Fri, 29 Jan 2016 16:24:10 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D28C820392 for ; Fri, 29 Jan 2016 16:24:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F10042015E for ; Fri, 29 Jan 2016 16:24:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753184AbcA2QYI (ORCPT ); Fri, 29 Jan 2016 11:24:08 -0500 Received: from mail.kernel.org ([198.145.29.136]:45247 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751413AbcA2QYG (ORCPT ); Fri, 29 Jan 2016 11:24:06 -0500 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id EDBF62015E; Fri, 29 Jan 2016 16:24:04 +0000 (UTC) Received: from localhost (unknown [69.71.1.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D951C2017D; Fri, 29 Jan 2016 16:24:03 +0000 (UTC) Date: Fri, 29 Jan 2016 10:24:00 -0600 From: Bjorn Helgaas To: Richard F Cc: linux-pci@vger.kernel.org Subject: Re: Hint HB6 - kernel doesn't see chips behind it. Message-ID: <20160129162400.GB12965@localhost> References: <5698191B.1070904@keynet-technology.com> <20160115172640.GC28453@localhost> <569CFB5B.7050903@keynet-technology.com> <20160119033839.GA3339@localhost> <56A8DA21.7060607@keynet-technology.com> <20160127215522.GA4875@localhost> <56A9EC07.8080509@keynet-technology.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <56A9EC07.8080509@keynet-technology.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, 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 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Jan 28, 2016 at 10:23:03AM +0000, Richard F wrote: > Bjorn, > > Thanks for looking at it. Actually I've tried 3 different PCI cards in > both slots and they all work fine. I have 2 different single channel > BT878 based PCI cards in there now capturing CCTV 24 x 7, the machine > stays up for months. That's why it's so odd. Any other pointers? Does > the kernel need the BIOS to detect the card right? The kernel should at least discover the card even if the BIOS doesn't do anything. But on x86, the BIOS usually *does* configure things, so it's very possible we could trip over a Linux defect if it doesn't. Try booting with "pci=pcie_scan_all". That *shouldn't* make a difference because this isn't a PCIe device, but maybe our logic is broken. Your topology looks a little strange: 00:1c.0 PCIe root port to [bus 01] slot 0 00:1c.1 PCIe root port to [bus 02] slot 1 00:1c.2 PCIe root port to [bus 03-05] slot 2 03:00.0 PCI bridge to [bus 04-05] (Integrated Technology Express) 04:01.0 PCI bridge to [bus 05] (Hint Corp) 00:1c.2 is a normal PCIe Root Port, so the device it's connected to *should* be a PCIe device, but 03:00.0 doesn't have a PCIe capability. Is this an adapter card of some kind? 03:00.0 is an ITE 8893, and we do have a quirk related to a similar device: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/quirks.c?h=v4.4#n3662 Can you try the patch below, please? --- 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 6d7ab9b..f6d8e85 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1530,6 +1530,7 @@ bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l, if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, l)) return false; + dev_info(&bus->dev, "%s %02x %#010x\n", __func__, devfn, *l); /* some broken boards return 0 or ~0 if a slot is empty: */ if (*l == 0xffffffff || *l == 0x00000000 || *l == 0x0000ffff || *l == 0xffff0000) @@ -1571,6 +1572,7 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn) struct pci_dev *dev; u32 l; + dev_info(&bus->dev, "%s %02x\n", __func__, devfn); if (!pci_bus_read_dev_vendor_id(bus, devfn, &l, 60*1000)) return NULL; @@ -1751,6 +1753,7 @@ struct pci_dev *pci_scan_single_device(struct pci_bus *bus, int devfn) { struct pci_dev *dev; + dev_info(&bus->dev, "%s %02x\n", __func__, devfn); dev = pci_get_slot(bus, devfn); if (dev) { pci_dev_put(dev); @@ -1825,6 +1828,7 @@ int pci_scan_slot(struct pci_bus *bus, int devfn) unsigned fn, nr = 0; struct pci_dev *dev; + dev_info(&bus->dev, "%s %02x\n", __func__, devfn); if (only_one_child(bus) && (devfn > 0)) return 0; /* Already scanned the entire slot */