From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1074BC28CC0 for ; Thu, 30 May 2019 20:58:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D7B5026197 for ; Thu, 30 May 2019 20:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559249907; bh=RzysyGPyd/1YfGrfUAerdAkUBe+i+zzpSKAftG8O6q4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=scGNQ9ZerPmvMehzJTFMvqyUQ9WxMt2eshDrj7DEmCIlSB5nPBwmrvTdTX5MDyaJG FbwR3B4H78OrNKARxLdyA/LkqqL0y3HOJc027OJ9eGBeYHwevyCXT7ezQ0yVXCjXOA aSJraRycT0LoUKD+Fl8x8fCmTHM6q2Ovgxvbi3ts= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726430AbfE3U60 (ORCPT ); Thu, 30 May 2019 16:58:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:36060 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726125AbfE3U60 (ORCPT ); Thu, 30 May 2019 16:58:26 -0400 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 B06D526197; Thu, 30 May 2019 20:58:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559249906; bh=RzysyGPyd/1YfGrfUAerdAkUBe+i+zzpSKAftG8O6q4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kj+YxR0PJOduRngkGNK3NVnrXL+3fjj0Twq+mHpZ8YnphK3kahYWsfVtl2Ac2Ozi3 9ywGdtXK4eqjk3jhGVVwxONwO+OMq1nms6trKDSwUXataFp0iQ6kkV1ErsXM9OkjnI QrRU0Kh+8BQvHzqdY8mbuZEbwnl7ILpxn20AWMNY= Date: Thu, 30 May 2019 15:58:23 -0500 From: Bjorn Helgaas To: Himanshu Madhani Cc: Andrew Vasquez , Girish Basrur , Giridhar Malavali , Myron Stowe , Linux Kernel Mailing List , Quinn Tran , Linux PCI Subject: Re: [EXT] VPD access Blocked by commit 0d5370d1d85251e5893ab7c90a429464de2e140b Message-ID: <20190530205823.GA45696@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, May 30, 2019 at 07:33:01PM +0000, Himanshu Madhani wrote: > We are able to successfully read VPD config data using lspci and cat > command Yes, you mentioned that in the very first email. I was hoping you would include the actual data, e.g., "cat vpd | xxd". That would help us figure out why you don't see the panic any more. I suspect either: - new QLogic firmware fixed the structure of the VPD data so Linux no longer attempts to read past the end of the implemented region, or, - we still read past the end of the implemented VPD region, but the device doesn't report an error or the platform deals with the error without causing a panic. > We also verified this same configuration on a SuperMicro X10SRA-F > server (which i had sent in earlier email)’ and were able to verify > that the VPD read was good and there were no errors on PCIe trace. Since you saw no PCIe errors here, this suggests that new firmware has changed the format of the VPD data. > Given this information, Please consider reverting the patch until we > further debug the issue and resolve as it is affecting general > availability of our adapter. 1) The way Linux works is that you would post a patch that does the revert you'd like to see done. 2) It's unlikely that a simple revert of 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") is the right answer because that would make Ethan's machine panic again. It's possible that a QLogic firmware update would avoid the panic, but we can't simply revert the patch and force users to do that update. If a QLogic firmware update indeed fixed the VPD format, I suggest that you ask the folks responsible for the firmware to identify the specific version where that was fixed and how the OS can figure that out. Then you could make a new quirk specific to this device that allows VPD reads if the adapter has new enough firmware. If it finds older firmware, it could even print a message suggesting that users could update the firmware if they need to read VPD data. Bjorn