You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please note that when enabling many other tracepoints, things work fine.
My one theory was that possibly we are running out of the stack and I have tried to double kernel and app and exception stack and it did not help.
My other theory is that there still may be an issue in sched.S where we are not saving or restoring some registers. Or maybe the fact that these tracepoints are called in sched::cpu::schedule_next_thread() has something to do with it.
One more thing - the following tracepoints crash:
sched_sched
sched_switch
sched_load
sched_wake
These seem to work (at least sometimes):
sched_preempt (sometimes on 2 CPUs)
sched_idle
sched_wait
The text was updated successfully, but these errors were encountered:
This failure appears (as you noted in the title) to be specific to aarch64. I couldn't reproduce it on x86.
I tried to review this code again (it is fairly complex, unfortunately), but can't find any bugs just by looking at the code :-(
The trace_slow_path() code in trace.hh does arch::irq_disable_notrace() which is necessary to avoid switching CPUs while touching the per-cpu trace buffers, and also reentrancy of different tracepoints - I hope this function does work correctly on aarch64?
The stack traces I am presenting below might be symptoms of a single underlying issue and may be related to #1158.
For example, when running
tst-hello.so
on ROFS image with the tracepointsched_switch
enabled we occasionally get this type of crash:Running same test on ZFS image looks slightly different:
or
Please note that when enabling many other tracepoints, things work fine.
My one theory was that possibly we are running out of the stack and I have tried to double kernel and app and exception stack and it did not help.
My other theory is that there still may be an issue in
sched.S
where we are not saving or restoring some registers. Or maybe the fact that these tracepoints are called insched::cpu::schedule_next_thread()
has something to do with it.One more thing - the following tracepoints crash:
These seem to work (at least sometimes):
The text was updated successfully, but these errors were encountered: