Re: [Xenomai-core] [BUG] Interrupt problem on powerpc

[Anders Blomdell <anders.blomdell@domain.hid>]

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