Received: by 10.223.185.116 with SMTP id b49csp4105042wrg; Mon, 19 Feb 2018 11:10:08 -0800 (PST) X-Google-Smtp-Source: AH8x226i59q+Ot/oRxbK/C45vYchUWTVO+MyPJk0W74UejXbBHhDVGzy+e4sDpV590tB/HLpNMZG X-Received: by 10.99.116.23 with SMTP id p23mr12753408pgc.178.1519067408799; Mon, 19 Feb 2018 11:10:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519067408; cv=none; d=google.com; s=arc-20160816; b=xhHufxdcMapZ9MJZBMn6TkOks1fJp6rUt+xtSrDYKK1KWbj8Ydvy6lObhsh7Xn8CsX GweX7YFsB7zvVuS+6+thj+3yBgl91Kdgq2arg5uQI5PrRnSV0ntqwWwcXkdQeQF9fvoD hj1NmoMTAz3a2TYLPG0gaeF6kwMHzYEYtJcieeBBJ5quAM6XYpr/hx4CUuYqYZ1F1Pwb 0vzru3M09eye09YYJFrFAEhYgvR/SW2PwwjXMz299g4lZBd8ayMKNFieKukhXeySQCm8 UAODOAiJdJpMPVcj8REbWloNykU2zn0XbiALTGEp8jTwDcVuBoZkcpYWoz3PcX3blRJ/ LXkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:newsgroups:cc:to:subject :arc-authentication-results; bh=fO++efk3ZFSTJ5cQUtx/n4WVMQgEtSFdOHQ9tUXlLPY=; b=PbCXfTyVd8F9PVJluhsuWuuY9kPz+jaXpthA+p+VqC2KlbH/7IYbntLmaRKlLeDQiU kgC+GZow+LfZMstvz6/4kgFGMOn/7rfP5n6cvrJfCdAI7gKh1I793+zNJ431HmADWLhK +3ni+/kgN2WfYQLhWgSsS9hHHCZGKpLpYlu19addPwQkIEeIR9nuA4QPUTbZe18AuKde qD7HmeQ+Cd99WhyJPMSiZW5SNShJJuH6/IKhezNRQBrwnjvAMLwtinBf6abPrU+uayT4 W/9VQXkIbAQRiucIoqycZJCV66lfJNXqSCPIx3uY/FU2gop8LH8a7eYFUkL3r8t8P+DY UBEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a63si127229pgc.194.2018.02.19.11.09.54; Mon, 19 Feb 2018 11:10:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753548AbeBSTJO (ORCPT + 99 others); Mon, 19 Feb 2018 14:09:14 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34994 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753371AbeBSTJN (ORCPT ); Mon, 19 Feb 2018 14:09:13 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9F41040FB648; Mon, 19 Feb 2018 19:09:12 +0000 (UTC) Received: from washington.bos.jonmasters.org (ovpn-122-215.rdu2.redhat.com [10.10.122.215]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B68D1946B7; Mon, 19 Feb 2018 19:08:48 +0000 (UTC) Subject: Re: [PATCH] PCI: Add quirk for Cavium Thunder-X2 PCIe erratum #173 To: Bjorn Helgaas , "Rafael J. Wysocki" Cc: Mika Westerberg , George Cherian , George Cherian , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, bhelgaas@google.com, Jayachandran.Nair@cavium.com, Robert.Richter@cavium.com, Lorenzo Pieralisi Newsgroups: gmane.linux.kernel.pci,gmane.linux.kernel References: <1517554846-16703-1-git-send-email-george.cherian@cavium.com> <20180214201653.GA62268@bhelgaas-glaptop.roam.corp.google.com> <26660034.hqiP3ND89J@aspire.rjw.lan> <20180215233900.GA195653@bhelgaas-glaptop.roam.corp.google.com> From: Jon Masters Organization: World Organi{s,z}ation of Broken Dreams Message-ID: <4adb69b4-f566-cca8-6038-ab2e6be59d12@jonmasters.org> Date: Mon, 19 Feb 2018 14:08:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180215233900.GA195653@bhelgaas-glaptop.roam.corp.google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 19 Feb 2018 19:09:12 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 19 Feb 2018 19:09:12 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jcm@jonmasters.org' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn, Rafael, others, On 02/15/2018 06:39 PM, Bjorn Helgaas wrote: > On Thu, Feb 15, 2018 at 10:57:25PM +0100, Rafael J. Wysocki wrote: >> On Wednesday, February 14, 2018 9:16:53 PM CET Bjorn Helgaas wrote: >>> On Wed, Feb 14, 2018 at 04:58:08PM +0530, George Cherian wrote: >>>> On 02/13/2018 08:39 PM, Bjorn Helgaas wrote: >>>>> On Fri, Feb 02, 2018 at 07:00:46AM +0000, George Cherian wrote: >>>>>> The PCIe Controller on Cavium ThunderX2 processors does not >>>>>> respond to downstream CFG/ECFG cycles when root port is >>>>>> in power management D3-hot state. >>>>> >>>>> I think you're talking about the CPU initiating a config cycle to >>>>> a device below the root port, right? >>>> Yes >>> >>> If a bridge, e.g., a Root Port in your case, is in D3hot, we should be >>> able to access config space of the bridge itself, but the secondary >>> bus will be in B2 or B3 and we won't be able to access config space >>> for any devices below the bridge. This is true for *all* bridges, not >>> just this Cavium Root Port. >> >> Right. >> >> But AFAICS config space reads from devices that aren't there (which >> effectively is what happens if the bridge is in D3hot) are at least >> expected to return all ones. > > Yes. AIUI, the PCIe spec doesn't actually *require* all ones Indeed. This was my reading of the spec last year when I originally discovered this bug (and suggested the temporary bandaid of the runtime kernel parameter to disable pm for the port). I've seen this on certain Cavium ThunderX2 systems in specific configurations, but in my debug sessions it seemed that the problem was we're expecting all 1s and we don't get those, so we then ultimately get an SError and go to lunch. > But from the discussion below, it sounds like this may have helped > uncover a more serious Linux bug, i.e., we don't resume a device > before trying to use it. I suspected this too, but didn't get chance to followup. I had expected the above would have been posted many months ago. Jon. -- Computer Architect