Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp241404pxb; Mon, 13 Sep 2021 18:06:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEAgSsHsDDqtUyCtCe58+HCeTT0nnyR+Q9fpnIBCqPEbqHizHlihgKRvcsHJ1XGh7ONKKi X-Received: by 2002:aa7:cb86:: with SMTP id r6mr16178514edt.181.1631581597662; Mon, 13 Sep 2021 18:06:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631581597; cv=none; d=google.com; s=arc-20160816; b=uDAMJ0DgzpH7zXScDijEBFA98WRHed0EFzKyNRoAtKcySlS+Ess6/dyctrz6CY5Gaz Ll8e8maHsNZJQ3GZKwLDN39e+O7yVmtDl9sKa9LmoYd6axGyd3njEeIM3pr3qq2xMr1x WBnh8G0YELCmkGqqiHwJj6qQKF+i6V8CXnZ27UouZdyesJ4BjQxUOrsnUwBdQbjn6T90 0xmKz+izx8QQZ4vYK0GUMr67Ul8+Mjx8WgePSQB7i35Cd31xen9tiGSAyM/mGSVsgZjS TPAHkXKc/q1w0ZxU5wOWitmNhlhb5kkLG/fesWhtKuFrnPFvosLSOHsdhUMtGPEljZAZ AMDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to:dkim-signature; bh=5BdvwOG+6brlU0D3bu5VRlz5Ma1oo1EfgyPoxcREHNc=; b=AluUrf056iWi6BqFtETqQU5ceVuVM7ckzlpap0YYoVXfvkCXSMHgUDvJP8yb9bCIX6 LqXY1qzFO8qmVT6hCi4fciKY4AYWl64B7WnAvmysdWhRvD1+Y562iIbEsUCWn3GuRnh/ UIvY/hqziccXm405QcOOSFlTW4TZaFj6THWWGSQe4RW6G0iyUSJoJbwYNdrPetwkIrEW gcEDEZlEkkWsrT+R7FuYRG9omHfP/IjK2kJCxkvMlZXwWyj+VnTd1BT+kcc4jMHtX5Gx VVvGXav2DxP3nGl7UDlKwcbp3ksBuXBCJXR1Q6sD2fdybzRixjMCVmYiRs74gDYC92/F VQ9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=jGM8xa4H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mm25si2523042ejb.307.2021.09.13.18.06.14; Mon, 13 Sep 2021 18:06:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=jGM8xa4H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242917AbhIMUNF (ORCPT + 99 others); Mon, 13 Sep 2021 16:13:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236133AbhIMUND (ORCPT ); Mon, 13 Sep 2021 16:13:03 -0400 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 890C2C061574; Mon, 13 Sep 2021 13:11:47 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id z184-20020a1c7ec1000000b003065f0bc631so296030wmc.0; Mon, 13 Sep 2021 13:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5BdvwOG+6brlU0D3bu5VRlz5Ma1oo1EfgyPoxcREHNc=; b=jGM8xa4HqxA+zZC0bigHTjuqCcKJKPBdcnFPqYh1kHFwzxK3fsARm20pxL5svSVN2l QekatSTLP7x8gm5MlOTLvOD7SGaLP2lI2moov5QWqhxHTPzxuRbKcYai7beOhq5RKnB1 /fFYnAjImgP5pEni4mt8MGp7HgAY8UMfWsDPTDaNRd4ligJ2yZge7Z6jJyZ37xMMGJV4 if9xQ2H3ycs1K4OWL8jVxztt98iyARqfC7zQ1jUQgt4+L3YUNdQeeLhPDrjTzj4DVe6h xfIN69KvYB9HHAz3lBddaql33YQxVOpRhUS5H0YCrIii6kNNzvQruozPK6+HziIXKY3F i2dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5BdvwOG+6brlU0D3bu5VRlz5Ma1oo1EfgyPoxcREHNc=; b=fTUrP99KCZG+GSE9y/Sm58Ia3Rki7/J9zu6o/fSq5rB2tx2qzt+DPZEhGKeB0XnPOK SNQq2bYqxbvtrIZld+tbyAr5qsigxbn59mBR8imFjri9qt8yYyyNz/mndUa8vBq+c626 3MDrZMHbhgtLWBYaOF96fu+Dmmfkaef+c/jYfvXtDqGNgJEqcjhfnyYnnSG8r95qAKO0 9vbyyrtBeeXskFUF4T0F6KI4hKB1IWmqGyC+FB1uVseViRXDtCrYQdBvIR11KvOWk4CZ D9GgwG750YI1VPRG9uWZHEaw1uUE1hc1lE0oUHA5QpGn0yEV4aElk7ieytGjUZnaqspU reig== X-Gm-Message-State: AOAM530UE38bABzwG+isJC0c3s02Hu/ah0aOhoPcaAm//pmNsa6AwUEy ugf1T5RY/PXgkLn7Q/9nxpHXLHJOh1A= X-Received: by 2002:a1c:7e12:: with SMTP id z18mr13327752wmc.60.1631563905920; Mon, 13 Sep 2021 13:11:45 -0700 (PDT) Received: from ?IPv6:2003:ea:8f08:4500:2517:8cca:49d8:dcdc? (p200300ea8f08450025178cca49d8dcdc.dip0.t-ipconnect.de. [2003:ea:8f08:4500:2517:8cca:49d8:dcdc]) by smtp.googlemail.com with ESMTPSA id s10sm8451247wrg.42.2021.09.13.13.11.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 13:11:45 -0700 (PDT) To: Linus Torvalds Cc: Dave Jones , Linux Kernel Mailing List , Bjorn Helgaas , "linux-pci@vger.kernel.org" References: <20210913141818.GA27911@codemonkey.org.uk> From: Heiner Kallweit Subject: Re: Linux 5.15-rc1 Message-ID: <18e101d9-f94c-1122-1436-dc3069429710@gmail.com> Date: Mon, 13 Sep 2021 22:11:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13.09.2021 21:51, Linus Torvalds wrote: > On Mon, Sep 13, 2021 at 12:00 PM Heiner Kallweit wrote: >> >> With an older kernel you may experience the stall when accessing the vpd >> attribute of this device in sysfs. > > Honestly, that old behavior seems to be the *much* better behavior. > > A synchronous stall at boot time is truly annoying, and a pain to deal > with (and debug). > > That pci_vpd_read() function is clearly NOT designed to deal with > boot-time callers in the first place, so I think that commit is simply > wrong. > > And yes, I see that "128ms timeout". If it was _one_ timeout, that > would be one thing,. But it looks like it's repeated over and over. > No. The timeout is not the issue, otherwise you would see the message "VPD access failed.." over and over again. The issue here seems to be that this call in PCI config space access to adress vpd->cap + PCI_VPD_ADDR stalls. In a first place this seems to be due to a buggy device. We'll know for sure once Dave checks with the test patch applied. To deal with such buggy devices we have the VPD blacklist quirk. Secondly you could blame the PCI subsystem for not detecting stalled access to a buggy device. However I don't know the PCIe spec good enough to really comment on this. > Not acceptable at boot time. Not at all. > > Bjorn. Please revert. Or I can do it. > > Linus > Heiner