Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617] [c00c22d4] _raw_spin_lock+0x180/0x184
[ 42.660637] [c000f388] __ipipe_ack_irq+0x88/0x130
[ 42.723657] [c000efe4] __ipipe_handle_irq+0x140/0x268
[ 42.791259] [c000f144] __ipipe_grab_irq+0x38/0xa4
[ 42.854279] [c0005058] __ipipe_ret_from_except+0x0/0xc
[ 42.923029] [00000000] 0x0
[ 42.959695] [c0038348] __do_IRQ+0x134/0x164
[ 43.015839] [c000ed04] __ipipe_do_IRQ+0x2c/0x44
[ 43.076567] [c000eb08] __ipipe_sync_stage+0x1ec/0x228
[ 43.144170] [c0039420] ipipe_suspend_domain+0x7c/0xc4
[ 43.211774] [c000f0b0] __ipipe_handle_irq+0x20c/0x268
[ 43.279377] [c000f144] __ipipe_grab_irq+0x38/0xa4
[ 43.342396] [c0005058] __ipipe_ret_from_except+0x0/0xc
[ 43.411145] [c0006524] default_idle+0x10/0x60
I think some probably important information is missing above this
back-trace.
You are so right!
> What does the kernel state before these lines?
[ 42.346643] BUG: spinlock recursion on CPU#0, swapper/0
[ 42.415438] lock: c01c943c, .magic: dead4ead, .owner: swapper/0,
.owner_cpu: 0
[ 42.511681] Call trace:
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617] [c00c22d4] _raw_spin_lock+0x180/0x184
[ 42.660637] [c000f388] __ipipe_ack_irq+0x88/0x130
[ 42.723657] [c000efe4] __ipipe_handle_irq+0x140/0x268
[ 42.791259] [c000f144] __ipipe_grab_irq+0x38/0xa4
[ 42.854279] [c0005058] __ipipe_ret_from_except+0x0/0xc
[ 42.923029] [00000000] 0x0
[ 42.959695] [c0038348] __do_IRQ+0x134/0x164
[ 43.015839] [c000ed04] __ipipe_do_IRQ+0x2c/0x44
[ 43.076567] [c000eb08] __ipipe_sync_stage+0x1ec/0x228
[ 43.144170] [c0039420] ipipe_suspend_domain+0x7c/0xc4
[ 43.211774] [c000f0b0] __ipipe_handle_irq+0x20c/0x268
[ 43.279377] [c000f144] __ipipe_grab_irq+0x38/0xa4
[ 43.342396] [c0005058] __ipipe_ret_from_except+0x0/0xc
[ 43.411145] [c0006524] default_idle+0x10/0x60
It might be that the problem is related to the fact that the interrupt is a
shared one (Harrier chip, "Functional Exception"), that is used for both
message-passing (should be RT) and UART (Linux, i.e. non-RT), my current IRQ
handler always pends the interrupt to the linux domain (RTDM_IRQ_PROPAGATE),
because all other attempts (RTDM_IRQ_ENABLE when it wasn't a UART interrupt) has
left the interrupts turned off.
What I believe should be done, is
1. When UART interrupt is received, disable further non-RT interrupts
on this IRQ-line, pend interrupt to Linux.
2. Handle RT interrupts on this IRQ line
3. When Linux has finished the pended interrupt, reenable non-RT interrupts.
but I have neither been able to achieve this, nor to verify that it is the right
thing to do...
Regards
Anders Blomdell
