mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Peter Wang (王信友)" <peter.wang@mediatek.com>
To: "quic_rampraka@quicinc.com" <quic_rampraka@quicinc.com>,
	"quic_nguyenb@quicinc.com" <quic_nguyenb@quicinc.com>,
	"quic_ziqichen@quicinc.com" <quic_ziqichen@quicinc.com>,
	"quic_nitirawa@quicinc.com" <quic_nitirawa@quicinc.com>,
	"beanhuo@micron.com" <beanhuo@micron.com>,
	"avri.altman@wdc.com" <avri.altman@wdc.com>,
	"bvanassche@acm.org" <bvanassche@acm.org>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"junwoo80.lee@samsung.com" <junwoo80.lee@samsung.com>,
	"mani@kernel.org" <mani@kernel.org>,
	"quic_cang@quicinc.com" <quic_cang@quicinc.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	"quic_asutoshd@quicinc.com" <quic_asutoshd@quicinc.com>,
	"quic_mnaresh@quicinc.com" <quic_mnaresh@quicinc.com>,
	"manivannan.sadhasivam@linaro.org"
	<manivannan.sadhasivam@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] scsi: ufs: core: quiesce request queues before check pending cmds
Date: Tue, 25 Jun 2024 03:38:57 +0000	[thread overview]
Message-ID: <ee45ce9429b1f69147c1a01e07b050275b4009bf.camel@mediatek.com> (raw)
In-Reply-To: <b1173b6f-445c-4d6d-9c78-b0351da2893a@acm.org>

On Mon, 2024-06-24 at 09:29 -0700, Bart Van Assche wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 6/24/24 2:56 AM, Ziqi Chen wrote:
> > 1. Why do we need to call blk_mq_quiesce_tagset() into 
> > ufshcd_scsi_block_requests() instead directly replace all 
> > ufshcd_scsi_block_requests() with blk_mq_quiesce_tagset()?
> 
> Because ufshcd_scsi_block_requests() has more callers than the clock
> scaling code and because all callers of ufshcd_scsi_block_requests()
> should be fixed.
> 
> > 2. This patch need to to do long-term stress test, I think many
> OEMs 
> > can't wait as it is a blocker issue for them.
> Patch "scsi: ufs: core: Quiesce request queues before checking
> pending
> cmds" is already in Linus' master branch. I will rebase my patch on
> top
> of linux-next.
> 
> Best regards,
> 
> Bart.

Hi Bart,

But ufshcd_scsi_block_requests usage is correct in SDR mode.
So, I don't think it is ufshcd_scsi_block_requests bug. 
Actually. this bug is triggered by this patch.
8d077ede48c1 ("scsi: ufs: core: scsi: ufs: Optimize the command
queueing code")
Which after ufshcd_scsi_block_requests, ufs cannot make sure ongoing
request 
is all completed by ufshcd_wait_for_doorbell_clr.
That is means, it is ufshcd_wait_for_doorbell_clr bug.

So, I think ufshcd_wait_for_doorbell_clr should be revise.
Check tr_doorbell in SDR mode. (before 8d077ede48c1 do) 
Check each HWQ's are all empty in MCQ mode. (need think how to do)
Make sure all requests is complete, and finish this function' job
correctly. 
Or there still have a gap in ufshcd_wait_for_doorbell_clr.
And someday somebody's patch may stepping into it in the future.

Thanks.
Peter




 

  reply	other threads:[~2024-06-25  3:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07 10:06 Ziqi Chen
2024-06-07 12:33 ` Bart Van Assche
2024-06-11 11:02   ` Ziqi Chen
2024-06-11 13:51     ` Bart Van Assche
2024-06-12  6:07       ` Ziqi Chen
2024-06-11 13:54 ` Bart Van Assche
2024-06-20 20:57 ` Bart Van Assche
2024-06-24  9:56   ` Ziqi Chen
2024-06-24 16:29     ` Bart Van Assche
2024-06-25  3:38       ` Peter Wang (王信友) [this message]
2024-06-25 16:13         ` Bart Van Assche
2024-06-26  3:52           ` Peter Wang (王信友)
2024-06-26 13:18           ` Ziqi Chen
2024-06-26 16:33             ` Bart Van Assche

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=ee45ce9429b1f69147c1a01e07b050275b4009bf.camel@mediatek.com \
    --to=peter.wang@mediatek.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=jejb@linux.ibm.com \
    --cc=junwoo80.lee@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=martin.petersen@oracle.com \
    --cc=quic_asutoshd@quicinc.com \
    --cc=quic_cang@quicinc.com \
    --cc=quic_mnaresh@quicinc.com \
    --cc=quic_nguyenb@quicinc.com \
    --cc=quic_nitirawa@quicinc.com \
    --cc=quic_rampraka@quicinc.com \
    --cc=quic_ziqichen@quicinc.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

all inboxes | Powered by JetHome®