Since we are on HN, I think it could be explained there (before it's all consumed by AI slop):

For complex reasons, available CPU time during landing was lower than expected (it was stolen by radar pointing peripheral). This caused regularly scheduled job to spawn before previous instance finished. As such, this caused two effects: job instances were preempted before finishing by new instances in the middle of the routine, and that pilling up of the old instances eventually exhausted resources and caused kernel to panic and reboot. Rebooting during landing sounds scary, but that actually was fine: such critical tasks were specifically designed to automatically restart from previously saved checkpoint data in the memory.

What was more dangerous, was the preempted tasks before restarts occured. First, it meant routine wasn't executing to the end, which in actual flight caused blanked displays (as updating the display was the last thing routine was doing). Any more CPU time stolen, and it could be interrupted even earlier, eg. before it sends the engine commands.

Another issue is that in case of fluctuating load, new instances could actually begin running to the end, and then previously preempted job instance could be resumed, potentially sending the stale data to the displays and engine.

And finally, while each job instance had it own core and VAC set properly managed by the kernel (think of it as modern kernel switching between task stacks), that particular routine wasn't designed to be reentrant. So it was using various global variables ("erasables") for its own purpose, that when interrupted in unluckly place might have caused very bad behavior.

How likely all of above is to occur, depends on the exact profile of fluctuating load caused by the confused radar peripheral. I guess that's why Mike Stewart is trying to replicate these issues with real CDU.