Re: [Xenomai-help] rtdm difficulties
I think the irq ticking to fast is correctthese 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.8uspretty 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.chanteperd...@xenomai.org]
Sent: Saturday, January 21, 2012 10:05 AM
To: Terry Fryar
Cc: xenomai-help@gna.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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rtdm difficulties...not fixed....
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] [] (unwind_backtrace+0x0/0xe0) from []
(warn_slowpath_common+0x4c/0x64)
[ 1870.871240] [] (warn_slowpath_common+0x4c/0x64) from
[] (warn_slowpath_null+0x18/0x1c)
[ 1870.881352] [] (warn_slowpath_null+0x18/0x1c) from []
(__local_bh_enable+0x44/0xac)
[ 1871.271582] [] (__local_bh_enable+0x44/0xac) from []
(irq_enter+0x44/0x60)
[ 1871.280600] [] (irq_enter+0x44/0x60) from []
(asm_do_IRQ+0x18/0x98)
[ 1871.288987] [] (asm_do_IRQ+0x18/0x98) from []
(__ipipe_sync_stage+0x154/0x188)
Guess I'll turn on all the debugging and see what popsdang.
-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Friday, January 20, 2012 2:47 PM
To: Terry Fryar
Cc: 'Gilles Chanteperdrix'; xenomai-help@gna.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] [] (unwind_backtrace+0x0/0xe0) from []
> (warn_slowpath_common+0x4c/0x64)
> [ 56.574419] [] (warn_slowpath_common+0x4c/0x64) from
> [] (warn_slowpath_null+0x18/0x1c)
> [ 56.584568] [] (warn_slowpath_null+0x18/0x1c) from
[]
> (__local_bh_enable+0x44/0xac)
> [ 56.594425] [] (__local_bh_enable+0x44/0xac) from
[]
> (irq_enter+0x44/0x60)
> [ 56.623476] [] (irq_enter+0x44/0x60) from []
> (asm_do_IRQ+0x18/0x98)
> [ 56.631880] [] (asm_do_IRQ+0x18/0x98) from []
> (__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.chanteperd...@xenomai.org]
> Sent: Friday, January 20, 2012 12:32 PM
> To: Terry Fryar
> Cc: xenomai-help@gna.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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rtdm difficulties..fixed...
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...ar...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:r...@xenomai.org]
Sent: Friday, January 20, 2012 2:47 PM
To: Terry Fryar
Cc: 'Gilles Chanteperdrix'; xenomai-help@gna.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] [] (unwind_backtrace+0x0/0xe0) from []
> (warn_slowpath_common+0x4c/0x64)
> [ 56.574419] [] (warn_slowpath_common+0x4c/0x64) from
> [] (warn_slowpath_null+0x18/0x1c)
> [ 56.584568] [] (warn_slowpath_null+0x18/0x1c) from
[]
> (__local_bh_enable+0x44/0xac)
> [ 56.594425] [] (__local_bh_enable+0x44/0xac) from
[]
> (irq_enter+0x44/0x60)
> [ 56.623476] [] (irq_enter+0x44/0x60) from []
> (asm_do_IRQ+0x18/0x98)
> [ 56.631880] [] (asm_do_IRQ+0x18/0x98) from []
> (__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.chanteperd...@xenomai.org]
> Sent: Friday, January 20, 2012 12:32 PM
> To: Terry Fryar
> Cc: xenomai-help@gna.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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
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] [] (unwind_backtrace+0x0/0xe0) from []
(warn_slowpath_common+0x4c/0x64)
[ 56.574419] [] (warn_slowpath_common+0x4c/0x64) from
[] (warn_slowpath_null+0x18/0x1c)
[ 56.584568] [] (warn_slowpath_null+0x18/0x1c) from []
(__local_bh_enable+0x44/0xac)
[ 56.594425] [] (__local_bh_enable+0x44/0xac) from []
(irq_enter+0x44/0x60)
[ 56.623476] [] (irq_enter+0x44/0x60) from []
(asm_do_IRQ+0x18/0x98)
[ 56.631880] [] (asm_do_IRQ+0x18/0x98) from []
(__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.chanteperd...@xenomai.org]
Sent: Friday, January 20, 2012 12:32 PM
To: Terry Fryar
Cc: xenomai-help@gna.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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rtdm difficulties
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] [] (unwind_backtrace+0x0/0xe0) from []
(warn_slowpath_common+0x4c/0x64)
[ 56.574419] [] (warn_slowpath_common+0x4c/0x64) from
[] (warn_slowpath_null+0x18/0x1c)
[ 56.584568] [] (warn_slowpath_null+0x18/0x1c) from []
(__local_bh_enable+0x44/0xac)
[ 56.594425] [] (__local_bh_enable+0x44/0xac) from []
(irq_enter+0x44/0x60)
[ 56.623476] [] (irq_enter+0x44/0x60) from []
(asm_do_IRQ+0x18/0x98)
[ 56.631880] [] (asm_do_IRQ+0x18/0x98) from []
(__ipipe_sync_stage+0x154/0x188)
-Original Message-
From: Gilles Chanteperdrix [mailto:gilles.chanteperd...@xenomai.org]
Sent: Friday, January 20, 2012 12:32 PM
To: Terry Fryar
Cc: xenomai-help@gna.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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rtdm difficulties
Yeh, omap and gpio.edge irq from a square wave pulse -Original Message- From: Gilles Chanteperdrix [mailto:gilles.chanteperd...@xenomai.org] Sent: Friday, January 20, 2012 12:20 PM To: Terry Fryar Cc: xenomai-help@gna.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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rtdm difficulties
Now I'm seeing this. I have lost complete control at this pointargh [ 149.017562] WARNING: at kernel/softirq.c:137 __local_bh_enable+0x44/0xac() [ 149.024765] Modules linked in: vme_pd_drv [ 149.029014] [] (unwind_backtrace+0x0/0xe0) from [] (warn_slowpath_common+0x4c/0x64) [ 149.038892] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x18/0x1c) [ 149.049019] [] (warn_slowpath_null+0x18/0x1c) from [] (__local_bh_enable+0x44/0xac) [ 149.118865] [] (__local_bh_enable+0x44/0xac) from [] (irq_enter+0x44/0x60) [ 149.127899] [] (irq_enter+0x44/0x60) from [] (asm_do_IRQ+0x18/0x98) [ 149.136302] [] (asm_do_IRQ+0x18/0x98) from [] (__ipipe_sync_stage+0x154/0x188) -Original Message- From: Philippe Gerum [mailto:r...@xenomai.org] Sent: Friday, January 20, 2012 11:04 AM To: xenomai-help@gna.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= [ 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 : [] lr : > [] psr: a113 [ 796.384740] sp : c058f1c8 ip : fb02 > fp : 031b [ 796.396765] r10: 0005 r9 : 2113 r8 : > [ 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: 0017 [ > 796.519769] Process ü (pid: -598785, stack limit = 0xc058e2f0) UhOh... This very muck looks like stack overflow / corruption. > > > > ___ > Xenomai-help mailing list > Xenomai-help@gna.org > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
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= [ 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 : [] lr : [] psr: a113 [ 796.384740] sp : c058f1c8 ip : fb02 fp : 031b [ 796.396765] r10: 0005 r9 : 2113 r8 : [ 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: 0017 [ 796.519769] Process ü (pid: -598785, stack limit = 0xc058e2f0) UhOh... This very muck looks like stack overflow / corruption. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] rtdm difficulties
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= [ 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: 0Not 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 : []lr : []psr: a113 [ 796.384740] sp : c058f1c8 ip : fb02 fp : 031b [ 796.396765] r10: 0005 r9 : 2113 r8 : [ 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: 0017 [ 796.519769] Process ü (pid: -598785, stack limit = 0xc058e2f0) ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
