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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, 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 AD456ECE562 for ; Sat, 15 Sep 2018 08:50:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 56A4A21477 for ; Sat, 15 Sep 2018 08:50:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="CbwoTc1x" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56A4A21477 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727218AbeIOOI1 (ORCPT ); Sat, 15 Sep 2018 10:08:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:47238 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726903AbeIOOI1 (ORCPT ); Sat, 15 Sep 2018 10:08:27 -0400 Received: from localhost (unknown [213.57.183.250]) (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 3226B2083A; Sat, 15 Sep 2018 08:50:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1537001414; bh=msys6+725WWbJQVQ+C2ujHae62x8k4yLaXbrSVZangE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CbwoTc1x+N5dTOJOWHye8pf7dgHd4Xw6dY219Rt1SlDUsor8slRtWk8yhb9caCixu dzgOfJhO+gX28hwr1sSkD4FQmXXKAVEq0GH5JHzjSNKcjxWnzX7x/30JqduC+TqniK tmLsd7hxkz/4eM4JCNwqbPm4bXP6dedtNgOPCGII= Date: Sat, 15 Sep 2018 11:50:09 +0300 From: Leon Romanovsky To: Qing Huang Cc: David Miller , andrew@lunn.ch, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, tariqt@mellanox.com Subject: Re: [PATCH] net/mlx4_core: print firmware version during driver loading Message-ID: <20180915085009.GD5257@mtr-leonro.mtl.com> References: <20180914181718.GD3811@lunn.ch> <20180914.141406.2211638662965115243.davem@davemloft.net> <1d4fe3c6-13aa-12a4-8da4-a83374b89fbf@oracle.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LiQwW4YX+w4axhAx" Content-Disposition: inline In-Reply-To: <1d4fe3c6-13aa-12a4-8da4-a83374b89fbf@oracle.com> 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 --LiQwW4YX+w4axhAx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 14, 2018 at 03:36:46PM -0700, Qing Huang wrote: > > > On 9/14/2018 2:14 PM, David Miller wrote: > > From: Qing Huang > > Date: Fri, 14 Sep 2018 11:33:40 -0700 > > > > > On 9/14/2018 11:17 AM, Andrew Lunn wrote: > > > > On Fri, Sep 14, 2018 at 10:15:48AM -0700, Qing Huang wrote: > > > > > The FW version is actually a very crucial piece of information and > > > > > only > > > > > printed once here > > > > > when the driver is loaded. People tend to get confused when switching > > > > > multiple FW files > > > > > back and forth without running separate utility tools, especially at > > > > > customer sites. > > > > > IMHO, this information is very useful and only takes up very little > > > > > log file > > > > > space. :-) > > > > Why not use ethtool -i ? > > > > > > > > $ sudo ethtool -i eth0 > > > > driver: r8169 > > > > version: 2.3LK-NAPI > > > > firmware-version: rtl8168g-2_0.0.1 02/06/13 > > > > > > > > Andrew > > > Sure. You can also use ibstat or ibv_devinfo tool if they are > > > installed. But it's not very > > > convenient in some cases. > > > > > > E.g. > > > A customer upgrades FW on HCAs and encounters issues. During triage, > > > it's much easier > > > to study customer uploaded log files when remotely testing different > > > FW files. > > Not a valid argument. You can print the ethtool output from initramfs > > if necessary for triage. > > > > I still stand by the fact that ethtool is the only fully reliable way > > to obtain this information, the kernel log is not. > > This is more for Infiniband mode which depends more on features and > functionalities For pure infiniband devices you have rdmatool, part of iproute2. [leonro@server-14-015 ~]$ rdma dev 1: mlx5_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455 sys_image_guid 5254:00c0:fe12:3455 > provided in firmware and get much more frequent FW bug fixes than typical > Ethernet > devices. This is not meant to replace other ways of getting the information, > more like > an enhancement for checking log history. > > This can provide valuable information when tracing through system log > history to > discover what happened with a specific HCA drv ver and fw ver combination in > the past. > > Regards, > Qing --LiQwW4YX+w4axhAx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJbnMfBAAoJEORje4g2clins2MP/2ahQ8mb69Zi6lmm5NOnF6Jp pRNzlNSTPzRZ9Fp2MXZYMU1tGny0099pN0kkUalecGjUjyIL5W3VU1kTKyhZJo9B 7mi/e1uTXVkT3dEyqsPhXdaig0C7EWv+pQRz6he2oc3QBhc1uUri7jKofjLG7K+q o6/j7F2nZ0mIK4AzoQZJErFv4bZ7hXzcx48vNRg4jV6LLgKP//9C5KyNrjZ/GyUf YDp3DOQzhbu4EHxQqm7bb08XHKj24SJ0AAaGKIJEcXY1iTrZqmg3LYSOpS0aGLy0 RV7q6uuKbbm7RiHqF+htAAobgoGqYorAep9ePvl2lvAzwnJh39Fcv25Hbrqly5EG fXsCk4SvNROH8RwqLwOQ1j4is08omwVN0LeKGS3y0auIJkdjiTJh6VZMb2/+WKG+ BaL9mzQnl32Spl/uOQPepf4YSwWVHqpzATamZpm/FVsDp4g0dhkzJmTLvErhEfxu b27VRmImB3mnGRhnQ/csRIy4aYlYXr811xbYs+QIFBMnU7Gj8587fAhA7Tpbe03u 7AusoUmICk5Z+CMaVWjLXsDY3BlwxRuSIzKrSWOy3eYEsNvgcn2750IoSrFF8ytD //P2h9BKzUMMwnwlxV6FYne4mTYLLhiD3vAk+eI/Xdsv6TLYr67/e8CL24na83Z+ 1nQgA1BF0TXoZBpShiR0 =dvjv -----END PGP SIGNATURE----- --LiQwW4YX+w4axhAx--