On 5/24/21 1:36 AM, Can Guo wrote: > 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? Thanks, Bart.
