On Mon, Apr 18, 2022 at 06:36:05PM -0700, Bao D. Nguyen wrote: > Increase the UIC command timeout to avoid false and unnecessary > UFS errors printout. There are increasing number of false UIC command > timeout error events where the actual cause of the issues is interrupt > starvation. When looking into these issues closely, it was clear that > the UIC command completed successfully, but the CPUs were hogged by other > subsystems for more than 500ms, causing a false UIC command timeout. > UFS irq handler is a hardirq. Not sure how CPU starving can happen here. Unless all CPUs are occupied by hardirq handlers from other subsystems. Thanks, Mani > Increase the UIC command timeout to 5 seconds to avoid false and > time consuming support calls so that we can shift the focus to where > the real issue would be. > > Signed-off-by: Bao D. Nguyen <quic_nguyenb@xxxxxxxxxxx> > --- > drivers/scsi/ufs/ufshcd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > index 3f9caaf..806acf4 100644 > --- a/drivers/scsi/ufs/ufshcd.c > +++ b/drivers/scsi/ufs/ufshcd.c > @@ -35,7 +35,7 @@ > UTP_TASK_REQ_COMPL |\ > UFSHCD_ERROR_MASK) > /* UIC command timeout, unit: ms */ > -#define UIC_CMD_TIMEOUT 500 > +#define UIC_CMD_TIMEOUT 5000 > > /* NOP OUT retries waiting for NOP IN response */ > #define NOP_OUT_RETRIES 10 > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
