________________________________________________________________________
Applicable Environment
________________________________________________________________________
- Topic: What is the expected QNX behavior if an interrupt hangs?
- SDP: 6.4.1
- Target: Any supported target
________________________________________________________________________
Question
________________________________________________________________________
We have an interrupt handler that handles one of the PPC's external interrupts. This references a hardware address that in some circumstances may generate a bus fault when accessed (i.e. the read cycle cannot complete). We understand the bus fault will itself generate an exception, which can be handled. The question is what happens to the interrupt handler that generated the bus fault? It can't continue, so does the processor return from the interrupt? Will the next interrupt on the same external line be handled correctly? Will the system lock up?
________________________________________________________________________
Recommendation________________________________________________________________________
Bus Error. ---> SIGBUS /usr/include/signal.h
Reasons:
http://en.wikipedia.org/wiki/Bus_error
non-existent address
unaligned access
>We understand the bus fault will itself generate an exception, which can be handled.
This cpu exception is handled by the kernel (procnto) and transformed into a SIGBUS signal and that is made pending onto the process what caused it.
And now your question:
>The question is what happens to the interrupt handler that generated the bus fault?
NOTE:
Assuming you have used InterruptAttach() -call your interrupt handler is running (with some priority beyond 255) in kernel space/context not in process space/context and it shares its stack with the kernel.
So if this cpu-exception is generated from within your interrupt handler then again the kernel handles it turns it into a SIGBUS signal an makes it pending onto the process what it belongs to and returns to the instruction what was causing to the cpu-exception previously (and tries to execute it again!) and this is in your interrupt handler .
So either it succeeds now (if your lucky) and no cpu-exception is generated and the interrupt handler can be left and SIGBUS signal is delivered to your process where you handle it or crash with coredump.
Else (the unlucky case) --> your system freezes/hangs, cause the interrupt handler cannot be left.
Additional thoughts:
-I would really make sure that you do not cause such a exception from within your interrupt handler.
Can You?
-How frequent are you interrupts occurring (in daily application life)?
-Is it an option to use It InterruptAttachEvent() so that the real interrupt handling is done -in thread/process (perhaps in some separate irq-handling thread, assuming ) ?
-Are You afraid to miss interrupts ? Then you can use a message receive loop (and wait for pulses ) instead of InterruptWait() -> pulse events are queued.
________________________________________________________________________
NOTE:
This entry has been validated against the SDP version listed above. Use
caution when considering this advice for any other SDP version. For
supported releases, please reach out to QNX Technical Support if you have any questions/concerns. ________________________________________________________________________