This actually turned out to be a red herring. One of the things I had to trace was an attempted read from /dev/ttyd0 in which I was trying to go past the actual read. This appears to be what thoroughly confused the trace.
There was a logic error in the signal handler which caused it to never exit and that was what prevented further signals. It took me a while to figure all that out but it makes sense. In my tinkering with embedded systems and assembly-language programming, one often-times shuts off the interrupts first thing during an interrupt handler because disaster results if another interrupt comes in while one is setting up the jump vector, etc. The signal handler hides all those details, but it still has to take care of them. Anyway, when I fixed the logic of the handler, itself and did not try to trace it, it does work as one would expect. I appreciate the help as it made me think and re-examine what was happening. The man page more or less explains it if you know what to look for but it wasn't close enough to what was happening here to really help much. Derek Ragona writes: >Nothing needs to be in your handler function to continue running simply >return from your function. However, depending on the signal you may wish >to call the original signal handler. Signals like interrupts are chained >linked lists of handlers. You can choose to break the chain, and have only >your handler called, or keep the chain intact calling the other handlers. In this case, the chain appears to resume on return from the routine I called on SIGHUP. _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"