| title: | OMAP sporadic hard lock up when GPIO interru |
|
Hi everyone,
Im trying to debug a problem with GPIO interrupts on my OMAP3503
(Gumstix Overo) platform with kernel 2.6.29.4-rt16-omap1.
While this is a sporadic lock-up, I havent been able to reproduce it
when PREEMPT_HARDIRQ is disabled.
I think it might have something to do with this patch (which is applied BTW):
rel="nofollow" patchwork.kernel.org/patch/16046/ patchwork.kernel.org/patch/16046/
And see this thread:
rel="nofollow" markmail.org/message/aaqpk5jztrrypsxz markmail.org/message/aaqpk5jztrrypsxz
Sometimes, I see a spurious IRQ message like this:
Spurious irq 95: 0xffffffdf, please flush posted write for irq 31
that the above patch is supposed to fix, just before the system locks
up. Is it possible that the interrupt handler is getting preempted
between acknowledging the interrupt and the flush posted write, and
meanwhile another interrupt from the same bank occurs?
To check this hypothesis, I built the kernel with
CONFIG_PREEMPT_DESKTOP=y
# CONFIG_PREEMPT_RT is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
which gives a /proc/irq/<irq /<handler /threaded flag. When I tried
disabling threading on irqs 246-249 (which are the virtual irqs for
the problematic GPIO interrupts), the problem still occured. Im not
sure how to disable threading or preemption on the intermediate ISR
(gpio_irq_handler() at arch/arm/plat-omap/gpio.c:959) which determines
which GPIO in the bank caused the interrupt and spawns the virtual
interrupts.
Any ideas for debugging or narrowing down on the cause?
Many thanks,
Hugo
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at rel="nofollow" vger.kernel.org/majordomo-info.html vger.kernel.org/majordomo-info.html
|
