Received: by 10.223.185.116 with SMTP id b49csp6791459wrg; Wed, 28 Feb 2018 15:56:13 -0800 (PST) X-Google-Smtp-Source: AH8x225GUpg+AR76Qwjqc8iSG3N8zMSo2S0fZ3//p4Yw+lZrtVBiUclhGI4tHHDtPmg9h5R4lkf6 X-Received: by 10.99.64.69 with SMTP id n66mr14882458pga.300.1519862173619; Wed, 28 Feb 2018 15:56:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519862173; cv=none; d=google.com; s=arc-20160816; b=Vksc3yYeXWoB6ddKWtC3Pdice6XlHDXouZVzx2/vzjptiCtvacFBsOg3anbeDXv2pf JSS6rURl83lroZoUzS95ym2C+I5fNBa2sWw+24cRjMiW1AWN5pbRYb1AOQpfp2tv+hkX lHUo7NUWZm1ClNWCem1xhxGKZSPlr4ZUH2Hm6Id39r2+xBaciuptCiuTi9LGU8eIdCbz Vv6pY70NZnTFOH5vQ+8Pen+UzssV0b3mnoeo8O58sfJ53rPJ6U6VivDx7wrFWjJ1T8/d 8ZzVdHybbpjGibgzg7U0+jN2P8e0comsg7iiuMfXCwcCF4jTv/TdhSb4iSnAWai58xEU gZvw== 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:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=tMRX+s0kEI5bEEqffaovRdOJ2Jo4yv+WuD188gF1AZo=; b=ZcXlflkWNTADJ9yMFdI+4dSmcUL+fR72Uy6vhkMc2+fSP2w8N69EAysvCKXlot/6B+ /LvccKl8LdkVnJncngFsaS/bklKkx8Za1Eq+RAtDEqH0M75kVeZ2MynqCO/1g5oSoU4A 1Yi4SSR5hWe7I5OoJOm0fIo6/b/G9bOXS/vjCRcC6Z6A3EvwZUpg7uLcMn0cx5opk/Me AsCWOfTb+XARvNHdLKOCCj+RS17qiMxwk/86t7gWS5ZVOrPF3u4iyvCQTlvhzAC1xFHo iPMp4/rhfFwH5mBUGcSn8FeraeY5vYiJ4vTDGMR+IdX0otu8VozXdKbmsrUfbD2koxYx d/6g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z79si1820504pfl.211.2018.02.28.15.55.58; Wed, 28 Feb 2018 15:56:13 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965168AbeB1XzR (ORCPT + 99 others); Wed, 28 Feb 2018 18:55:17 -0500 Received: from mga17.intel.com ([192.55.52.151]:9581 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964824AbeB1XzQ (ORCPT ); Wed, 28 Feb 2018 18:55:16 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2018 15:55:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,406,1515484800"; d="scan'208";a="20977845" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga007.fm.intel.com with ESMTP; 28 Feb 2018 15:55:15 -0800 Date: Wed, 28 Feb 2018 16:55:37 -0700 From: Keith Busch To: wenxiong Cc: linux-nvme@lists.infradead.org, axboe@fb.com, linux-kernel@vger.kernel.org, wenxiong@us.ibm.com Subject: Re: [PATCH V3] nvme-pci: Fixes EEH failure on ppc Message-ID: <20180228235537.GK16002@localhost.localdomain> References: <1518725110-25894-1-git-send-email-wenxiong@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 28, 2018 at 04:31:37PM -0600, wenxiong wrote: > On 2018-02-15 14:05, wenxiong@linux.vnet.ibm.com wrote: > > From: Wen Xiong > > > > With b2a0eb1a0ac72869c910a79d935a0b049ec78ad9(nvme-pci: Remove watchdog > > timer), EEH recovery stops working on ppc. > > > > After removing whatdog timer routine, when trigger EEH on ppc, we hit > > EEH in nvme_timeout(). We would like to check if pci channel is offline > > or not at the beginning of nvme_timeout(), if it is already offline, > > we don't need to do future nvme timeout process. > > > > Add mrmory barrier before calling pci_channel_offline(). > > > > With the patch, EEH recovery works successfuly on ppc. > > > > Signed-off-by: Wen Xiong > > Hi Keith and All, > > We have the newer Linux distro releases came out recently, so I got more > reports for this issue. > > Test teams have verified the patch in several distro kernel version(v4.14, > v4.15). > > > If you have any question about the V3 patch I submitted two weeks, Let me > know. Sorry, I'd nearly forgotten about this one. We need a better change log. Could you help explain how this really works? As I understand it, I would write it something like this, but let me know if there's more to it: Triggering PPC EEH detection and handling requires a memory mapped read failure. The NVMe driver removed the periodic health check MMIO, so there's no early detection mechanism to trigger the recovery. Instead, the detection happens when the nvme driver handles an IO timeout event. Since this takes the pci channel offline, we do not want the driver to proceed with escalating its own recovery efforts that may conflict with the EEH handler. This patch ensures the driver will observe the channel was set to offline after a failed MMIO read and resets the IO timer so the EEH handler has a chance to recover the device.