Desktop Freeze on UNIS D3812 D2000
https://pms.uniontech.com/bug-view-234167.html
UNIS D3812 D2000 系统资源占用过多，存在影院崩溃的情况。
桌面可以显示，但是右下角时间不动。
鼠标可以移动，键盘灯常亮，按键无响应。
新插入别的usb设备，也无法响应。
拔掉键盘再插入，键盘灯常亮，按键无响应。
拔掉鼠标后再插入，拖动鼠标无响应。
初步分析
后台一直跑着自制的性能监测小工具，发现系统并没有死掉，但是桌面卡住了。截取部分top日志：
1 sed -n '801165,802645' p top_20231218181114.log > top_20231219224132.log
内核版本：
1 2023-12-18 17:56:54 username kernel: [ 0.000000] Linux version 4.19.0-arm64-desktop (uosserver@uosserver-PC) (gcc version 8.3.0 (Uos 8.3.0.3-3+rebuild)) (74123f25fea1)
将桌面卡主附近的kern.log中oops相关日志导出到oops_gfx.log中：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 3753 2023-12-19 22:41:36 hbyc-PC kernel: [102629.596004] Modules linked in : bnep vfs_monitor(O) udl nfnetlink_queue nfnetlink_log nfnetlink fuse st bluetooth ecdh_generic rfkill cpufreq_powersave nls_iso8859_1 nls _cp437 aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce aes_arm64 sha2_ce sha256_arm64 ppdev hid_generic serio_raw sha1_ce parport_serial parport_pc parport at24 scpi_hwmon uos_resources(O) u os_bluetooth_connection_control(O) lightorange lightnut lightfig lightcherry filearmor(O) smc_dri(O) binder_linux(O) ashmem_linux(O) efivarfs ip_tables x_tables usbkbd amdgpu usbhid chash gpu_sched radeon phy tium_sdci mmc_core motorcommcut here ]------------in : bnep vfs_monitor(O) udl nfnetlink_queue nfnetlink_log nfnetlink fuse st bluetooth ecdh_generic rfkill cpufreq_powersave nls_iso8859_1 nls _cp437 aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce aes_arm64 sha2_ce sha256_arm64 ppdev hid_generic serio_raw sha1_ce parport_serial parport_pc parport at24 scpi_hwmon uos_resources(O) u os_bluetooth_connection_control(O) lightorange lightnut lightfig lightcherry filearmor(O) smc_dri(O) binder_linux(O) ashmem_linux(O) efivarfs ip_tables x_tables usbkbd amdgpu usbhid chash gpu_sched radeon phy tium_sdci mmc_core motorcommlimit = 0x000000006119d7ac)timeout , signaled seq =27126054, emitted seq =27126054
1 2 3 4 5 6 7 8 9 modinfo gpu_sched
1 2 3 vim drivers/gpu/drm/scheduler/Makefile +25
1 2 grep CONFIG_DRM_SCHED .config
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 ~/code/arm-kernel/scripts/faddr2line gpu-sched.ko drm_sched_main+0x44c/0x4b0wait before queueinglocal CPU.return queue_delayed_work_on(WORK_CPU_UNBOUND, wq, dwork, delay); // WORK_CPU_UNBOUND 表示不绑定到特定 CPUin global workqueue after delaydone wait or 0 for immediate executionfor a given time this puts a job in the kernel-globalreturn queue_delayed_work(system_wq, dwork, delay); sched = s_job->sched ;sched ->job_list_lock);sched ->ring_mirror_list);if (sched ->timeout != MAX_SCHEDULE_TIMEOUT &&sched ->ring_mirror_list,sched ->timeout ); sched ->job_list_lock);sched = (struct drm_gpu_scheduler *)param;while (!kthread_should_stop()) {sched ->wake_up_worker,sched ) &&sched ))) ||if (!entity)continue ;if (!sched_job)continue ;sched ->hw_rq_count);sched ->ops->run_job(sched_job);if (fence) {if (r == -ENOENT)else if (r)"fence add callback failed (%d)\n" ,else {sched ->job_scheduled);return 0;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 objdump -d -l -S gpu-sched.ko > gpu-sched.objdump2821 0000000000001448 <drm_sched_main>: 848 1448 : a9b67bfd stp x29, x30, [sp, #-160 ]!849 struct sched_param sparam =1 };144 c: 52800023 mov w3, #0x1 853 1450 : 2 a0303e1 mov w1, w3848 1454 : 910003f d mov x29, sp1458 : a9025bf5 stp x21, x22, [sp, #32 ]145 c: aa0003f6 mov x22, x0886 1870 : aa1503e1 mov x1, x211874 : aa1303e0 mov x0, x191878 : 97f ffd58 bl dd8 <drm_sched_process_job>187 c: 17f fffab b 1728 <drm_sched_main+0x2e0 >628 return queue_delayed_work(system_wq, dwork, delay);1880 : 90000001 adrp x1, 0 <system_wq>527 return queue_delayed_work_on(WORK_CPU_UNBOUND, wq, dwork, delay);1884 : 91004042 add x2, x2, #0x10 ; 将 x2 寄存器的值加上 0x10 1888 : 52802000 mov w0, #0x100 ; 将 w0 寄存器的值设置为 0x100 188 c: f9400021 ldr x1, [x1] ; 从存储在 x1 寄存器中的地址处加载一个 64 位值到 x1 寄存器1890 : 94000000 bl 0 <queue_delayed_work_on> ; 调用一个函数，函数地址为 0 ，即 queue_delayed_work_on1894 : 17f fff8e b 16 cc <drm_sched_main+0x284 > ; 无条件分支到地址 16 cc
1 2 3 4 5 /data3/home/yuanqiliang/code/arm-kernel/./include/asm -generic/qspinlock.h:101 0 );16 cc: 52800000 mov w0, #0x0 16 d0: 91050261 add x1, x19, #0x140 16 d4: 089f fc20 stlrb w0, [x1]
1 2 3 4 ./scripts/faddr2line vmlinux add_timer+0x20/0x28
1 2 3 4 5 6 void add_timer (struct timer_list *timer)
1 #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
该宏接受一个条件表达式作为参数。如果条件表达式为真（即非零），则会调用BUG()宏，导致程序终止并生成错误报告。
timer_pending(timer) 是一个函数或宏，用于检查指定的定时器是否处于挂起状态。如果定时器已经被挂起，表示存在错误的状态，那么BUG_ON()宏就会触发一个BUG，导致程序终止执行。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 objdump -d -l -S timer.o > timer.objdump5179 5179 00000000000027 c8 <add_timer>: 5180 add_timer():5181 /data3/home/yuanqiliang/code/arm-kernel/kernel/time/timer.c:1137 5182 {5183 27 c8: a9bf7bfd stp x29, x30, [sp, #-16 ]!5184 27 cc: 910003f d mov x29, sp5185 /data3/home/yuanqiliang/code/arm-kernel/kernel/time/timer.c:1138 5186 BUG_ON(timer_pending(timer));5187 27 d0: f9400402 ldr x2, [x0, #8 ]5188 27 d4: b50000a2 cbnz x2, 27e8 <add_timer+0x20 >5189 /data3/home/yuanqiliang/code/arm-kernel/kernel/time/timer.c:1139 5190 mod_timer(timer, timer->expires);5191 27 d8: f9400801 ldr x1, [x0, #16 ]5192 27 dc: 94000000 bl 2460 <mod_timer>5193 /data3/home/yuanqiliang/code/arm-kernel/kernel/time/timer.c:1140 5194 }5195 27e0 : a8c17bfd ldp x29, x30, [sp], #16 5196 27e4 : d65f03c0 ret 5197 /data3/home/yuanqiliang/code/arm-kernel/kernel/time/timer.c:1138 5198 BUG_ON(timer_pending(timer));5199 27e8 : d4210000 brk #0x800 5200 27 ec: d503201f nop
brk #0x800 触发了一个软中断，参数为 0x800。软中断通常被用于在程序中插入调试点，以便在这里停下程序的执行，以便进行调试。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 144 154 static inline int timer_pending (const struct timer_list * timer) 156 return timer->entry.pprev != NULL ;157 }
timer_pending函数检查给定的定时器是否处于等待状态。当 timer->entry.pprev 不为 NULL 时，表示定时器当前处于等待状态，返回 1；否则，返回 0。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 11 struct timer_list {12 16 struct hlist_node entry ;17 unsigned long expires; 18 void (*function)(struct timer_list *); 19 u32 flags; 20 21 #ifdef CONFIG_LOCKDEP 22 struct lockdep_map lockdep_map ;23 #endif 24 };
在 GPU 调度器（gpu_sched）中，如果 timer_list 为空，通常表示当前没有定时器在等待执行。这可能是正常的状态，尤其是当没有 GPU 任务或者所有 GPU 任务都已经及时完成时。
具体来说，timer_list 一般用于跟踪 GPU 调度器中的计时器，这些计时器可能用于任务的超时、延迟或其他与时间相关的操作。当没有任务等待执行，或者已经按时完成，timer_list 可能为空。
如果你观察到 timer_list 为空，但 GPU 任务并未按预期执行，可能需要进一步调查原因。可能的原因包括：
任务完成： 当 GPU 任务按时完成时，相关的计时器可能会被取消，从而导致 timer_list 为空。
任务延迟： 如果任务因某些原因而延迟执行，相关的计时器可能还在等待。在这种情况下，你可能需要检查任务执行的日志或其他调试信息，以找到延迟的原因。
调度器问题： 如果 GPU 调度器本身存在问题，可能导致计时器未正确添加或处理。在这种情况下，你可能需要查看 GPU 调度器的源代码、文档或相关的日志信息。
总的来说，timer_list 为空并不一定表示问题，这可能是 GPU 调度器正常运行的一部分。然而，如果你怀疑有问题，最好检查相关的调试信息以了解更多上下文。
1 3817 2023-12-19 22:41:45 hbyc-PC kernel: [102639.646128] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout , signaled seq =27126054, emitted seq =27126054
1 2 3 4 5 6 7 215 220 MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms > 0 (default 10000)" );221 module_param_named(lockup_timeout, amdgpu_lockup_timeout, int , 0444 );
1 2 cat /sys/module/amdgpu/parameters/lockup_timeout
amdgpu_job_timedout: 当调度器执行任务超时，调用的超时处理回调函数。
继续排查
将lockup_timeout参数调大:
1 echo 20000 > /sys/module/your_module/parameters/lockup_timeout
cpu动态调频开启没？
gpu调频开启没？
1 trace-bpfcc -tUK amdgpu_set_dpm_forced_performance_level