[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