Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1103576ybg; Wed, 29 Jul 2020 06:05:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyyqs194JcjZi79F6l6rxkARl64NsLNTlo4yOy1AXypTTFvjGlAUxgl8zSGibCBkeORQtc X-Received: by 2002:a17:906:12cd:: with SMTP id l13mr23803809ejb.385.1596027901823; Wed, 29 Jul 2020 06:05:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596027901; cv=none; d=google.com; s=arc-20160816; b=OGiSFpJ4dY1VKnTY67CN0yx3SoX1zwVIjATtC6OqzxXgJJAMqda0Xwhuc9U6e68+sk aiQDLZFMaj0htC3ipyDB5n74uKw7EcPvQtqr6d0JxqJ5vKpuk3wPi1rx2NAa7gss4xL8 qo0SCRVheuYr419wMizXdg/JgZuXFtT1WKUU3dkQGZ4KEXaxL7d+8bKFkO/wW7H0xRqb nRXUrF/EKGkMygNRdBhVOZGAhdaZCxLIMU02cU/Ck0lremCVB7gsHL4qAz2ICflbPlPK X6yFQ8tYLsceQcYwYWOv62NIpeZXT1TLeP2r4mLHMt+oGdn4HFbsebAkYejd+VNgOzD0 Lp/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=Z/CQ/FqDlwwW+m2QFj2+c7Hf8xIIhoH/WH49OMnQboM=; b=TdL1lluDhbIfblBrxq7k8ZR3eXLO5nzRIjBeQw2FNnk6fv7J/7vUpsxrz+X047ND0l lIQWo5wundK32OwTSVGinUZXLmgDYB3wzmSOXruyZ+39TyIZf0/5LKKC/zTpeLGUdumF GDB8keaTUOkb9JGghL/mktU67gVkNzLu2remhHBeOM1KFQIC2LaYimZx5QYFX5qAWGcB AyGU3ihW1auk+g1iFl19wtFJxC9jMEI9MK0VTnhsvqDoMuw5fhUCTiVTbrrWumyfPE5g MjRkEDG/uWM9i3+lPIOhnC0TvZuGrHqb1OmvVHafWTNTEn65UL3Rs1yWidGoMjOWsG3k ZG3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b="p/lgZmoX"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ci17si802459ejb.743.2020.07.29.06.04.29; Wed, 29 Jul 2020 06:05:01 -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=fail header.i=@mg.codeaurora.org header.s=smtp header.b="p/lgZmoX"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727037AbgG2NDm (ORCPT + 99 others); Wed, 29 Jul 2020 09:03:42 -0400 Received: from m43-7.mailgun.net ([69.72.43.7]:39759 "EHLO m43-7.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726998AbgG2NDm (ORCPT ); Wed, 29 Jul 2020 09:03:42 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1596027821; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=Z/CQ/FqDlwwW+m2QFj2+c7Hf8xIIhoH/WH49OMnQboM=; b=p/lgZmoX6CdlZp7rTuDS6+OG7UCy9g6TNCQ7BqLuu56rJaOPqS7d2qcqP7h1v5jSi0m2TubN UJbA9WZifpFkG4mDkKPakPn9IlF/iByX4Lzm3sinfjTNMuVfNslWv9GM3PUj8J1DsGFVP3RH u1cfW6fE5uik0w8Y1kTS9yq3ULw= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n13.prod.us-east-1.postgun.com with SMTP id 5f21737236e6de324e9a1945 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Wed, 29 Jul 2020 13:02:42 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 81BB4C433B1; Wed, 29 Jul 2020 13:02:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cang) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5C52FC433C9; Wed, 29 Jul 2020 13:02:40 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 Jul 2020 21:02:40 +0800 From: Can Guo To: "Asutosh Das (asd)" Cc: nguyenb@codeaurora.org, hongwus@codeaurora.org, rnayak@codeaurora.org, sh425.lee@samsung.com, linux-scsi@vger.kernel.org, kernel-team@android.com, saravanak@google.com, salyzyn@google.com, Alim Akhtar , Avri Altman , "James E.J. Bottomley" , "Martin K. Petersen" , Stanley Chu , Bean Huo , Bart Van Assche , open list Subject: Re: [PATCH v7 7/8] scsi: ufs: Move dumps in IRQ handler to error handler In-Reply-To: <7e5e942d-449b-bd52-32da-7f5beed116b7@codeaurora.org> References: <1595912460-8860-1-git-send-email-cang@codeaurora.org> <1595912460-8860-8-git-send-email-cang@codeaurora.org> <7e5e942d-449b-bd52-32da-7f5beed116b7@codeaurora.org> Message-ID: X-Sender: cang@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Asutosh, On 2020-07-29 02:06, Asutosh Das (asd) wrote: > On 7/27/2020 10:00 PM, Can Guo wrote: >> Sometime dumps in IRQ handler are heavy enough to cause system >> stability >> issues, move them to error handler. >> >> Signed-off-by: Can Guo >> --- >> drivers/scsi/ufs/ufshcd.c | 31 +++++++++++++++---------------- >> 1 file changed, 15 insertions(+), 16 deletions(-) >> >> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c >> index c480823..b2bafa3 100644 >> --- a/drivers/scsi/ufs/ufshcd.c >> +++ b/drivers/scsi/ufs/ufshcd.c >> @@ -5682,6 +5682,21 @@ static void ufshcd_err_handler(struct >> work_struct *work) >> UFSHCD_UIC_DL_TCx_REPLAY_ERROR)))) >> needs_reset = true; >> + if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR | >> + UFSHCD_UIC_HIBERN8_MASK)) { >> + bool pr_prdt = !!(hba->saved_err & SYSTEM_BUS_FATAL_ERROR); >> + >> + dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 0x%x\n", >> + __func__, hba->saved_err, hba->saved_uic_err); >> + spin_unlock_irqrestore(hba->host->host_lock, flags); >> + ufshcd_print_host_state(hba); >> + ufshcd_print_pwr_info(hba); >> + ufshcd_print_host_regs(hba); >> + ufshcd_print_tmrs(hba, hba->outstanding_tasks); >> + ufshcd_print_trs(hba, hba->outstanding_reqs, pr_prdt); >> + spin_lock_irqsave(hba->host->host_lock, flags); >> + } >> + >> /* >> * if host reset is required then skip clearing the pending >> * transfers forcefully because they will get cleared during >> @@ -5900,22 +5915,6 @@ static irqreturn_t ufshcd_check_errors(struct >> ufs_hba *hba) >> /* block commands from scsi mid-layer */ >> ufshcd_scsi_block_requests(hba); >> - >> - /* dump controller state before resetting */ >> - if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR)) { >> - bool pr_prdt = !!(hba->saved_err & >> - SYSTEM_BUS_FATAL_ERROR); >> - >> - dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 0x%x\n", >> - __func__, hba->saved_err, >> - hba->saved_uic_err); >> - >> - ufshcd_print_host_regs(hba); >> - ufshcd_print_pwr_info(hba); > How about keep the above prints and move the tmrs and trs to eh? > Sometimes in system instability, the eh may not get a chance to run > even. Still the above prints would provide some clues. Here is the IRQ handler, ufshcd_print_host_regs() is sometime heavy enough to cause stability issues during my fault injection test, since it prints host regs, reg's history, crypto debug infos plus prints from vops_dump. How about just printing host regs and reg history here? Most time, these infos are enough. Thanks, Can Guo. >> - ufshcd_print_tmrs(hba, hba->outstanding_tasks); >> - ufshcd_print_trs(hba, hba->outstanding_reqs, >> - pr_prdt); >> - } >> ufshcd_schedule_eh_work(hba); >> retval |= IRQ_HANDLED; >> } >>