wiki1667: Kernel_Crashed_Common_Causes (Version 4) |
Common Causes of QNX Neutrino Kernel Crashes#If you see a QNX Neutrino kernel crash, chances are it's caused by one of the following. While this is by no means a complete list, the following are the high runner cases. - segfault/sigbus in an interrupt handler - incorrectly written callouts - Operations that cause a machine check or other types of asynchronous faults in the system. If you're unlucky the fault gets "noticed" by the CPU when we're executing in the kernel crash. If a user-land thread was active at the time, a SIGBUS to the task is the usual end result. - If there are hardware issues, high load can elicit crashes - Memory controller configuration issues can cause random crashes - low memory conditions can be hazardous. These generally would be failed assertions (ie. cannot allocate) which should not have failed. - Having a JTAG attached to the board (not consistent from board to board/JTAG to JTAG) when jumping from startup into the OS (or any time after). - A privileged thread steps on hardware that procnto cares about (the interrupt controller(s), the timer providing the clock, the memory controller, the MMU, etc.) - A root process does a direct physical mapping (MAP_PHYS) to memory it shouldn't and overwrites important bits. - A privileged thread programs a DMA engine to scribble over memory it shouldn't. - Startup lies about something on the system page (e.g. where memory is, how much memory is in the system, what the capabilities of the CPU are, etc). |