All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-help] rtdm difficulties
@ 2012-01-20 16:17 Terry Fryar
  2012-01-20 17:03 ` Philippe Gerum
  2012-01-20 18:19 ` Gilles Chanteperdrix
  0 siblings, 2 replies; 12+ messages in thread
From: Terry Fryar @ 2012-01-20 16:17 UTC (permalink / raw)
  To: xenomai

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

Using xenomai 2.6.0 with 2.6.38 kernel and rtdm.  Been working on a rtdm
driver for awhile and all of a sudden I've lost stability.  So, I've backed
off all code except for registering an empty realtime irq handler using
rtdm_irq_request().  I'm getting kernel oops, and I don't know why?  The irq
handler simply returns RTDM_IRQ_HANDLED and that's it.  I've rebuilt my
kernel several times, and I'm wondering if I'm missing a .config entry for
something related to xenomai??  If I take out the irq handler registration,
all is fine.  This driver's been working for about 2 weeks, but all of a
sudden I'm getting kernel faults.  Here's what I'm getting from my driver
(vme_pd_drv):
 
[  795.986316] Unable to handle kernel paging request at virtual address
80b112d6
[  795.993905] Unable to handle kernel paging request at virtual address
e28cca55
[  796.001475] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.009045] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.016615] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.044130] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.051696] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.059262] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.106868] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.124353] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.131920] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.139484] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.207081] Unable to handle kernel paging request at virtual address
e5bcf074
[  796.214711] pgd = c0004000
[  796.217544] [e5bcf074] *pgd=00000000
[  796.221294] Internal error: Oops: 5 [#1] PREEMPT
[  796.266149] last sysfs file: /sys/devices/virtual/irqdrv/irqdrv0/uevent
[  796.273082] Modules linked in: vme_pd_drv [last unloaded: vme_pd_drv]
[  796.279846] CPU: 0    Not tainted  (2.6.38-ipipe-dirty #53)
[  796.315847] PC is at show_pte+0x18/0xb0
[  796.319868] LR is at __do_kernel_fault+0x54/0x84
[  796.384733] pc : [<c0059170>]    lr : [<c00592f8>]    psr: a0000113
[  796.384740] sp : c058f1c8  ip : fb020000  fp : 0000031b
[  796.396765] r10: 00000005  r9 : 20000113  r8 : 00000000
[  796.402237] r7 : c058f2a8  r6 : e5bcf050  r5 : e5bcf050  r4 : e5bcf074
[  796.449104] r3 : c058f1cc  r2 : c04fbb6f  r1 : e5bcf074  r0 : c04fbac9
[  796.455945] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment
kernel
[  796.463604] Control: 10c5387d  Table: 9e52c019  DAC: 00000017
[  796.519769] Process ü (pid: -598785, stack limit = 0xc058e2f0)
 
 

[-- Attachment #2: Type: text/html, Size: 3804 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-20 16:17 [Xenomai-help] rtdm difficulties Terry Fryar
@ 2012-01-20 17:03 ` Philippe Gerum
  2012-01-20 17:42   ` Terry Fryar
  2012-01-20 18:19 ` Gilles Chanteperdrix
  1 sibling, 1 reply; 12+ messages in thread
From: Philippe Gerum @ 2012-01-20 17:03 UTC (permalink / raw)
  To: xenomai

On 01/20/2012 05:17 PM, Terry Fryar wrote:
> Using xenomai 2.6.0 with 2.6.38 kernel and rtdm. Been working on a rtdm
> driver for awhile and all of a sudden I've lost stability. So, I've
> backed off all code except for registering an empty realtime irq handler
> using rtdm_irq_request(). I'm getting kernel oops, and I don't know why?
> The irq handler simply returns RTDM_IRQ_HANDLED and that's it. I've
> rebuilt my kernel several times, and I'm wondering if I'm missing a
> .config entry for something related to xenomai?? If I take out the irq
> handler registration, all is fine. This driver's been working for about
> 2 weeks, but all of a sudden I'm getting kernel faults. Here's what I'm
> getting from my driver (vme_pd_drv):
> [ 795.986316] Unable to handle kernel paging request at virtual address
> 80b112d6
> [ 795.993905] Unable to handle kernel paging request at virtual address
> e28cca55
> [ 796.001475] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.009045] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.016615] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.044130] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.051696] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.059262] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.106868] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.124353] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.131920] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.139484] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.207081] Unable to handle kernel paging request at virtual address
> e5bcf074
> [ 796.214711] pgd = c0004000
> [ 796.217544] [e5bcf074] *pgd=00000000
> [ 796.221294] Internal error: Oops: 5 [#1] PREEMPT
> [ 796.266149] last sysfs file: /sys/devices/virtual/irqdrv/irqdrv0/uevent
> [ 796.273082] Modules linked in: vme_pd_drv [last unloaded: vme_pd_drv]
> [ 796.279846] CPU: 0 Not tainted (2.6.38-ipipe-dirty #53)
> [ 796.315847] PC is at show_pte+0x18/0xb0
> [ 796.319868] LR is at __do_kernel_fault+0x54/0x84
> [ 796.384733] pc : [<c0059170>] lr : [<c00592f8>] psr: a0000113
> [ 796.384740] sp : c058f1c8 ip : fb020000 fp : 0000031b
> [ 796.396765] r10: 00000005 r9 : 20000113 r8 : 00000000
> [ 796.402237] r7 : c058f2a8 r6 : e5bcf050 r5 : e5bcf050 r4 : e5bcf074
> [ 796.449104] r3 : c058f1cc r2 : c04fbb6f r1 : e5bcf074 r0 : c04fbac9
> [ 796.455945] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> [ 796.463604] Control: 10c5387d Table: 9e52c019 DAC: 00000017
> [ 796.519769] Process ü (pid: -598785, stack limit = 0xc058e2f0)
                 ^^^^^^^^^^^^^^^^^^^^^^^^

UhOh... This very muck looks like stack overflow / corruption.

>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-20 17:03 ` Philippe Gerum
@ 2012-01-20 17:42   ` Terry Fryar
  0 siblings, 0 replies; 12+ messages in thread
From: Terry Fryar @ 2012-01-20 17:42 UTC (permalink / raw)
  To: 'Philippe Gerum', xenomai

Now I'm seeing this.  I have lost complete control at this point....argh....

[  149.017562] WARNING: at kernel/softirq.c:137
__local_bh_enable+0x44/0xac()
[  149.024765] Modules linked in: vme_pd_drv
[  149.029014] [<c00566fc>] (unwind_backtrace+0x0/0xe0) from [<c007db0c>]
(warn_slowpath_common+0x4c/0x64)
[  149.038892] [<c007db0c>] (warn_slowpath_common+0x4c/0x64) from
[<c007db3c>] (warn_slowpath_null+0x18/0x1c)
[  149.049019] [<c007db3c>] (warn_slowpath_null+0x18/0x1c) from [<c0083138>]
(__local_bh_enable+0x44/0xac)
[  149.118865] [<c0083138>] (__local_bh_enable+0x44/0xac) from [<c008481c>]
(irq_enter+0x44/0x60)
[  149.127899] [<c008481c>] (irq_enter+0x44/0x60) from [<c0046018>]
(asm_do_IRQ+0x18/0x98)
[  149.136302] [<c0046018>] (asm_do_IRQ+0x18/0x98) from [<c00b9af0>]
(__ipipe_sync_stage+0x154/0x188)

 

-----Original Message-----
From: Philippe Gerum [mailto:rpm@xenomai.org
Sent: Friday, January 20, 2012 11:04 AM
To: xenomai@xenomai.org
Cc: Terry Fryar
Subject: Re: [Xenomai-help] rtdm difficulties

On 01/20/2012 05:17 PM, Terry Fryar wrote:
> Using xenomai 2.6.0 with 2.6.38 kernel and rtdm. Been working on a 
> rtdm driver for awhile and all of a sudden I've lost stability. So, 
> I've backed off all code except for registering an empty realtime irq 
> handler using rtdm_irq_request(). I'm getting kernel oops, and I don't
know why?
> The irq handler simply returns RTDM_IRQ_HANDLED and that's it. I've 
> rebuilt my kernel several times, and I'm wondering if I'm missing a 
> .config entry for something related to xenomai?? If I take out the irq 
> handler registration, all is fine. This driver's been working for 
> about
> 2 weeks, but all of a sudden I'm getting kernel faults. Here's what 
> I'm getting from my driver (vme_pd_drv):
> [ 795.986316] Unable to handle kernel paging request at virtual 
> address
> 80b112d6
> [ 795.993905] Unable to handle kernel paging request at virtual 
> address
> e28cca55
> [ 796.001475] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.009045] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.016615] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.044130] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.051696] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.059262] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.106868] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.124353] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.131920] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.139484] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.207081] Unable to handle kernel paging request at virtual 
> address
> e5bcf074
> [ 796.214711] pgd = c0004000
> [ 796.217544] [e5bcf074] *pgd=00000000 [ 796.221294] Internal error: 
> Oops: 5 [#1] PREEMPT [ 796.266149] last sysfs file: 
> /sys/devices/virtual/irqdrv/irqdrv0/uevent
> [ 796.273082] Modules linked in: vme_pd_drv [last unloaded: 
> vme_pd_drv] [ 796.279846] CPU: 0 Not tainted (2.6.38-ipipe-dirty #53) 
> [ 796.315847] PC is at show_pte+0x18/0xb0 [ 796.319868] LR is at 
> __do_kernel_fault+0x54/0x84 [ 796.384733] pc : [<c0059170>] lr : 
> [<c00592f8>] psr: a0000113 [ 796.384740] sp : c058f1c8 ip : fb020000 
> fp : 0000031b [ 796.396765] r10: 00000005 r9 : 20000113 r8 : 00000000 
> [ 796.402237] r7 : c058f2a8 r6 : e5bcf050 r5 : e5bcf050 r4 : e5bcf074 
> [ 796.449104] r3 : c058f1cc r2 : c04fbb6f r1 : e5bcf074 r0 : c04fbac9 
> [ 796.455945] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment 
> kernel [ 796.463604] Control: 10c5387d Table: 9e52c019 DAC: 00000017 [ 
> 796.519769] Process ü (pid: -598785, stack limit = 0xc058e2f0)
                 ^^^^^^^^^^^^^^^^^^^^^^^^

UhOh... This very muck looks like stack overflow / corruption.

>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


--
Philippe.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-20 16:17 [Xenomai-help] rtdm difficulties Terry Fryar
  2012-01-20 17:03 ` Philippe Gerum
@ 2012-01-20 18:19 ` Gilles Chanteperdrix
  2012-01-20 18:24   ` Terry Fryar
  1 sibling, 1 reply; 12+ messages in thread
From: Gilles Chanteperdrix @ 2012-01-20 18:19 UTC (permalink / raw)
  To: Terry Fryar; +Cc: xenomai

On 01/20/2012 05:17 PM, Terry Fryar wrote:
> Using xenomai 2.6.0 with 2.6.38 kernel and rtdm.  Been working on a rtdm
> driver for awhile and all of a sudden I've lost stability.  So, I've backed
> off all code except for registering an empty realtime irq handler using
> rtdm_irq_request().  I'm getting kernel oops, and I don't know why?  The irq
> handler simply returns RTDM_IRQ_HANDLED and that's it.  I've rebuilt my
> kernel several times, and I'm wondering if I'm missing a .config entry for
> something related to xenomai??  If I take out the irq handler registration,
> all is fine.  This driver's been working for about 2 weeks, but all of a
> sudden I'm getting kernel faults.  Here's what I'm getting from my driver
> (vme_pd_drv):

Are you working on omap ? Is the irq coming from a gpio ? Are you
returning IRQ_HANDLED without acknowledging the interrupt at device
level (I am talking about the device on the other end of the irq line).

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-20 18:19 ` Gilles Chanteperdrix
@ 2012-01-20 18:24   ` Terry Fryar
  2012-01-20 18:32     ` Gilles Chanteperdrix
  0 siblings, 1 reply; 12+ messages in thread
From: Terry Fryar @ 2012-01-20 18:24 UTC (permalink / raw)
  To: 'Gilles Chanteperdrix'; +Cc: xenomai

Yeh, omap and gpio.....edge irq from a square wave pulse.... 

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: Friday, January 20, 2012 12:20 PM
To: Terry Fryar
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] rtdm difficulties

On 01/20/2012 05:17 PM, Terry Fryar wrote:
> Using xenomai 2.6.0 with 2.6.38 kernel and rtdm.  Been working on a 
> rtdm driver for awhile and all of a sudden I've lost stability.  So, 
> I've backed off all code except for registering an empty realtime irq 
> handler using rtdm_irq_request().  I'm getting kernel oops, and I 
> don't know why?  The irq handler simply returns RTDM_IRQ_HANDLED and 
> that's it.  I've rebuilt my kernel several times, and I'm wondering if 
> I'm missing a .config entry for something related to xenomai??  If I 
> take out the irq handler registration, all is fine.  This driver's 
> been working for about 2 weeks, but all of a sudden I'm getting kernel 
> faults.  Here's what I'm getting from my driver
> (vme_pd_drv):

Are you working on omap ? Is the irq coming from a gpio ? Are you returning
IRQ_HANDLED without acknowledging the interrupt at device level (I am
talking about the device on the other end of the irq line).

-- 
                                                                Gilles.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-20 18:24   ` Terry Fryar
@ 2012-01-20 18:32     ` Gilles Chanteperdrix
  2012-01-20 19:37       ` Terry Fryar
  0 siblings, 1 reply; 12+ messages in thread
From: Gilles Chanteperdrix @ 2012-01-20 18:32 UTC (permalink / raw)
  To: Terry Fryar; +Cc: xenomai

On 01/20/2012 07:24 PM, Terry Fryar wrote:
> Yeh, omap and gpio.....edge irq from a square wave pulse.... 

Try this patch:

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 30cb7d4..114ccf0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1272,7 +1272,7 @@ static void gpio_irq_handler(unsigned int irq,
struct irq_desc *desc)
 	u32 retrigger = 0;
 	int unmasked = 0;

-	desc->irq_data.chip->irq_ack(&desc->irq_data);
+	desc->irq_data.chip->irq_mask_ack(&desc->irq_data);

 	bank = get_irq_data(irq);
 #ifdef CONFIG_ARCH_OMAP1

-- 
                                                                Gilles.


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-20 18:32     ` Gilles Chanteperdrix
@ 2012-01-20 19:37       ` Terry Fryar
  2012-01-20 20:47         ` Philippe Gerum
  2012-01-21 16:05         ` [Xenomai-help] rtdm difficulties Gilles Chanteperdrix
  0 siblings, 2 replies; 12+ messages in thread
From: Terry Fryar @ 2012-01-20 19:37 UTC (permalink / raw)
  To: 'Gilles Chanteperdrix'; +Cc: xenomai

Ok, I'll try the patch.  A question though...on the beagle, there is a OMAP
register GPIO_IRQSTATUSx that I am not manually clearing out.  This is the
only place to ack an irq I know of...I assumed that was being handled by the
kernel?  Or is this what the patch is adding??  I'm very new to writing irq
handlers, as you can tell!

Honestly, all that's in my current handler is this:

int irqdrv_rtdm_isr(rtdm_irq_t* handle)
{
	return(RTDM_IRQ_HANDLED);
}

And here's the register func:

if ((err = rtdm_irq_request(&irqdrv_isr_handle, irqno, irqdrv_rtdm_isr,
RTDM_IRQTYPE_EDGE, IRQDRV_NAME, NULL)) == 0)
   rtdm_irq_enable(&irqdrv_isr_handle);

And I'm running against a square waveform and getting this:

[   56.522948] WARNING: at kernel/softirq.c:137
__local_bh_enable+0x44/0xac()
[   56.530153] Modules linked in: vme_pd_drv
[   56.534399] [<c00566fc>] (unwind_backtrace+0x0/0xe0) from [<c007db0c>]
(warn_slowpath_common+0x4c/0x64)
[   56.574419] [<c007db0c>] (warn_slowpath_common+0x4c/0x64) from
[<c007db3c>] (warn_slowpath_null+0x18/0x1c)
[   56.584568] [<c007db3c>] (warn_slowpath_null+0x18/0x1c) from [<c0083138>]
(__local_bh_enable+0x44/0xac)
[   56.594425] [<c0083138>] (__local_bh_enable+0x44/0xac) from [<c008481c>]
(irq_enter+0x44/0x60)
[   56.623476] [<c008481c>] (irq_enter+0x44/0x60) from [<c0046018>]
(asm_do_IRQ+0x18/0x98)
[   56.631880] [<c0046018>] (asm_do_IRQ+0x18/0x98) from [<c00b9af0>]
(__ipipe_sync_stage+0x154/0x188)


 

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: Friday, January 20, 2012 12:32 PM
To: Terry Fryar
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] rtdm difficulties

On 01/20/2012 07:24 PM, Terry Fryar wrote:
> Yeh, omap and gpio.....edge irq from a square wave pulse.... 

Try this patch:

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index
30cb7d4..114ccf0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1272,7 +1272,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
 	u32 retrigger = 0;
 	int unmasked = 0;

-	desc->irq_data.chip->irq_ack(&desc->irq_data);
+	desc->irq_data.chip->irq_mask_ack(&desc->irq_data);

 	bank = get_irq_data(irq);
 #ifdef CONFIG_ARCH_OMAP1

-- 
                                                                Gilles.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-20 19:37       ` Terry Fryar
@ 2012-01-20 20:47         ` Philippe Gerum
  2012-01-20 21:05           ` [Xenomai-help] rtdm difficulties..fixed Terry Fryar
  2012-01-20 21:12           ` [Xenomai-help] rtdm difficulties...not fixed Terry Fryar
  2012-01-21 16:05         ` [Xenomai-help] rtdm difficulties Gilles Chanteperdrix
  1 sibling, 2 replies; 12+ messages in thread
From: Philippe Gerum @ 2012-01-20 20:47 UTC (permalink / raw)
  To: Terry Fryar; +Cc: xenomai

On 01/20/2012 08:37 PM, Terry Fryar wrote:
> Ok, I'll try the patch.  A question though...on the beagle, there is a OMAP
> register GPIO_IRQSTATUSx that I am not manually clearing out.  This is the
> only place to ack an irq I know of...I assumed that was being handled by the
> kernel?  Or is this what the patch is adding??  I'm very new to writing irq
> handlers, as you can tell!
>
> Honestly, all that's in my current handler is this:
>
> int irqdrv_rtdm_isr(rtdm_irq_t* handle)
> {
> 	return(RTDM_IRQ_HANDLED);
> }
>
> And here's the register func:
>
> if ((err = rtdm_irq_request(&irqdrv_isr_handle, irqno, irqdrv_rtdm_isr,
> RTDM_IRQTYPE_EDGE, IRQDRV_NAME, NULL)) == 0)
>     rtdm_irq_enable(&irqdrv_isr_handle);
>
> And I'm running against a square waveform and getting this:
>
> [   56.522948] WARNING: at kernel/softirq.c:137
> __local_bh_enable+0x44/0xac()
> [   56.530153] Modules linked in: vme_pd_drv
> [   56.534399] [<c00566fc>] (unwind_backtrace+0x0/0xe0) from [<c007db0c>]
> (warn_slowpath_common+0x4c/0x64)
> [   56.574419] [<c007db0c>] (warn_slowpath_common+0x4c/0x64) from
> [<c007db3c>] (warn_slowpath_null+0x18/0x1c)
> [   56.584568] [<c007db3c>] (warn_slowpath_null+0x18/0x1c) from [<c0083138>]
> (__local_bh_enable+0x44/0xac)
> [   56.594425] [<c0083138>] (__local_bh_enable+0x44/0xac) from [<c008481c>]
> (irq_enter+0x44/0x60)
> [   56.623476] [<c008481c>] (irq_enter+0x44/0x60) from [<c0046018>]
> (asm_do_IRQ+0x18/0x98)
> [   56.631880] [<c0046018>] (asm_do_IRQ+0x18/0x98) from [<c00b9af0>]
> (__ipipe_sync_stage+0x154/0x188)

Make sure to have CONFIG_IPIPE_DEBUG_INTERNAL enabled in your kernel 
config btw, this might help.

Gilles, I wonder whether this backtrace could not be the sign of a demux 
ISR not going through ipipe_handle_chained_irq()?

>
>
>
>
> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Friday, January 20, 2012 12:32 PM
> To: Terry Fryar
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] rtdm difficulties
>
> On 01/20/2012 07:24 PM, Terry Fryar wrote:
>> Yeh, omap and gpio.....edge irq from a square wave pulse....
>
> Try this patch:
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index
> 30cb7d4..114ccf0 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -1272,7 +1272,7 @@ static void gpio_irq_handler(unsigned int irq, struct
> irq_desc *desc)
>   	u32 retrigger = 0;
>   	int unmasked = 0;
>
> -	desc->irq_data.chip->irq_ack(&desc->irq_data);
> +	desc->irq_data.chip->irq_mask_ack(&desc->irq_data);
>
>   	bank = get_irq_data(irq);
>   #ifdef CONFIG_ARCH_OMAP1
>


-- 
Philippe.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties..fixed...
  2012-01-20 20:47         ` Philippe Gerum
@ 2012-01-20 21:05           ` Terry Fryar
  2012-01-20 21:12           ` [Xenomai-help] rtdm difficulties...not fixed Terry Fryar
  1 sibling, 0 replies; 12+ messages in thread
From: Terry Fryar @ 2012-01-20 21:05 UTC (permalink / raw)
  To: 'Philippe Gerum'; +Cc: xenomai

Well, nevermind!  I found out I did have code to clear out the irq status
register, and I'm using ioremap, but I was missing the "/4" in my ulong
array dereference...argggg...so the irq status register flags never got
cleared as I was referencing the wrong memory.  When I started going
backwards, I didn't copy this back into the blank handler either, so I had
the same problem.  I also had a global var scope conflict with the kernel
that was affecting my spinlock in the original isr.  What a mess!

With it all fixed, all the interrupts seem to be working fine now, and with
little load I actually am down to about 1.8us latency...which is great!
Sorry for all the fuss....

Now in the bare metal micro world, you always have to clear the irq flags.
I assume this is always true in a klm isr as well??


-----Original Message-----
From: Philippe Gerum [mailto:rpm@xenomai.org] 
Sent: Friday, January 20, 2012 2:47 PM
To: Terry Fryar
Cc: 'Gilles Chanteperdrix'; xenomai@xenomai.org
Subject: Re: [Xenomai-help] rtdm difficulties

On 01/20/2012 08:37 PM, Terry Fryar wrote:
> Ok, I'll try the patch.  A question though...on the beagle, there is a 
> OMAP register GPIO_IRQSTATUSx that I am not manually clearing out.  
> This is the only place to ack an irq I know of...I assumed that was 
> being handled by the kernel?  Or is this what the patch is adding??  
> I'm very new to writing irq handlers, as you can tell!
>
> Honestly, all that's in my current handler is this:
>
> int irqdrv_rtdm_isr(rtdm_irq_t* handle) {
> 	return(RTDM_IRQ_HANDLED);
> }
>
> And here's the register func:
>
> if ((err = rtdm_irq_request(&irqdrv_isr_handle, irqno, 
> irqdrv_rtdm_isr, RTDM_IRQTYPE_EDGE, IRQDRV_NAME, NULL)) == 0)
>     rtdm_irq_enable(&irqdrv_isr_handle);
>
> And I'm running against a square waveform and getting this:
>
> [   56.522948] WARNING: at kernel/softirq.c:137
> __local_bh_enable+0x44/0xac()
> [   56.530153] Modules linked in: vme_pd_drv
> [   56.534399] [<c00566fc>] (unwind_backtrace+0x0/0xe0) from [<c007db0c>]
> (warn_slowpath_common+0x4c/0x64)
> [   56.574419] [<c007db0c>] (warn_slowpath_common+0x4c/0x64) from
> [<c007db3c>] (warn_slowpath_null+0x18/0x1c)
> [   56.584568] [<c007db3c>] (warn_slowpath_null+0x18/0x1c) from
[<c0083138>]
> (__local_bh_enable+0x44/0xac)
> [   56.594425] [<c0083138>] (__local_bh_enable+0x44/0xac) from
[<c008481c>]
> (irq_enter+0x44/0x60)
> [   56.623476] [<c008481c>] (irq_enter+0x44/0x60) from [<c0046018>]
> (asm_do_IRQ+0x18/0x98)
> [   56.631880] [<c0046018>] (asm_do_IRQ+0x18/0x98) from [<c00b9af0>]
> (__ipipe_sync_stage+0x154/0x188)

Make sure to have CONFIG_IPIPE_DEBUG_INTERNAL enabled in your kernel config
btw, this might help.

Gilles, I wonder whether this backtrace could not be the sign of a demux ISR
not going through ipipe_handle_chained_irq()?

>
>
>
>
> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Friday, January 20, 2012 12:32 PM
> To: Terry Fryar
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] rtdm difficulties
>
> On 01/20/2012 07:24 PM, Terry Fryar wrote:
>> Yeh, omap and gpio.....edge irq from a square wave pulse....
>
> Try this patch:
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c 
> index 30cb7d4..114ccf0 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -1272,7 +1272,7 @@ static void gpio_irq_handler(unsigned int irq, 
> struct irq_desc *desc)
>   	u32 retrigger = 0;
>   	int unmasked = 0;
>
> -	desc->irq_data.chip->irq_ack(&desc->irq_data);
> +	desc->irq_data.chip->irq_mask_ack(&desc->irq_data);
>
>   	bank = get_irq_data(irq);
>   #ifdef CONFIG_ARCH_OMAP1
>


--
Philippe.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties...not fixed....
  2012-01-20 20:47         ` Philippe Gerum
  2012-01-20 21:05           ` [Xenomai-help] rtdm difficulties..fixed Terry Fryar
@ 2012-01-20 21:12           ` Terry Fryar
  1 sibling, 0 replies; 12+ messages in thread
From: Terry Fryar @ 2012-01-20 21:12 UTC (permalink / raw)
  To: 'Philippe Gerum'; +Cc: xenomai

Spoke too soon...after about 20 minutes, I got:

[ 1870.675437] WARNING: at kernel/softirq.c:137
__local_bh_enable+0x44/0xac()
[ 1870.682629] Modules linked in: vme_pd_drv [last unloaded: vme_pd_drv]
[ 1870.689415] [<c00566fc>] (unwind_backtrace+0x0/0xe0) from [<c007db0c>]
(warn_slowpath_common+0x4c/0x64)
[ 1870.871240] [<c007db0c>] (warn_slowpath_common+0x4c/0x64) from
[<c007db3c>] (warn_slowpath_null+0x18/0x1c)
[ 1870.881352] [<c007db3c>] (warn_slowpath_null+0x18/0x1c) from [<c0083138>]
(__local_bh_enable+0x44/0xac)
[ 1871.271582] [<c0083138>] (__local_bh_enable+0x44/0xac) from [<c008481c>]
(irq_enter+0x44/0x60)
[ 1871.280600] [<c008481c>] (irq_enter+0x44/0x60) from [<c0046018>]
(asm_do_IRQ+0x18/0x98)
[ 1871.288987] [<c0046018>] (asm_do_IRQ+0x18/0x98) from [<c00b9af0>]
(__ipipe_sync_stage+0x154/0x188)

Guess I'll turn on all the debugging and see what pops....dang..... 

-----Original Message-----
From: Philippe Gerum [mailto:rpm@xenomai.org] 
Sent: Friday, January 20, 2012 2:47 PM
To: Terry Fryar
Cc: 'Gilles Chanteperdrix'; xenomai@xenomai.org
Subject: Re: [Xenomai-help] rtdm difficulties

On 01/20/2012 08:37 PM, Terry Fryar wrote:
> Ok, I'll try the patch.  A question though...on the beagle, there is a 
> OMAP register GPIO_IRQSTATUSx that I am not manually clearing out.  
> This is the only place to ack an irq I know of...I assumed that was 
> being handled by the kernel?  Or is this what the patch is adding??  
> I'm very new to writing irq handlers, as you can tell!
>
> Honestly, all that's in my current handler is this:
>
> int irqdrv_rtdm_isr(rtdm_irq_t* handle) {
> 	return(RTDM_IRQ_HANDLED);
> }
>
> And here's the register func:
>
> if ((err = rtdm_irq_request(&irqdrv_isr_handle, irqno, 
> irqdrv_rtdm_isr, RTDM_IRQTYPE_EDGE, IRQDRV_NAME, NULL)) == 0)
>     rtdm_irq_enable(&irqdrv_isr_handle);
>
> And I'm running against a square waveform and getting this:
>
> [   56.522948] WARNING: at kernel/softirq.c:137
> __local_bh_enable+0x44/0xac()
> [   56.530153] Modules linked in: vme_pd_drv
> [   56.534399] [<c00566fc>] (unwind_backtrace+0x0/0xe0) from [<c007db0c>]
> (warn_slowpath_common+0x4c/0x64)
> [   56.574419] [<c007db0c>] (warn_slowpath_common+0x4c/0x64) from
> [<c007db3c>] (warn_slowpath_null+0x18/0x1c)
> [   56.584568] [<c007db3c>] (warn_slowpath_null+0x18/0x1c) from
[<c0083138>]
> (__local_bh_enable+0x44/0xac)
> [   56.594425] [<c0083138>] (__local_bh_enable+0x44/0xac) from
[<c008481c>]
> (irq_enter+0x44/0x60)
> [   56.623476] [<c008481c>] (irq_enter+0x44/0x60) from [<c0046018>]
> (asm_do_IRQ+0x18/0x98)
> [   56.631880] [<c0046018>] (asm_do_IRQ+0x18/0x98) from [<c00b9af0>]
> (__ipipe_sync_stage+0x154/0x188)

Make sure to have CONFIG_IPIPE_DEBUG_INTERNAL enabled in your kernel config
btw, this might help.

Gilles, I wonder whether this backtrace could not be the sign of a demux ISR
not going through ipipe_handle_chained_irq()?

>
>
>
>
> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Friday, January 20, 2012 12:32 PM
> To: Terry Fryar
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] rtdm difficulties
>
> On 01/20/2012 07:24 PM, Terry Fryar wrote:
>> Yeh, omap and gpio.....edge irq from a square wave pulse....
>
> Try this patch:
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c 
> index 30cb7d4..114ccf0 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -1272,7 +1272,7 @@ static void gpio_irq_handler(unsigned int irq, 
> struct irq_desc *desc)
>   	u32 retrigger = 0;
>   	int unmasked = 0;
>
> -	desc->irq_data.chip->irq_ack(&desc->irq_data);
> +	desc->irq_data.chip->irq_mask_ack(&desc->irq_data);
>
>   	bank = get_irq_data(irq);
>   #ifdef CONFIG_ARCH_OMAP1
>


--
Philippe.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-20 19:37       ` Terry Fryar
  2012-01-20 20:47         ` Philippe Gerum
@ 2012-01-21 16:05         ` Gilles Chanteperdrix
  2012-01-22 23:32           ` Terry Fryar
  1 sibling, 1 reply; 12+ messages in thread
From: Gilles Chanteperdrix @ 2012-01-21 16:05 UTC (permalink / raw)
  To: Terry Fryar; +Cc: xenomai

On 01/20/2012 08:37 PM, Terry Fryar wrote:
> Ok, I'll try the patch.  A question though...on the beagle, there is a OMAP
> register GPIO_IRQSTATUSx that I am not manually clearing out.  This is the
> only place to ack an irq I know of...I assumed that was being handled by the
> kernel?  Or is this what the patch is adding??  I'm very new to writing irq
> handlers, as you can tell!

I am not sure what you are talking about, but I guess you do not have 
to clear anything on the omap side, the irq demuxing side should take 
care about it.

The problem you have look like the edge irq is ticking to fast, and 
causing an overflow because we are re-enabling irqs in the middle of 
the irq demuxing code. So, if the patch I sent does not solve the 
issue, please try the following one. Note that if the irq is indeed 
ticking to fast, you are going to replace the stack overflow with a 
complete lock-up.

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 30cb7d4..9c9b6d7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1229,13 +1229,14 @@ static void gpio_demux_inner(struct gpio_bank *bank, u32 isr, int nonroot)
 	for (; isr != 0; isr >>= 1, gpio_irq++) {
 		if (!(isr & 1))
 			continue;
-
+#if 0
 #ifdef CONFIG_IPIPE
 		if (nonroot) {
 			local_irq_enable_hw();
 			local_irq_disable_hw();
 		}
 #endif /* CONFIG_IPIPE */
+#endif
 
 #ifdef CONFIG_ARCH_OMAP1
 		gpio_index = get_gpio_index(irq_to_gpio(gpio_irq));
@@ -1308,12 +1309,14 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 		u32 isr_saved, level_mask = 0;
 		u32 enabled;
 
+#if 0
 #ifdef CONFIG_IPIPE
 		if (!bank->nonroot_gpios) {
 			local_irq_enable_hw();
 			local_irq_disable_hw();
 		}
 #endif /* CONFIG_IPIPE */
+#endif
 
 		enabled = _get_gpio_irqbank_mask(bank);
 		isr_saved = isr = __raw_readl(isr_reg) & enabled;

-- 
                                                                Gilles.


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [Xenomai-help] rtdm difficulties
  2012-01-21 16:05         ` [Xenomai-help] rtdm difficulties Gilles Chanteperdrix
@ 2012-01-22 23:32           ` Terry Fryar
  0 siblings, 0 replies; 12+ messages in thread
From: Terry Fryar @ 2012-01-22 23:32 UTC (permalink / raw)
  To: 'Gilles Chanteperdrix'; +Cc: xenomai

I think the irq ticking to fast is correct....these are firing very, very
quickly, and if I clear out the irq flag register myself in the isr, it
works for quite a while.  If I don't, the stack overflows pretty fast.  I'll
try both patches and report back.

I'm not sure what the kernel does with the irq status register in the omap
code, but if this was a microprocessor binary, I'd have to reset the
register flags in my isr myself, since there's no o/s to do it.  I wasn't
sure in the linux world if this was required...I assumed it was not, as you
said, but clearing it out in the middle of the isr does help prevent so many
irq's from ticking and greatly improves the odds against a stack overflow.
I have noticed I am now (with little load) able to have irq latency around
1.8us....pretty fast!

I'll let you know how the patches fare......

Thanks Gilles & Philippe!!  Your help is always much appreciated!!

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: Saturday, January 21, 2012 10:05 AM
To: Terry Fryar
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] rtdm difficulties

On 01/20/2012 08:37 PM, Terry Fryar wrote:
> Ok, I'll try the patch.  A question though...on the beagle, there is a 
> OMAP register GPIO_IRQSTATUSx that I am not manually clearing out.  
> This is the only place to ack an irq I know of...I assumed that was 
> being handled by the kernel?  Or is this what the patch is adding??  
> I'm very new to writing irq handlers, as you can tell!

I am not sure what you are talking about, but I guess you do not have to
clear anything on the omap side, the irq demuxing side should take care
about it.

The problem you have look like the edge irq is ticking to fast, and causing
an overflow because we are re-enabling irqs in the middle of the irq
demuxing code. So, if the patch I sent does not solve the issue, please try
the following one. Note that if the irq is indeed ticking to fast, you are
going to replace the stack overflow with a complete lock-up.

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index
30cb7d4..9c9b6d7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1229,13 +1229,14 @@ static void gpio_demux_inner(struct gpio_bank *bank,
u32 isr, int nonroot)
 	for (; isr != 0; isr >>= 1, gpio_irq++) {
 		if (!(isr & 1))
 			continue;
-
+#if 0
 #ifdef CONFIG_IPIPE
 		if (nonroot) {
 			local_irq_enable_hw();
 			local_irq_disable_hw();
 		}
 #endif /* CONFIG_IPIPE */
+#endif
 
 #ifdef CONFIG_ARCH_OMAP1
 		gpio_index = get_gpio_index(irq_to_gpio(gpio_irq));
@@ -1308,12 +1309,14 @@ static void gpio_irq_handler(unsigned int irq,
struct irq_desc *desc)
 		u32 isr_saved, level_mask = 0;
 		u32 enabled;
 
+#if 0
 #ifdef CONFIG_IPIPE
 		if (!bank->nonroot_gpios) {
 			local_irq_enable_hw();
 			local_irq_disable_hw();
 		}
 #endif /* CONFIG_IPIPE */
+#endif
 
 		enabled = _get_gpio_irqbank_mask(bank);
 		isr_saved = isr = __raw_readl(isr_reg) & enabled;

-- 
                                                                Gilles.



^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2012-01-22 23:32 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-20 16:17 [Xenomai-help] rtdm difficulties Terry Fryar
2012-01-20 17:03 ` Philippe Gerum
2012-01-20 17:42   ` Terry Fryar
2012-01-20 18:19 ` Gilles Chanteperdrix
2012-01-20 18:24   ` Terry Fryar
2012-01-20 18:32     ` Gilles Chanteperdrix
2012-01-20 19:37       ` Terry Fryar
2012-01-20 20:47         ` Philippe Gerum
2012-01-20 21:05           ` [Xenomai-help] rtdm difficulties..fixed Terry Fryar
2012-01-20 21:12           ` [Xenomai-help] rtdm difficulties...not fixed Terry Fryar
2012-01-21 16:05         ` [Xenomai-help] rtdm difficulties Gilles Chanteperdrix
2012-01-22 23:32           ` Terry Fryar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.