79d4e25bea
handling, SMPng always switches the npx context away from curproc before calling the handler, so the handler always paniced. When using exception 16 exception handling, SMPng sometimes switches the npx context away from curproc before calling the handler, so the handler sometimes paniced. Also, we didn't lock the context while using it, so we sometimes didn't detect the switch and then paniced in a less controlled way. Just lock the context while using it, and return without doing anything except clearing the busy latch if the context is not for curproc. This fixes the exception 16 case and makes the IRQ13 case harmless. In both cases, the instruction that caused the exception is restarted and the exception repeats. In the exception 16 case, we soon get an exception that can be handled without doing anything special. In the IRQ13 case, we get an easy to kill hung process. |
||
|---|---|---|
| .. | ||
| atpic_vector.S | ||
| clock.c | ||
| icu_ipl.s | ||
| icu_ipl.S | ||
| icu_vector.s | ||
| icu_vector.S | ||
| icu.h | ||
| intr_machdep.c | ||
| intr_machdep.h | ||
| isa_dma.c | ||
| isa_dma.h | ||
| isa.c | ||
| isa.h | ||
| ithread.c | ||
| nmi.c | ||
| npx.c | ||
| timerreg.h | ||
| vector.s | ||
| vector.S | ||