
                        RTAI LXRT Exception Handling

The LXRT module now mounts a handler to deal with processor generated 
exceptions. These exceptions or traps use the lower 32 vectors in the IDT.
The previous approach was to simply ignore trap handling. It worked as long
as the real time code was bug free. Often, the slightest mistake would
crash or reboot the computer or screw up something that came back later to
make the user's life miserable. Real time developers became masters of the
fsck program. Much time was waisted waiting for fsck to do it's thing
at reboot time. Those days are over :-)

RTAI-LXRT Trapping of exceptions can deal with the following 5 cases:

1) A plain real time task is running. Action: suspend the task. We avoid
   deleting the task to make it possible for a module to dump the task
   structure and it's stack after the fact. qBlk's can execute user space
   code if setup by LXRT soft or hard tasks. In that case a special handler
   is installed to switch back the memory before the context switch to
   Linux.

2) A soft real time task is running in user space. Action: none - let Linux
   deal with it. lxrt-informed deletes the real time component task and any 
   other resource associated with the failed task.

3) A soft real time task is running in the kernel. Action: Pend a srq 
   to send the signal SIGKILL to the Linux task and call lxrt_suspend()
   to abort the real time component task (the buddy task). lxrt-informed
   finishes as in 2 above. Note: control never returns to the trap handler
   and the unexecuted iret disappears on the stack after the rt_schedule()
   in lxrt_suspend(). 

4) A HRT task is running in user space. Action: give_back_to_linux()
   followed by do_exit(SIGKILL). 

5) A HRT task is running in the kernel. Action: lxrt_suspend() to come
   back to Linux context, give_back_to_linux() to come back to lxrt
   soft mode and do_exit(SIGKILL). lxrt-informed completes as in 2 above.
   
Technical notes on traps:

1) There is not much that can be done if an exception like a division
   by zero occurs in an interrupt handler. However, that remains true
   for all systems.

2) The CPL is not checked if the exception is generated by the processor.
   That's why trap and interrupt descriptors have a DPL of zero. The
   IF flag does not affect processor generated exceptions. 

3) The DPL level of a trap descriptor can be changed to 3 to allow calling
   the trap with the int $n instruction from user space. Catch 22: there is
   no error code pushed on the stack in that case. 

4) A stack switch occurs if the handler's priviledge level is smaller
   than the CPL of the interrupted procedure. 

5) Page fault exceptions occur all the time in the Linux context. Usually
   the user space program needs a VMA not currently mapped in physical
   memory. An error can occur if the kernel tries to access user
   space memory with a bad pointer argument. The page fault handler
   deals nicely with that problem - see file exception.txt in the kernel
   documentation.  

Pierre Cloutier
pcloutier@PoseidonControls.com
