Anders Blomdell wrote: > 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...
Your approach is basically what I proposed some years back on rtai-dev for handling unresolvable shared RT/NRT IRQs. I once successfully tested such a setup with two network cards, one RT, the other Linux. So when you are really doomed and cannot change the IRQ line of your RT device, this is a kind of emergency workaround. Not nice and generic (you have to write the stub for disabling the NRT IRQ source), but it should work. Anyway, I do not understand what made your spinlock recurs. This shared IRQ scenario should only cause indeterminism to the RT driver (by blocking the line until the Linux handler can release it), but it must not trigger this bug. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
