[uClinux-dev] MCF5249 GPIO5/SIGILL Interrupt Crash

Paul Romero paulr at rcom-software.com
Fri Jun 6 12:33:30 EDT 2008


Dear User Group:

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.

Has anybody else seen evidence of this problem ?


Best Regards,

Paul R.


--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: paulr at rcom-software.com




More information about the uClinux-dev mailing list