From: Bjorn Helgaas <helgaas@kernel.org>
To: Arun Easi <aeasi@marvell.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, Girish Basrur <GBasrur@marvell.com>,
Quinn Tran <qutran@marvell.com>
Subject: Re: [PATCH 1/1] PCI/VPD: Fix blocking of VPD data in lspci for QLogic 1077:2261
Date: Thu, 8 Apr 2021 12:27:47 -0500 [thread overview]
Message-ID: <20210408172747.GA1940414@bjorn-Precision-5520> (raw)
In-Reply-To: <alpine.LRH.2.21.9999.2104071535110.13940@irv1user01.caveonetworks.com>
On Wed, Apr 07, 2021 at 03:57:32PM -0700, Arun Easi wrote:
> On Wed, 7 Apr 2021, 3:13pm, Bjorn Helgaas wrote:
>
> > On Wed, Mar 03, 2021 at 02:42:50PM -0800, Arun Easi wrote:
> > > "lspci -vvv" for Qlogic Fibre Channel HBA 1077:2261 displays
> > > "Vital Product Data" as "Not readable" today and thus preventing
> > > customers from getting relevant HBA information. Fix it by removing
> > > the blacklist quirk.
> > >
> > > The VPD quirk was added by [0] to avoid a system NMI; this issue has
> > > been long fixed in the HBA firmware. In addition, PCI also has changes
> > > to check the VPD size [1], so this quirk can be reverted now regardless
> > > of a firmware update.
> >
> > This is not a very convincing argument yet since 104daa71b396 ("PCI:
> > Determine actual VPD size on first access") appeared in v4.6 and
> > 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") appeared
> > in v4.11.
> >
> > If 104daa71b396 really fixed the problem, why did we need
> > 0d5370d1d852?
>
> True, 0d5370d1d852 was not really neeeded for 104daa71b396 and newer
> kernels; my theory is that when Ethan Z. ran the tests, he was using an
> older (older than 104daa71b396) kernel, but by the time the blacklisting
> was put in place, the kernel already had the fix that made the
> blacklisting unnecessary.
>
> More of my investigation details explained here:
> https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2012161641230.28924@irv1user01.caveonetworks.com/
>
> A quick summary of which is that, when Ethan reported the crash stack, it
> had pci_vpd_pci22* calls which is seen only in older kernels. Though
> 104daa71b396 too had those calls, it was very close to the commit that
> renamed those calls (f1cd93f9aabe) -- and I theorized Ethan probably was
> not running a kernel between 104daa71b396 and f1cd93f9aabe (only 3
> commits (drivers/pci/) away).
We should put the outline of this theory in the commit log for the
benefit of future readers who have the same question I did.
Bjorn
next prev parent reply other threads:[~2021-04-08 17:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 22:42 [PATCH 0/1] PCI/VPD: Fix blocking of VPD data in lspci for QLogic 1077:2261 Arun Easi
2021-03-03 22:42 ` [PATCH 1/1] " Arun Easi
2021-03-06 23:57 ` Krzysztof Wilczyński
2021-04-07 22:13 ` Bjorn Helgaas
2021-04-07 22:57 ` Arun Easi
2021-04-08 17:27 ` Bjorn Helgaas [this message]
2021-04-09 19:58 ` [EXT] " Arun Easi
2021-03-24 20:04 ` [PATCH 0/1] " Arun Easi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210408172747.GA1940414@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=GBasrur@marvell.com \
--cc=aeasi@marvell.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=qutran@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox