On Fri, 2022-12-02 at 10:32 +1100, Daniil Lunev wrote: > On Thu, Dec 1, 2022 at 4:50 AM Bart Van Assche <bvanassche@xxxxxxx> > wrote: > > > > On 11/30/22 02:17, Adrian Hunter wrote: > > > On 1/11/22 16:24, peter.wang@xxxxxxxxxxxx wrote: > > > > From: Peter Wang <peter.wang@xxxxxxxxxxxx> > > > > > > > > When SSU fail in wlun suspend flow, trigger error handlder and > > > > > > handlder -> handler > > > > > > Why / how does SSU fail? > > > > I'm not sure but the issue that Peter is trying to fix with this > > patch > > may already have been fixed by my patch series "Fix a deadlock in > > the > > UFS driver". > > We observe a similar failure scenario when a device tries to change > power mode (e.g. due to autosuspend) while "purge" is in progress. It > appears that in this case the "pm_only" counter is increased on the > device queue prior to the attempt of entering a runtime suspended > state, but not reduced upon it failing due to the device being busy > with an ongoing purge. That leads to a deadlock of subsequent IO > operations to the device. > > --Daniil Hi Daniil, May I have a question, which dievce you use in this failure scenario? I think it is same issue due to SSU fail, and wlun devcie pm enter error state. So the cunsomer(scsi lu device) is block in suspend state and connot resume to reduce pm_only lead to IO hang. Thanks. BR Peter
