0670ba6c92
Zephyr isn't ready to handle interrupts yet, until the threading/scheduler are set up and we make our first context switch. This was a semi-hidden bug: only the timer interrupt would actually get unmasked before the system was ready, and obviously would never have time to fire a tick before the system completed initialization. But a combination of system load and a new version of Qemu (which seems to be more sensitive to non-deterministic timing glitchery) has made this visible. About 2-3% of the time when run under a full sanitycheck, the qemu process will get swapped away for long enough that the tick timer expires before _Cstart() has reached enable_multithreading(). It looks like the original code was cut and pasted from another implementation, which was expected to call into an "application" main() routine that wanted interrupts ready. Fixes #11182 (Note also that this code is not used for ESP-32, which has its own startup path) Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| offsets | ||
| startup | ||
| CMakeLists.txt | ||
| atomic.S | ||
| cpu_idle.c | ||
| crt1.S | ||
| fatal.c | ||
| irq_manage.c | ||
| irq_offload.c | ||
| swap.S | ||
| thread.c | ||
| window_vectors.S | ||
| xt_zephyr.S | ||
| xtensa-asm2-util.S | ||
| xtensa-asm2.c | ||
| xtensa_context.S | ||
| xtensa_intgen.py | ||
| xtensa_intgen.tmpl | ||
| xtensa_intr.c | ||
| xtensa_intr_asm.S | ||
| xtensa_vectors.S | ||