From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43DE3A90.4040107@domain.hid> Date: Mon, 30 Jan 2006 17:10:56 +0100 From: Anders Blomdell MIME-Version: 1.0 Subject: Re: [Xenomai-core] [BUG] Interrupt problem on powerpc References: <43DE1DAD.8050302@domain.hid> <43DE2505.7000709@domain.hid> In-Reply-To: <43DE2505.7000709@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org 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