封面图加载中
林渡
copyright_author: thonmin
copyright_author_href: https://blog.csdn.net/thonmin
copyright_info: 此文章版权归thonmin所有，如有转载，请注明来自原作者
copyright_url: https://blog.csdn.net/thonmin/article/details/122627058
0. 问题现象
dmesg_TZ.txt
(3)[71:khungtaskd]INFO: task Binder:2848_9:3784 tgid:2848 blocked for 120s in whitelist
10707 cpu4
Call trace:
__switch_to+0x244/0x460
__schedule+0x590/0xac4
schedule+0x64/0x188
__mutex_lock+0x444/0x998
__mutex_lock_slowpath+0x14/0x20
regulator_lock_dependent+0x6c/0x378
regulator_enable+0x3c/0x84
arm_smmu_power_on+0xa8/0x298 [arm_smmu]
arm_smmu_runtime_resume+0x18/0x24 [arm_smmu]
pm_generic_runtime_resume+0x44/0x80
__rpm_callback+0x18c/0xb34
rpm_resume+0x8e0/0x11ec
__pm_runtime_resume+0x68/0x148
arm_smmu_flush_iotlb_all+0x44/0x13c [arm_smmu]
_iopgtbl_unmap+0xb4/0x110 [msm_kgsl]
kgsl_iopgtbl_unmap+0x3c/0x48 [msm_kgsl]
kgsl_mmu_unmap+0xa4/0x334 [msm_kgsl]
kgsl_unmap_and_put_gpuaddr+0x40/0xdc [msm_kgsl]
kgsl_mem_entry_detach_process+0x80/0x190 [msm_kgsl]
kgsl_mem_entry_destroy+0x58/0x1a0 [msm_kgsl]
kgsl_ioctl_gpuobj_free+0x200/0x294 [msm_kgsl]
kgsl_ioctl_helper+0x114/0x208 [msm_kgsl]
kgsl_ioctl+0x34/0xe0 [msm_kgsl]
__arm64_sys_ioctl+0x170/0x1ec
el0_svc_common+0xd4/0x26c
el0_svc+0x34/0x94
el0_sync_handler+0x88/0xe8
el0_sync+0x1a4/0x1c0
1. 问题分析
明显是等锁
使用tace32在task.dtask窗口中搜索2848_9，后面pid是3784 然后右键->Display Stack Frame显示调用栈
__mutex_lock() 这个函数在等锁
lock=0xFFFFFFD19C343EC8;
lock->owner->counter = 0xFFFFFF8050744D01
说明当前持锁的task是0xFFFFFF8050744D00，最后一位的1是计数
三个方法使用命令查看task:
- B:: Frame /locals /Caller /TASK 0xFFFFFF8050744D00 /MODule
- 在Display Stack Frame窗口的Task:后面输入地址
- 在task.dtask窗口第一列地址栏中找到该地址
task是{% p red, "crtc_commit:160" cpu6 %}，右键看调用栈
Call trace:
__switch_to+0x244/0x460
__schedule+0x590/0xac4
schedule+0x64/0x188
__ww_mutex_lock+0x4a0/0xdb4
__ww_mutex_lock_slowpath+0x18/0x24
ww_mutex_lock+0x4c/0x180
regulator_lock_recursive+0x108/0x5e8
regulator_lock_dependent+0xe4/0x378
regulator_disable+0x3c/0x84
dsi_pwr_enable_vregs+0x130/0x318 [msm_drm]
又是等锁，继续前面的步骤，查看锁
lock=0xFFFFFF800178A0B0
lock->owner->counter ={% p red,0xFFFFFF804DEE8001 %}
task： "vendor.qti.came" cpu6，调用栈：
Call trace:
__switch_to+0x244/0x460
__schedule+0x590/0xac4
schedule+0x64/0x188
__mutex_lock+0x444/0x998
__mutex_lock_slowpath+0x14/0x20
clk_prepare+0xd0/0x250
se_geni_clks_on+0x52c/0x648 [msm_geni_se]
se_geni_resources_on+0xac/0x148 [msm_geni_se]
geni_i2c_runtime_resume+0xd0/0x440 [i2c_msm_geni]
pm_generic_runtime_resume+0x44/0x80
__rpm_callback+0x18c/0xb34
rpm_resume+0x8e0/0x11ec
__pm_runtime_resume+0x68/0x148
geni_i2c_xfer+0xb8/0x1254 [i2c_msm_geni]
__i2c_transfer+0x27c/0x8ec
i2c_transfer+0xd4/0x1d4
regmap_i2c_read+0x58/0x94
_regmap_raw_read+0x250/0x488
_regmap_bus_read+0x44/0xb0
_regmap_read+0xac/0x248
regulator_get_voltage_sel_regmap+0x84/0x148
regulator_get_voltage_rdev+0xa8/0x2b4
等锁，
lock=0xFFFFFFD19C342048
lock->owner->counter ={% p red, 0xFFFFFF8050081341 %}
task："kworker/u16:7" cpu0，调用栈：
Call trace:
__switch_to+0x244/0x460
__schedule+0x590/0xac4
schedule+0x64/0x188
__mutex_lock+0x444/0x998
__mutex_lock_slowpath+0x14/0x20
regulator_lock_dependent+0x6c/0x378
regulator_set_voltage+0x44/0xa0
clk_aggregate_vdd+0xd8/0x1c0 [clk_qcom]
clk_unvote_vdd_level+0x88/0x238 [clk_qcom]
clk_unprepare_regmap+0x20/0x2c [clk_qcom]
clk_core_unprepare+0x94/0x2b0
clk_core_unprepare+0xb4/0x2b0
clk_unprepare+0x118/0x248
clk_bulk_unprepare+0x30/0x4c
gen7_gmu_power_off+0x288/0x334 [msm_kgsl]
gen7_power_off+0xac/0x37c [msm_kgsl]
等锁:
lock=0xFFFFFFD19C343EC8
lock->owner->counter ={% p red, 0xFFFFFF8050744D01 %}
task:"crtc_commit:160" cpu0
嗯？这个不是死机进程所等的锁么，3方死锁了。
2848_9 --等待-->crtc_commit:160 --等待-->vendor.qti.came--等待-->kworker/u16:7--等待>crtc_commit:160
至于怎么解决嘛~ 我不知道，[手动滑稽]