Signal/Interrupt oddities

[bruce woller]

I believe that SIGNALS are implemented as program controlled trap 
instructions in the PPC Linux Kernel.  The trap causes an exception and 
the exception handler decides who should get dispatched to handle this 
exception before the return from interrupt is executed.  Hopefully the 
SIGNAL handler has registered itself with the kernel (usually takes 
place when the module is installed i.e. modProbe or insMod).  Can you 
compile your ADA program with a -g option that builds gdb compatible 
object.  (I know this is easy with gcc but I don't know ADA) If you 
can, try running your program under the gdb debugger and see if some 
other handler is getting control of your SIGNAL.

Just a suggestion,
Bruce
On Saturday, June 5, 2004, at 09:58  AM, Butler, Paul wrote:

> I have two G5's running:
>
> YDL 3.0 - 2.6.4-1.1321smp kernel
>
> I have an Ada program that attaches an interrupt handler to SIGUSR1 
> (this doesn't seem to matter, I've tried several different signals 
> with the same result), and then sets a timer to fire that 
> interrupt/signal.  It works fine on one machine, but doesn't on the 
> other.  I can compile the program on either machine, and run it on the 
> other, and the outcome is the same.  One machine throws/catches the 
> signal, the other doesn't.
>
> Oddly enough, I have another test program that doesn't actually attach 
> a handler, but uses a POSIX wait for a timer to expire and it works on 
> both machines.  So something must be up with the Attach_Handler 
> processing on the one machine that doesn't work.
>
> My question is what could I have done to the one machine to cause 
> Linux to ignore signals in this manner.
>
> Thanks.
> _______________________________________________
> yellowdog-general mailing list
> yellowdog-general@lists.terrasoftsolutions.com
> http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
> HINT: to Google archives, try  '<keywords> site:terrasoftsolutions.com'
>