On 2021-06-29 06:58, Bart Van Assche wrote:

On 5/24/21 1:36 AM, Can Guo wrote:

quoted

Current UFS IRQ handler is completely wrapped by host lock, and 
because
ufshcd_send_command() is also protected by host lock, when IRQ handler
fires, not only the CPU running the IRQ handler cannot send new 
requests,
the rest CPUs can neither. Move the host lock wrapping the IRQ handler 
into
specific branches, i.e., ufshcd_uic_cmd_compl(), 
ufshcd_check_errors(),
ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to 
further
reduce occpuation of host lock in ufshcd_transfer_req_compl(), host 
lock is
no longer required to call __ufshcd_transfer_req_compl(). As per test, 
the
optimization can bring considerable gain to random read/write 
performance.

Hi Can,

Since this patch has been applied on the AOSP kernel we see 100%
reproducible lockups appearing on multiple test setups. Examples of 
call
traces:

blk_execute_rq()
__scsi_execute()
sd_sync_cache()
sd_suspend_common()
sd_suspend_system()
scsi_bus_suspend()
__device_suspend()

blk_execute_rq()
__scsi_execute()
ufshcd_clear_ua_wlun()
ufshcd_err_handling_unprepare()
ufshcd_err_handler()
process_one_work()

Reverting this patch and the next patch from this series solved the
lockups. Do you prefer to revert this patch or do you perhaps want us 
to
test a potential fix?

Hi Bart,

I am waiting for more infos/logs/dumps on Buganizor to look into it.
With above calltrace snippet, it is hard to figure out what is 
happening.
Besides, we've tested this series before go upstream and we didn't
see such problem.

Thanks,

Can Guo.

Thanks,

Bart.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek