Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp1120645ybc; Tue, 19 Nov 2019 15:00:56 -0800 (PST) X-Google-Smtp-Source: APXvYqyHO7NzonVdgAGgczA+iEuLqmYjWy9KPpW516tOBYhQPImW6GuXwtPp9ERkrv28DxmszxNq X-Received: by 2002:a17:906:e110:: with SMTP id gj16mr326198ejb.124.1574204455848; Tue, 19 Nov 2019 15:00:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574204455; cv=none; d=google.com; s=arc-20160816; b=aev18Ve9a0aIg7wBM0FqOC4A7/RFW7D9VEelP8hI6HCgS5hMcC5Va7ebWljVUD2sLl aOydk7BNa50dm3ZK3wIkmbSVg1aZnH5ja+wP2W2OR26pKoR3MjujNwTBC1KrlUgsrzDU xzHnrNmF0EdcWDFJ3K+SQHHp8NOYu0tSi95Cg+A+QDSM0btDO7tdviH8OeQTDZtAKCpV 5LquWfwvLA5vTah1i+sv947nyaxwNaOzg61X5J0NNcexaS4pZJCDMbBivnI0/JRGIrCs LaAJcGQhMAWDsUaHMeGELqFUis1IakQNy+/klHugtXrp0iEvJnrufvdMYE3Wwc2g563H XLPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=lSDE2rZ/5bCW0yJPN/Z5OmuLVtWH03JYZE7JeR7br4c=; b=0l9MdR7SUj3szWzoT0NnBhYxuaIxGUwWYBfxNDIlfDPmMyl6X0Khoz5js/WlLiXSkm PQfKyYESRc23a65AB2H/vce0cNkb6XCbOJZlGo37b8nuXkoTkzjhP1/7dMgOLY+r62I4 t0JObjSTVbFWbUvNHWnXtALJwsWe63s85ETh6/T8d+dXXusDj5ans8A21JWDk8WNUow4 xCQD6RQYdDKkkfnH8U2cP5FOtd3eV/0dl6N+2jCNcaD80LXVRMZPYe5QvVTXPk51oa/5 mUcsJt0g/JprzKvZCMTlo+NuZXgUjgq4Q9BLdRo5rkzAGUb+u//TlW+6+0VexgZOAf/M FOpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=E52+6cgL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j20si14859468ejm.348.2019.11.19.15.00.30; Tue, 19 Nov 2019 15:00:55 -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; dkim=pass header.i=@kernel.org header.s=default header.b=E52+6cgL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727348AbfKSW5Z (ORCPT + 99 others); Tue, 19 Nov 2019 17:57:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:50628 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726025AbfKSW5Y (ORCPT ); Tue, 19 Nov 2019 17:57:24 -0500 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 41B882245B; Tue, 19 Nov 2019 22:57:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574204243; bh=MfxbIsx2AwLtCUhkamnT0UAwFBGbj1YyWpFNWLIPhMM=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=E52+6cgLfMfo9ceaHCYZ+iAp4zf56dFMAe0NcguaKJCgzSyAD9J19ZM6oLMsh0R0R JOkfl/XLao+RYszehEsWWTShlZeOhUuIiZOAk7lvjnwKmyQlFn7Vd+w0/9CGSoA0i4 Cc2z3+YhUvhSgeBDsRLdaEMY+KWsj10hEhoT7Wz0= Date: Tue, 19 Nov 2019 16:57:21 -0600 From: Bjorn Helgaas To: Karol Herbst Cc: LKML , Lyude Paul , "Rafael J . Wysocki" , Mika Westerberg , Linux PCI , Linux PM , dri-devel , nouveau , Dave Airlie , Daniel Drake , Vidya Sagar , Thierry Reding Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges Message-ID: <20191119225721.GA237491@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+cc Daniel, Vidya, Thierry; thread starts at https://lore.kernel.org/r/20191017121901.13699-1-kherbst@redhat.com] On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote: > On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote: > > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote: > > > Fixes state transitions of Nvidia Pascal GPUs from D3cold into > > > higher device states. > > > ... > > > + * - kernel crashes, as all pci reads return -1, which most code > > > + * isn't able to handle well enough. > > > > More details about these crashes would be useful as we look at > > places that *should* be able to handle errors like this. > > makes sense, I could ,orthogonal to this, make the code more robust > if we hit issues like this in the future. What I am mostly wondering > about is, why pci core doesn't give up if the device doesn't come > back from D3cold? It sounds like, that the most sane thing to do > here is to just give up and fail runtime_resume and report errors > back to userspace trying to make use of the devices. It's possible there's something the core could do here. It's interesting that we have at least three issues in this area in this release: 1) This NVIDIA GPU issue 2) Daniel's issue with AMD Ryzen5/7 XHCI power-on (https://lore.kernel.org/r/20191014061355.29072-1-drake@endlessm.com) 3) Vidya's issue with Intel 750 NVMe power-on (https://lore.kernel.org/r/20191118172310.21373-1-vidyas@nvidia.com) Vidya's current patch is the most generic (calling pci_dev_wait() from pci_power_up()). That will print a warning if the device doesn't respond, but we still don't go as far as returning errors to runtime_resume. This is definitely something we should consider improving in the future. > > > + * - sudden shutdowns, as the kernel identified an unrecoverable error after > > > + * userspace tries to access the GPU. > > > > This doesn't fit with the others and more details might be > > informative here as well. > > yeah.. I try to get more infos on that. But at least for me (and it > might be a distribution thing) if I execute lspci, the system shuts > down, or at least tries to and might fail. The lspci doesn't need to be after the failure occurs. You can do it immediately after boot. If you can capture any part of the dmesg or console log of these sudden shutdowns, that's all I'm interested in at this point. Bjorn