Hi, Aurabindo, On Sat, Mar 29, 2025 at 2:27 AM Aurabindo Pillai <aurabindo.pil...@amd.com> wrote: > > > > On 2025-03-26 21:40, Huacai Chen wrote: > > Hi, Alex, > > > > On Thu, Mar 27, 2025 at 8:10 AM Alex Hung <alex.h...@amd.com> wrote: > >> > >> The following error messages showed up on an APU and a dGPU during testing. > >> > >> <3> [100.231411] BUG: sleeping function called from invalid context at > >> include/linux/sched/mm.h:321 > >> <3> [100.231414] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: > >> 1711, name: kms_color > >> <3> [100.231416] preempt_count: 2, expected: 0 > >> <3> [100.231417] RCU nest depth: 0, expected: 0 > >> <3> [100.231418] Preemption disabled at: > >> <3> [100.231419] [<ffffffffc0c2843b>] dc_fpu_begin+0x2b/0xc0 [amdgpu] > >> <4> [100.231626] CPU: 4 UID: 0 PID: 1711 Comm: kms_color Tainted: G > >> W 6.12.0+ #1 > >> <4> [100.231629] Tainted: [W]=WARN > >> <4> [100.231631] Call Trace: > >> <4> [100.231632] <TASK> > >> <4> [100.231633] dump_stack_lvl+0x5b/0x70 > >> <4> [100.231638] dump_stack+0x10/0x20 > >> <4> [100.231639] __might_resched+0x170/0x1d0 > >> <4> [100.231643] __might_sleep+0x44/0x70 > >> <4> [100.231645] __alloc_pages_noprof+0x22f/0x370 > >> <4> [100.231649] ___kmalloc_large_node+0x95/0x150 > >> <4> [100.231651] ? preempt_count_add+0x4e/0xc0 > >> <4> [100.231653] __kmalloc_large_noprof+0x1d/0xb0 > >> <4> [100.231655] dml2_create_copy+0x27/0x60 [amdgpu] > >> <4> [100.231827] dc_state_create_copy+0x7e/0x170 [amdgpu] > >> <4> [100.231995] update_planes_and_stream_state+0x23c/0x600 [amdgpu] > >> <4> [100.232189] update_planes_and_stream_v2+0x22b/0x530 [amdgpu] > >> <4> [100.232366] ? amdgpu_dm_atomic_commit_tail+0x1310/0x4100 [amdgpu] > >> <4> [100.232569] ? commit_tail+0x96/0x140 [drm_kms_helper] > >> <4> [100.232577] dc_update_planes_and_stream+0x5b/0xe0 [amdgpu] > >> <4> [100.232730] amdgpu_dm_atomic_commit_tail+0x1fa7/0x4100 [amdgpu] > >> <4> [100.232908] ? stack_depot_save_flags+0x2c/0x730 > >> <4> [100.232915] ? wait_for_completion_timeout+0x1d/0x30 > >> <4> [100.232917] commit_tail+0x96/0x140 [drm_kms_helper] > >> <4> [100.232923] drm_atomic_helper_commit+0x12b/0x150 [drm_kms_helper] > >> <4> [100.232927] drm_atomic_commit+0xad/0xe0 [drm] > >> <4> [100.232939] ? __pfx___drm_printfn_info+0x10/0x10 [drm] > >> <4> [100.232956] drm_atomic_helper_set_config+0x80/0xc0 [drm_kms_helper] > >> <4> [100.232961] drm_mode_setcrtc+0x22e/0x910 [drm] > >> <4> [100.232975] ? kfree+0x18f/0x350 > >> <4> [100.232977] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm] > >> <4> [100.232987] drm_ioctl_kernel+0xa7/0x100 [drm] > >> <4> [100.233004] drm_ioctl+0x29d/0x500 [drm] > >> <4> [100.233015] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm] > >> <4> [100.233026] ? _raw_spin_unlock_irqrestore+0x1f/0x40 > >> <4> [100.233029] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu] > >> <4> [100.233131] __x64_sys_ioctl+0x92/0xd0 > >> <4> [100.233133] x64_sys_call+0x1205/0x20d0 > >> <4> [100.233136] do_syscall_64+0x50/0x110 > >> <4> [100.233138] entry_SYSCALL_64_after_hwframe+0x76/0x7e > >> <4> [100.233142] RIP: 0033:0x7fb21e71a94f > >> <4> [100.233144] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 > >> 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 > >> 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 > >> <4> [100.233145] RSP: 002b:00007ffdd9a52e50 EFLAGS: 00000246 ORIG_RAX: > >> 0000000000000010 > >> <4> [100.233148] RAX: ffffffffffffffda RBX: 00007ffdd9a52ee0 RCX: > >> 00007fb21e71a94f > >> <4> [100.233149] RDX: 00007ffdd9a52ee0 RSI: 00000000c06864a2 RDI: > >> 0000000000000005 > >> <4> [100.233149] RBP: 00000000c06864a2 R08: 0000000000000000 R09: > >> 00005609537f7b08 > >> <4> [100.233150] R10: 0000000000000000 R11: 0000000000000246 R12: > >> 0000000000000000 > >> <4> [100.233151] R13: 0000000000000005 R14: 0000000000000000 R15: > >> 00005609537e2848 > >> <4> [100.233152] </TASK> > > This seems caused by dml2_allocate_memory(), to fix this we can only > > protect FPU in DML2, I can do it in the new version, but I want to > > listen Aurabindo's opinion. > > > > > > It looks like dml21_apply_soc_bb_overrides() does have some division on > double variables. I'm curious why we dont see this on our side. Was this > seen on x86 or Loongson? It is seen on Loongson.
> > I think your approach is correct. Thanks for taking time to fix this. We > can add it to weekly testing if you send us a patch. V2 is sent, please take a look. https://lore.kernel.org/dri-devel/20250327095334.3327111-1-chenhua...@loongson.cn/T/#t Huacai
