[uClinux-dev] MCF5249 GPIO5/SIGILL Interrupt Crash

[Gavin Lambert]

Quoth Paul Romero:
> I made great progress in isolating the problem.
> If you modify the driver to ignore interrupts that
> are very close together rather than automatically send
> SIGUSR2 to to the user space application process right
> away, the problem does not occur. (i.e. Crude debouncing.)
> This means that the real problem is somewhere is
> in  kernel kill_proc() or  user space process signal
> handling.
> 
> I strongly suspect it is in user space process signal handling and
> essentially the user space processes don't queue or ignore signals
> correctly. One likely possibility is that there is a problem
> if a task receives a signal while a signal handler is executing.
> The other is the old ALTIVEC problem is somehow still
> in the MCF5249 code which would be quite serious
> as I don't think the MCF5249 supports either the ALTIVEC
> instruction or an alternate signal stack.

While I admit to being mostly ignorant of signals (I don't really use them):
aren't signal handlers set by signal() single-shot handlers?  So if a second
signal arrives before the signal handler itself calls signal() again then
it'll get default processing, which might be to abort() or something.

IIRC there's another method you can call to set a signal handler (not sure
what it is, my man pages aren't handy right now) which takes a flag letting
you specify that it's a permanent handler.  (Or a flag saying it's one-shot,
which you can leave out; again I forget.)