-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BORE: Crash, when switching often BORE off and on #396
Comments
It probably happened, because you switched scheduler in the process. Yes, I know, it's done in the video, but a crash can happen because of that. It happened in "pick_task_fair", so maybe a task was already planned for BORE, you switched back to "EEVDF" and this task was not fully migrated back to EEVDF in the switch and you got your kaboom. It's just a guess. Use the kernel in your day to day usage and see, if it happens there, too. |
This is a known issue with LLVM19. AFAIK a fix was already staged in amd-drm-staging-next and will probably in a future stable kernel soon. |
But what does this message tell me? Is it save to use this kernel or is this stack limit issue a concern for system stability? |
Its just a compiler warning - not more. This has nothing to do with the system stability. |
ff: push rdi
0f 84 2a 01 00 00: je 0x12a
49 8b 47 60: mov rax, qword ptr [r15 + 0x60]
48 85 c0: test rax, rax
74 0e: je 0xf
80 78 50 00: and byte ptr [rax + 0x50], 0x00
74 08: je 0x8
4c 89 ff: mov qword ptr [rdi], r15
e8 b4 c9 ff ff: call 0xffffffffc9b4
66 90: nop
66 90: nop
4c 89 ff: mov qword ptr [rdi], r15
e8 28 94 00 00: call 0x9428
<80> 78 51 00: and byte ptr [rax + 0x51], 0x00
74 c2: je 0xc2
4c 89 f7: mov rdi, r15
48 89 c6: mov rsx, rax
ba 01 02 00 00: mov edx, 0x00000201
e8 d2 23 00 00: call 0x23d2 Related to delayed dequeueing, maybe? |
yesterday I compiled cachyos 6.13.1 and got this warning during compilation.
ld.lld: warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6714:0: stack frame size (2056) exceeds limit (2048) in function 'dml_core_mode_support'
This was with
clang
andlto=thin
which is the default now.After that I wanted to do some performance resp. latency tests as described in the video: https://www.youtube.com/watch?v=kKumW_qH4a0
from the BORE developer @firelzrd
After a hand full of
sysctl -w kernel.sched_bore=0
/sysctl -w kernel.sched_bore=1
cycles my PC frooze completey. Sound was looping and not even a REISUB was possible.This is the journal
The text was updated successfully, but these errors were encountered: