Kernel bug on power key press #2
Comments
Could you please describe the problem in detail? It means that there is on response when your power key is press or other condition. |
|
Hi, correct. Anytime I press the power key on the device, the above bug is triggered in the kernel and I see it in dmesg. |
I can't confirm the specific problems from above dmesg directly, is there a corresponding event response when the power key is pressed? Like the following event log: |
|
Sorry, you're right, should have included that... One example: Another example: |
|
It seems that the devicetree codes are not synchronized fully. Maybe you can check the devicetree codes in path "arch/arm64/boot/dts/vendor/qcom". |
Thanks, I just checked and the entire repo is synchronized. I'm also using the stock dtbo partition with my kernel. |
|
Hi @YuHuang65, to put more context around it, the exact same issue is on fully stock kernel. |
|
I'm sorry it took so long to reply, could you please what's your problem on your phone now. I need to know the actual problem phenomenon to confirm which module get the problem on your phone. |
Thanks, I just feel like on a production kernel this shouldn't happen. But like you say, it's there on stock and and I don't see any symptoms other than this warning being triggered in the kernel. |
anayw2001
pushed a commit
to anayw2001/android_kernel_oneplus_sm8350
that referenced
this issue
Jun 10, 2021
I don't think kthreads are supposed to be IRQ safe but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
lineageos-gerrit
pushed a commit
to LineageOS/android_kernel_oneplus_sm8350
that referenced
this issue
Sep 22, 2021
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
SnowCore8
pushed a commit
to SnowCore8/android_kernel_oneplus9pro_sm8350
that referenced
this issue
Oct 20, 2021
This patch implements deduplication feature in zram. The purpose of this work is naturally to save amount of memory usage by zram. Android is one of the biggest users to use zram as swap and it's really important to save amount of memory usage. There is a paper that reports that duplication ratio of Android's memory content is rather high [1]. And, there is a similar work on zswap that also reports that experiments has shown that around 10-15% of pages stored in zswp are duplicates and deduplicate them provides some benefits [2]. Also, there is a different kind of workload that uses zram as blockdev and store build outputs into it to reduce wear-out problem of real blockdev. In this workload, deduplication hit is very high due to temporary files and intermediate object files. Detailed analysis is on the bottom of this description. Anyway, if we can detect duplicated content and avoid to store duplicated content at different memory space, we can save memory. This patch tries to do that. Implementation is almost simple and intuitive but I should note one thing about implementation detail. To check duplication, this patch uses checksum of the page and collision of this checksum could be possible. There would be many choices to handle this situation but this patch chooses to allow entry with duplicated checksum to be added to the hash, but, not to compare all entries with duplicated checksum when checking duplication. I guess that checksum collision is quite rare event and we don't need to pay any attention to such a case. Therefore, I decided the most simplest way to implement the feature. If there is a different opinion, I can accept and go that way. Following is the result of this patch. Test result #1 (Swap): Android Marshmallow, emulator, x86_64, Backporting to kernel v3.18 orig_data_size: 145297408 compr_data_size: 32408125 mem_used_total: 32276480 dup_data_size: 3188134 meta_data_size: 1444272 Last two metrics added to mm_stat are related to this work. First one, dup_data_size, is amount of saved memory by avoiding to store duplicated page. Later one, meta_data_size, is the amount of data structure to support deduplication. If dup > meta, we can judge that the patch improves memory usage. In Adnroid, we can save 5% of memory usage by this work. Test result OnePlusOSS#2 (Blockdev): build the kernel and store output to ext4 FS on zram <no-dedup> Elapsed time: 249 s mm_stat: 430845952 191014886 196898816 0 196898816 28320 0 0 0 <dedup> Elapsed time: 250 s mm_stat: 430505984 190971334 148365312 0 148365312 28404 0 47287038 3945792 There is no performance degradation and save 23% memory. Test result OnePlusOSS#3 (Blockdev): copy android build output dir(out/host) to ext4 FS on zram <no-dedup> Elapsed time: out/host: 88 s mm_stat: 8834420736 3658184579 3834208256 0 3834208256 32889 0 0 0 <dedup> Elapsed time: out/host: 100 s mm_stat: 8832929792 3657329322 2832015360 0 2832015360 32609 0 952568877 80880336 It shows performance degradation roughly 13% and save 24% memory. Maybe, it is due to overhead of calculating checksum and comparison. Test result OnePlusOSS#4 (Blockdev): copy android build output dir(out/target/common) to ext4 FS on zram <no-dedup> Elapsed time: out/host: 203 s mm_stat: 4041678848 2310355010 2346577920 0 2346582016 500 4 0 0 <dedup> Elapsed time: out/host: 201 s mm_stat: 4041666560 2310488276 1338150912 0 1338150912 476 0 989088794 24564336 Memory is saved by 42% and performance is the same. Even if there is overhead of calculating checksum and comparison, large hit ratio compensate it since hit leads to less compression attempt. I checked the detailed reason of savings on kernel build workload and there are some cases that deduplication happens. 1) *.cmd Build command is usually similar in one directory so content of these file are very similar. In my system, more than 789 lines in fs/ext4/.namei.o.cmd and fs/ext4/.inode.o.cmd are the same in 944 and 938 lines of the file, respectively. 2) intermediate object files built-in.o and temporary object file have the similar contents. More than 50% of fs/ext4/ext4.o is the same with fs/ext4/built-in.o. 3) vmlinux .tmp_vmlinux1 and .tmp_vmlinux2 and arch/x86/boo/compressed/vmlinux.bin have the similar contents. Android test has similar case that some of object files(.class and .so) are similar with another ones. (./host/linux-x86/lib/libartd.so and ./host/linux-x86-lib/libartd-comiler.so) Anyway, benefit seems to be largely dependent on the workload so following patch will make this feature optional. However, this feature can help some usecases so is deserved to be merged. [1]: MemScope: Analyzing Memory Duplication on Android Systems, dl.acm.org/citation.cfm?id=2797023 [2]: zswap: Optimize compressed pool memory utilization, lkml.kernel.org/r/1341407574.7551.1471584870761.JavaMail.weblogic@epwas3p2 Change-Id: I8fe80c956c33f88a6af337d50d9e210e5c35ce37 Reviewed-by: Sergey Senozhatsky <[email protected]> Acked-by: Minchan Kim <[email protected]> Signed-off-by: Joonsoo Kim <[email protected]> Link: https://lore.kernel.org/patchwork/patch/787162/ Patch-mainline: linux-kernel@ Thu, 11 May 2017 22:30:26 Signed-off-by: Charan Teja Reddy <[email protected]> Signed-off-by: Park Ju Hyung <[email protected]>
SnowCore8
pushed a commit
to SnowCore8/android_kernel_oneplus9pro_sm8350
that referenced
this issue
Nov 23, 2021
This patch implements deduplication feature in zram. The purpose of this work is naturally to save amount of memory usage by zram. Android is one of the biggest users to use zram as swap and it's really important to save amount of memory usage. There is a paper that reports that duplication ratio of Android's memory content is rather high [1]. And, there is a similar work on zswap that also reports that experiments has shown that around 10-15% of pages stored in zswp are duplicates and deduplicate them provides some benefits [2]. Also, there is a different kind of workload that uses zram as blockdev and store build outputs into it to reduce wear-out problem of real blockdev. In this workload, deduplication hit is very high due to temporary files and intermediate object files. Detailed analysis is on the bottom of this description. Anyway, if we can detect duplicated content and avoid to store duplicated content at different memory space, we can save memory. This patch tries to do that. Implementation is almost simple and intuitive but I should note one thing about implementation detail. To check duplication, this patch uses checksum of the page and collision of this checksum could be possible. There would be many choices to handle this situation but this patch chooses to allow entry with duplicated checksum to be added to the hash, but, not to compare all entries with duplicated checksum when checking duplication. I guess that checksum collision is quite rare event and we don't need to pay any attention to such a case. Therefore, I decided the most simplest way to implement the feature. If there is a different opinion, I can accept and go that way. Following is the result of this patch. Test result #1 (Swap): Android Marshmallow, emulator, x86_64, Backporting to kernel v3.18 orig_data_size: 145297408 compr_data_size: 32408125 mem_used_total: 32276480 dup_data_size: 3188134 meta_data_size: 1444272 Last two metrics added to mm_stat are related to this work. First one, dup_data_size, is amount of saved memory by avoiding to store duplicated page. Later one, meta_data_size, is the amount of data structure to support deduplication. If dup > meta, we can judge that the patch improves memory usage. In Adnroid, we can save 5% of memory usage by this work. Test result OnePlusOSS#2 (Blockdev): build the kernel and store output to ext4 FS on zram <no-dedup> Elapsed time: 249 s mm_stat: 430845952 191014886 196898816 0 196898816 28320 0 0 0 <dedup> Elapsed time: 250 s mm_stat: 430505984 190971334 148365312 0 148365312 28404 0 47287038 3945792 There is no performance degradation and save 23% memory. Test result OnePlusOSS#3 (Blockdev): copy android build output dir(out/host) to ext4 FS on zram <no-dedup> Elapsed time: out/host: 88 s mm_stat: 8834420736 3658184579 3834208256 0 3834208256 32889 0 0 0 <dedup> Elapsed time: out/host: 100 s mm_stat: 8832929792 3657329322 2832015360 0 2832015360 32609 0 952568877 80880336 It shows performance degradation roughly 13% and save 24% memory. Maybe, it is due to overhead of calculating checksum and comparison. Test result OnePlusOSS#4 (Blockdev): copy android build output dir(out/target/common) to ext4 FS on zram <no-dedup> Elapsed time: out/host: 203 s mm_stat: 4041678848 2310355010 2346577920 0 2346582016 500 4 0 0 <dedup> Elapsed time: out/host: 201 s mm_stat: 4041666560 2310488276 1338150912 0 1338150912 476 0 989088794 24564336 Memory is saved by 42% and performance is the same. Even if there is overhead of calculating checksum and comparison, large hit ratio compensate it since hit leads to less compression attempt. I checked the detailed reason of savings on kernel build workload and there are some cases that deduplication happens. 1) *.cmd Build command is usually similar in one directory so content of these file are very similar. In my system, more than 789 lines in fs/ext4/.namei.o.cmd and fs/ext4/.inode.o.cmd are the same in 944 and 938 lines of the file, respectively. 2) intermediate object files built-in.o and temporary object file have the similar contents. More than 50% of fs/ext4/ext4.o is the same with fs/ext4/built-in.o. 3) vmlinux .tmp_vmlinux1 and .tmp_vmlinux2 and arch/x86/boo/compressed/vmlinux.bin have the similar contents. Android test has similar case that some of object files(.class and .so) are similar with another ones. (./host/linux-x86/lib/libartd.so and ./host/linux-x86-lib/libartd-comiler.so) Anyway, benefit seems to be largely dependent on the workload so following patch will make this feature optional. However, this feature can help some usecases so is deserved to be merged. [1]: MemScope: Analyzing Memory Duplication on Android Systems, dl.acm.org/citation.cfm?id=2797023 [2]: zswap: Optimize compressed pool memory utilization, lkml.kernel.org/r/1341407574.7551.1471584870761.JavaMail.weblogic@epwas3p2 Change-Id: I8fe80c956c33f88a6af337d50d9e210e5c35ce37 Reviewed-by: Sergey Senozhatsky <[email protected]> Acked-by: Minchan Kim <[email protected]> Signed-off-by: Joonsoo Kim <[email protected]> Link: https://lore.kernel.org/patchwork/patch/787162/ Patch-mainline: linux-kernel@ Thu, 11 May 2017 22:30:26 Signed-off-by: Charan Teja Reddy <[email protected]> Signed-off-by: Park Ju Hyung <[email protected]>
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Mar 1, 2022
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Mar 4, 2022
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Mar 4, 2022
…ePlus Nord N200 Oxygen 11.0.2.0.DE17AA Change-Id: I5b330bd462725059b55db81268b91d274445af83 techpack: oneplus: Remove unnecessary debug info from pstore Fails compilation on some environments + we don't need it. Change-Id: Ib348bac230ae30b85de633ba58dfa7e9ce9f9254 disp: msm: sde: Rework PLANE_PROP_ALPHA handling * matches with our z-order fix Co-authored-by: alk3pInjection <[email protected]> Signed-off-by: alk3pInjection <[email protected]> Change-Id: Ic65ac6dc5489980ed9e2aebc4965b17886de6030 disp: msm: sde: Refactor fod dimming * Check oneplus_dimlayer_hbm_enable instead of fp_index to activate fod dimming mode. Co-authored-by: alk3pInjection <[email protected]> Signed-off-by: alk3pInjection <[email protected]> Change-Id: I8cd87ccab8e8dbbd0653ddbeadb5d8bafb72cd71 input: qpnp-power-on: Fix WARN_ON() after pressing the power button Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8 techpack: oplus_chg: Fix function prototype related warning Change-Id: I7b9107c9fd771b0c478fe0158e04327976f7476b
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Mar 4, 2022
…ePlus Nord N200 Oxygen 11.0.2.0.DE17AA Change-Id: I5b330bd462725059b55db81268b91d274445af83 techpack: oneplus: Remove unnecessary debug info from pstore Fails compilation on some environments + we don't need it. Change-Id: Ib348bac230ae30b85de633ba58dfa7e9ce9f9254 disp: msm: sde: Rework PLANE_PROP_ALPHA handling * matches with our z-order fix Co-authored-by: alk3pInjection <[email protected]> Signed-off-by: alk3pInjection <[email protected]> Change-Id: Ic65ac6dc5489980ed9e2aebc4965b17886de6030 disp: msm: sde: Refactor fod dimming * Check oneplus_dimlayer_hbm_enable instead of fp_index to activate fod dimming mode. Co-authored-by: alk3pInjection <[email protected]> Signed-off-by: alk3pInjection <[email protected]> Change-Id: I8cd87ccab8e8dbbd0653ddbeadb5d8bafb72cd71 input: qpnp-power-on: Fix WARN_ON() after pressing the power button Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8 techpack: oplus_chg: Fix function prototype related warning Change-Id: I7b9107c9fd771b0c478fe0158e04327976f7476b
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Apr 14, 2022
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Apr 16, 2022
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Jun 18, 2022
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Jun 18, 2022
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Jun 18, 2022
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
elginsk8r
pushed a commit
to elginsk8r/android_kernel_oneplus_sm4350
that referenced
this issue
Jun 30, 2022
Maybe kthreads aren't supposed to be IRQ safe, but at the very least this gets rid of warning every time power button is up. Fixes: OnePlusOSS/android_kernel_oneplus_sm8350#2 Change-Id: Ib2030f730d3fc79663a77ae4a2b56a8a08da3ad8
SnowCore8
pushed a commit
to SnowCore8/android_kernel_oneplus9pro_sm8350
that referenced
this issue
Jan 19, 2023
There's a potential deadlock with the following cycle: wfs_lock --> device_links_lock --> kn->count Fix this by simply dropping the lock around a list_empty() check that's just exported to a sysfs file. The sysfs file output is an instantaneous check anyway and the lock doesn't really add any protection. Lockdep log: [ 48.808132] [ 48.808132] the existing dependency chain (in reverse order) is: [ 48.809069] [ 48.809069] -> OnePlusOSS#2 (kn->count){++++}: [ 48.809707] __kernfs_remove.llvm.7860393000964815146+0x2d4/0x460 [ 48.810537] kernfs_remove_by_name_ns+0x54/0x9c [ 48.811171] sysfs_remove_file_ns+0x18/0x24 [ 48.811762] device_del+0x2b8/0x5a8 [ 48.812269] __device_link_del+0x98/0xb8 [ 48.812829] device_links_driver_bound+0x210/0x2d8 [ 48.813496] driver_bound+0x44/0xf8 [ 48.814000] really_probe+0x340/0x6e0 [ 48.814526] driver_probe_device+0xb8/0x100 [ 48.815117] device_driver_attach+0x78/0xb8 [ 48.815708] __driver_attach+0xe0/0x194 [ 48.816255] bus_for_each_dev+0xa8/0x11c [ 48.816816] driver_attach+0x24/0x30 [ 48.817331] bus_add_driver+0x100/0x1e0 [ 48.817880] driver_register+0x78/0x114 [ 48.818427] __platform_driver_register+0x44/0x50 [ 48.819089] 0xffffffdbb3227038 [ 48.819551] do_one_initcall+0xd8/0x1e0 [ 48.820099] do_init_module+0xd8/0x298 [ 48.820636] load_module+0x3afc/0x44c8 [ 48.821173] __arm64_sys_finit_module+0xbc/0xf0 [ 48.821807] el0_svc_common+0xbc/0x1d0 [ 48.822344] el0_svc_handler+0x74/0x98 [ 48.822882] el0_svc+0x8/0xc [ 48.823310] [ 48.823310] -> #1 (device_links_lock){+.+.}: [ 48.824036] __mutex_lock_common+0xe0/0xe44 [ 48.824626] mutex_lock_nested+0x28/0x34 [ 48.825185] device_link_add+0xd4/0x4ec [ 48.825734] of_link_to_suppliers+0x158/0x204 [ 48.826347] of_fwnode_add_links+0x50/0x64 [ 48.826928] device_link_add_missing_supplier_links+0x90/0x11c [ 48.827725] fw_devlink_resume+0x58/0x130 [ 48.828296] of_platform_default_populate_init+0xb4/0xd0 [ 48.829030] do_one_initcall+0xd8/0x1e0 [ 48.829578] do_initcall_level+0xb8/0xcc [ 48.830137] do_basic_setup+0x60/0x7c [ 48.830662] kernel_init_freeable+0x128/0x1ac [ 48.831275] kernel_init+0x18/0x29c [ 48.831781] ret_from_fork+0x10/0x18 [ 48.832297] [ 48.832297] -> #0 (wfs_lock){+.+.}: [ 48.832922] __lock_acquire+0xe04/0x2e20 [ 48.833480] lock_acquire+0xbc/0xec [ 48.833984] __mutex_lock_common+0xe0/0xe44 [ 48.834577] mutex_lock_nested+0x28/0x34 [ 48.835136] waiting_for_supplier_show+0x3c/0x98 [ 48.835781] dev_attr_show+0x48/0xb4 [ 48.836295] sysfs_kf_seq_show+0xe8/0x184 [ 48.836864] kernfs_seq_show+0x48/0x8c [ 48.837401] seq_read+0x1c8/0x600 [ 48.837884] kernfs_fop_read+0x68/0x204 [ 48.838431] __vfs_read+0x60/0x214 [ 48.838925] vfs_read+0xbc/0x15c [ 48.839397] ksys_read+0x78/0xe4 [ 48.839869] __arm64_sys_read+0x1c/0x28 [ 48.840416] el0_svc_common+0xbc/0x1d0 [ 48.840953] el0_svc_handler+0x74/0x98 [ 48.841490] el0_svc+0x8/0xc [ 48.841917] [ 48.841917] other info that might help us debug this: [ 48.841917] [ 48.842920] Chain exists of: [ 48.842920] wfs_lock --> device_links_lock --> kn->count [ 48.842920] [ 48.844152] Possible unsafe locking scenario: [ 48.844152] [ 48.844895] CPU0 CPU1 [ 48.845463] ---- ---- [ 48.846032] lock(kn->count); [ 48.846417] lock(device_links_lock); [ 48.847203] lock(kn->count); [ 48.847902] lock(wfs_lock); [ 48.848276] [ 48.848276] *** DEADLOCK *** Reported-by: [email protected] Signed-off-by: Saravana Kannan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Bug: 171536500 (cherry picked from commit 7008e58c63bc8468e8d16154e25d780198b3ecfc) Change-Id: Icb98a270d6ff07bcc81a2162ac00493fae6fafe6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @YuHuang65, you have been so helpful with the other issue, I wanted to bring to your attention that anytime the power key is pressed, the following is triggered in the kernel:
[12434.277491] [20210504_15:08:27.067097]@0 ------------[ cut here ]------------
[12434.277511] [20210504_15:08:27.067121]@0 WARNING: CPU: 0 PID: 2071 at kernel/time/timer.c:1394 del_timer_sync+0xb8/0xd0
[12434.277520] [20210504_15:08:27.067131]@0 CPU: 0 PID: 2071 Comm: netmgrd Tainted: G S W 5.4.61-Omega #1
[12434.277525] [20210504_15:08:27.067135]@0 Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT)
[12434.277530] [20210504_15:08:27.067141]@0 pstate: 00400085 (nzcv daIf +PAN -UAO)
[12434.277536] [20210504_15:08:27.067147]@0 pc : del_timer_sync+0xb8/0xd0
[12434.277546] [20210504_15:08:27.067157]@0 lr : __kthread_cancel_work_sync+0xe0/0x150
[12434.277550] [20210504_15:08:27.067161]@0 sp : ffffffc010003cf0
[12434.277554] [20210504_15:08:27.067164]@0 x29: ffffffc010003cf0 x28: ffffffd397707018
[12434.277559] [20210504_15:08:27.067170]@0 x27: ffffff81f3d9d800 x26: ffffffd397707018
[12434.277565] [20210504_15:08:27.067176]@0 x25: ffffffd397a79ca8 x24: ffffff81f3166d48
[12434.277570] [20210504_15:08:27.067181]@0 x23: ffffff81f3166dd8 x22: ffffff81f30de584
[12434.277575] [20210504_15:08:27.067186]@0 x21: ffffff81f30de584 x20: ffffff81f3166d70
[12434.277580] [20210504_15:08:27.067191]@0 x19: ffffff81f3166d48 x18: 0000000000080000
[12434.277585] [20210504_15:08:27.067196]@0 x17: 0000000000000000 x16: 0000000000000000
[12434.277591] [20210504_15:08:27.067201]@0 x15: 000000000632ea00 x14: 0000000000000000
[12434.277596] [20210504_15:08:27.067207]@0 x13: 00000000000066eb x12: 0000000000000001
[12434.277601] [20210504_15:08:27.067212]@0 x11: 0000000000000000 x10: 0000000000000000
[12434.277606] [20210504_15:08:27.067217]@0 x9 : 000000000000cddb x8 : 000000000085a4a3
[12434.277612] [20210504_15:08:27.067222]@0 x7 : ffffff81fecbd240 x6 : 0000005c1ee08d27
[12434.277617] [20210504_15:08:27.067228]@0 x5 : ffffff8040ac5c80 x4 : 0000000000000000
[12434.277622] [20210504_15:08:27.067233]@0 x3 : ffffff81f30de584 x2 : 0000000000000000
[12434.277627] [20210504_15:08:27.067238]@0 x1 : ffffff8040ac5c80 x0 : 000000002e000000
[12434.277633] [20210504_15:08:27.067244]@0 Call trace:
[12434.277639] [20210504_15:08:27.067250]@0 del_timer_sync+0xb8/0xd0
[12434.277644] [20210504_15:08:27.067255]@0 __kthread_cancel_work_sync+0xe0/0x150
[12434.277650] [20210504_15:08:27.067260]@0 kthread_cancel_delayed_work_sync+0x10/0x20
[12434.277660] [20210504_15:08:27.067271]@0 qpnp_pon_input_dispatch+0x21c/0x2e0
[12434.277666] [20210504_15:08:27.067276]@0 qpnp_kpdpwr_irq+0x1c/0x50
[12434.277673] [20210504_15:08:27.067284]@0 __handle_irq_event_percpu+0x58/0x2a0
[12434.277678] [20210504_15:08:27.067289]@0 handle_irq_event+0x60/0x130
[12434.277684] [20210504_15:08:27.067295]@0 handle_edge_irq+0xb4/0x210
[12434.277689] [20210504_15:08:27.067300]@0 generic_handle_irq+0x28/0x40
[12434.277698] [20210504_15:08:27.067309]@0 periph_interrupt+0xa8/0x130
[12434.277703] [20210504_15:08:27.067313]@0 pmic_arb_chained_irq+0x140/0x240
[12434.277707] [20210504_15:08:27.067318]@0 __handle_domain_irq+0x74/0xd0
[12434.277714] [20210504_15:08:27.067324]@0 gic_handle_irq+0xc0/0x164
[12434.277720] [20210504_15:08:27.067331]@0 el1_irq+0xf0/0x1c0
[12434.277730] [20210504_15:08:27.067340]@0 _raw_spin_unlock_irq+0x10/0x50
[12434.277737] [20210504_15:08:27.067347]@0 __schedule+0x320/0x860
[12434.277741] [20210504_15:08:27.067352]@0 schedule+0x40/0xe0
[12434.277748] [20210504_15:08:27.067359]@0 __refrigerator+0x44/0xe0
[12434.277755] [20210504_15:08:27.067366]@0 get_signal+0x7c8/0x840
[12434.277763] [20210504_15:08:27.067374]@0 do_notify_resume+0x16c/0x1420
[12434.277768] [20210504_15:08:27.067379]@0 work_pending+0x8/0x10
[12434.277772] [20210504_15:08:27.067383]@0 ---[ end trace 7bbf3fd4650fdb41 ]---
The text was updated successfully, but these errors were encountered: