date:20120120

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

2012-01-20 Thread Manfred


Hi All,

I tested the patch on my omap3630 and I ran the cross-link test.
It works. I want to thank Fabrice Gasnier from my side.

I have, however, the following suggestions/questions to the patch:
- If I got it right, the errata only affects the RX_fifo (not the 
tx_fifo), so I suggest to handle those cases separately and usually call 
the normal reg_in, and put the cases were we access RHR in "#ifdef 
omap"-clauses

- There is however another errata (or 'quirk') about the mdr1 register
http://www.ti.com/pdfs/wtbu/SWPZ017B_4460_Public_SE.pdf
but I don't think that this register is ever touched by the xeno_16550A 
driver. (If we would touch it in the future, one would have to add 
#ifdef clauses and use omapsafe_reg_out)
- in the mach-omap2/serial.c  in function "serial_out_override" there is 
this 10ms timeout-value, which should probably be avoided at any cost 
(it will increase the latency). I actually don't see why we should wait 
for the transmit_fifo to empty. Why is this necc.? Is there still 
another errata about the tx_fifo?


So I suggest to usually call the normal reg_out (formerly 
omap_raw_reg_out) and only call the modified one when necc. (now renamed 
to omapsafe_reg_out)


I have made the changes along these lines and attached them in a patch. 
(this patch is to be applied after the patch from Fabrice Gasnier)


When I compare the timings between the original patch and with my latest 
changes (using cross-link and creating load with dohell -s ) I 
get about 25% better timings under load. (I only ran each test once for 
3min each, though). Without load, there is of course no big change in 
the latencies.


@Fabrice: Can you check with cross-link.c on your platform? I get 
worst-case timings of 150micros with your patch, and 115micros with my 
additional changes. (I think these are round-trip timings, but I am not 
sure)


Let me know, what you think.
Regards
Manfred

On 1/19/12 6:09 PM, Fabrice Gasnier wrote:

Finally, I find out that UART was in sleep mode.
According to omap's reference manual, it enters this mode when conditions are 
met:
rx line is idle,
tx fifo and shift register are empty,
rx fifo is empty
no interrupts pending

One solution that i've tested successfully is to disable sleep mode in 
rt_16550_open().

> TX interrupts are then being triggered as expected.


other quirks, see:

http://lxr.linux.no/#linux+v3.2.1/arch/arm/mach-omap2/serial.c#L742

Thank you for this link! It helps handle the fifo full condition.
However, I noticed a strange value regarding version register. My omap3530 
reports 0x46?
Linux serial driver assume this bug is present on revision>= 0x52 ...
But my target freeze when I send more than 16 chars at once (Fifo full without 
errata handling).
It works when using errata handling.




You'll find attached a patch that works for me.
Please advise. Maybe we can enhance it and push it?

Thanks!
Regards,

Fabrice
diff --git a/ksrc/drivers/serial/16550A.c b/ksrc/drivers/serial/16550A.c
index 81c7b70..8eb9bdb 100644
--- a/ksrc/drivers/serial/16550A.c
+++ b/ksrc/drivers/serial/16550A.c
@@ -175,7 +175,12 @@ static inline int rt_16550_rx_interrupt(struct 
rt_16550_context *ctx,
int c;
 
do {
+#if defined (CONFIG_ARCH_OMAP3) || \
+defined (CONFIG_ARCH_OMAP4)
+   c = rt_16550_omapsafe_reg_in(mode, base, regshift, RHR);
/* read input char */
+#else
c = rt_16550_reg_in(mode, base, regshift, RHR); /* read input 
char */
+#endif
 
ctx->in_buf[ctx->in_tail] = c;
if (ctx->in_history)
@@ -568,7 +573,12 @@ int rt_16550_close(struct rtdm_dev_context *context,
rt_16550_reg_out(mode, base, regshift, IER, 0);
rt_16550_reg_in(mode, base, regshift, IIR);
rt_16550_reg_in(mode, base, regshift, LSR);
+#if defined (CONFIG_ARCH_OMAP3) || \
+defined (CONFIG_ARCH_OMAP4)
+   rt_16550_omapsafe_reg_in(mode, base, regshift, RHR);
+#else
rt_16550_reg_in(mode, base, regshift, RHR);
+#endif
rt_16550_reg_in(mode, base, regshift, MSR);
 
in_history = ctx->in_history;
@@ -810,7 +820,12 @@ int rt_16550_ioctl(struct rtdm_dev_context *context,
ctx->in_npend = 0;
ctx->status = 0;
fcr |= FCR_FIFO | FCR_RESET_RX;
+#if defined (CONFIG_ARCH_OMAP3) || \
+defined (CONFIG_ARCH_OMAP4)
+   rt_16550_omapsafe_reg_in(mode, base, regshift, RHR);
+#else
rt_16550_reg_in(mode, base, regshift, RHR);
+#endif
}
if ((long)arg & RTDM_PURGE_TX_BUFFER) {
ctx->out_head = 0;
@@ -1204,7 +1219,12 @@ int __init rt_16550_init(void)
rt_16550_reg_out(mode, base, regshift, IER, 0);
rt_16550_reg_in(mode, base, regshift, IIR);
rt_16550_reg_in(mode, base, regshift, LSR);
+#if defined (CONFIG_ARCH_OMAP3) || \
+defined (CONFIG_ARCH_OMAP4)
+   rt_16550_omapsafe_reg_in(mode,

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

2012-01-20 Thread Fabrice Gasnier

Dear all, Manfred,

Please find interleaved answers/questions.

On 20/01/2012 13:03, Manfred wrote:
> Hi All,
> 
> I tested the patch on my omap3630 and I ran the cross-link test.
> It works. I want to thank Fabrice Gasnier from my side.
you're welcome.
> 
> I have, however, the following suggestions/questions to the patch:
> - If I got it right, the errata only affects the RX_fifo (not the tx_fifo), 
> so I suggest to handle those cases separately and usually call the normal 
> reg_in, and put the cases were we access RHR in "#ifdef omap"-clauses
It also cares about tx fifo full condition: in rt_16550_reg_out():
lsr = rt_16550_omap_raw_reg_in(io_mode, base, rshift, LSR);
while (!(lsr & RTSER_LSR_THR_EMTPY)) {
/* Wait up to 10ms for the character(s) to be sent. */
if(--tmout == 0)
break;
rtdm_task_sleep(1000);
lsr = rt_16550_omap_raw_reg_in(io_mode, base, rshift, LSR);
}

> - There is however another errata (or 'quirk') about the mdr1 register
> http://www.ti.com/pdfs/wtbu/SWPZ017B_4460_Public_SE.pdf
> but I don't think that this register is ever touched by the xeno_16550A 
> driver. (If we would touch it in the future, one would have to add #ifdef 
> clauses and use omapsafe_reg_out)
> - in the mach-omap2/serial.c  in function "serial_out_override" there is this 
> 10ms timeout-value, which should probably be avoided at any cost (it will 
> increase the latency). I actually don't see why we should wait for the 
> transmit_fifo to empty. Why is this necc.? Is there still another errata 
> about the tx_fifo?
I think you're right it adds latencies, but what can we do about this?
e.g. I've made some testing without such a handling: trying to write "lots of" 
bytes (I assume more than fifo size) freezes target. It has to be handled 
somehow. Maybe it's wrong to do this way?
Maybe it would be better to write up to fifo full and then return...
- an error ?
- or just the number of written bytes with no error?
This way responsibility would be let to the caller (writting to much bytes will 
cause a lantency in the end, no ?)
I'm not sure of expected behavior on other platforms such as x86 ?

> 
> So I suggest to usually call the normal reg_out (formerly omap_raw_reg_out) 
> and only call the modified one when necc. (now renamed to omapsafe_reg_out)
> 
> I have made the changes along these lines and attached them in a patch. (this 
> patch is to be applied after the patch from Fabrice Gasnier)
> 
> When I compare the timings between the original patch and with my latest 
> changes (using cross-link and creating load with dohell -s ) I get 
> about 25% better timings under load. (I only ran each test once for 3min 
> each, though). Without load, there is of course no big change in the 
> latencies.
> 
> @Fabrice: Can you check with cross-link.c on your platform? I get worst-case 
> timings of 150micros with your patch, and 115micros with my additional 
> changes. (I think these are round-trip timings, but I am not sure)
I shall try these, but I own a PhyCARD-L that only has one serial port... 
Cannot run cross-link.
> 
> Let me know, what you think.
> Regards
> Manfred
> 
> On 1/19/12 6:09 PM, Fabrice Gasnier wrote:
>> Finally, I find out that UART was in sleep mode.
>> According to omap's reference manual, it enters this mode when conditions 
>> are met:
>> rx line is idle,
>> tx fifo and shift register are empty,
>> rx fifo is empty
>> no interrupts pending
>>
>> One solution that i've tested successfully is to disable sleep mode in 
>> rt_16550_open().
>> TX interrupts are then being triggered as expected.
> 
>>> other quirks, see:
>>>
>>> http://lxr.linux.no/#linux+v3.2.1/arch/arm/mach-omap2/serial.c#L742
>> Thank you for this link! It helps handle the fifo full condition.
>> However, I noticed a strange value regarding version register. My omap3530 
>> reports 0x46?
>> Linux serial driver assume this bug is present on revision>= 0x52 ...
>> But my target freeze when I send more than 16 chars at once (Fifo full 
>> without errata handling).
>> It works when using errata handling.
> 
>>
>> You'll find attached a patch that works for me.
>> Please advise. Maybe we can enhance it and push it?
>>
>> Thanks!
>> Regards,
>>
>> Fabrice

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] ensuring code running in kernel modules has realtime priority

2012-01-20 Thread Benner Bernd (MH/EES)

Hi Roland,

  i think that there is a commercial ethercat master with a xenomai rtdm 
interface available
from koenig ( https://koenig-pa.com )

  We are using a open source linux ethercat master ( 
http://www.etherlab.org/de/ethercat/index.php )
from IGH.

  I have developed a xenomai rtdm realtime interface for this igh ethercat 
master. All sources of this interface are now part of the development tree of 
the IGH- ethercat Master and can be downloaded from the IGH- website.

  My way was to do all initializations and slow non realtime stuff ( SDO etc.) 
with the linux device interface and attach the rtdm driver to the running 
master and port only the "send","receive" and "process domain" ioctrl to rtdm. 
But this will only work if your master will not use the linux network layer.

   The IGH master works, because special patched network drivers are part of 
the project and there is no other linux interfacing in the real time path . ( 
The Igh Master is designed for RTAI )

Mit freundlichen Grüßen / Best Regards
Bernd Benner
MH/SGT3
moehwald
Bosch Group
Moehwald GmbH
Michelinstraße 21
66424 Homburg
GERMANY
www.moehwald.de
Tel.: +49 (0)6841 707-229
b.ben...@moehwald.de
Moehwald GmbH, Sitz/Registered Office: Homburg/Saar, Zentrales 
Handelsregister/Registered Court: Saarbrücken HRB 2812
Geschäftsführung/Managing Directors: Christian Artmann, Wolfgang Geenen

-Ursprüngliche Nachricht-
Von: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] Im 
Auftrag von Gilles Chanteperdrix
Gesendet: Mittwoch, 18. Januar 2012 11:52
An: rolandtollen...@gmail.com
Cc: RT; Xenomai-help@gna.org
Betreff: Re: [Xenomai-help] ensuring code running in kernel modules has 
realtime priority

On 01/18/2012 08:59 AM, RT wrote:
> Hi all,
>
> we have an interesting situation. We are using a module to do
> communication over a network (ethercat master module) to some remote IO.
>
> The ethercat module is loaded against the kernel in the normal manner.
>
> Now we possibly have overlooked that even though the call to the
> ethercat module (ioctl call) from our real-time application takes
> place in a xenomai real time task, the code of the ethercatmodule may
> be interrupted by other processes running on the machine. Due to the
> fact that the modules code is not running in any real-time prioritized space.
>
> If this is indeed the case, what would be the best or easiest manner
> to ensure that the module does not get interrupted, ie. to encapsulate
> it into the xenomai real-time priority sphere?
>
> Hope someone can point us in the right direction here. Its pretty
> urgent because the system is already running live and we are
> intermittently encountering this problem.

If I understand correctly, what you need is to rewrite the ethercat driver as a 
real-time driver using the RTDM skin.

--
Gilles.

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

2012-01-20 Thread Felipe Brandão Cavalcanti

Dear All,

Any chance you guys could make a Gumstix Overo image with Xenomai and the
RTDM drivers working? I was actually going to start working on this very
issue (RTDM drivers for the OMAP) next week, but you seem to have had a
head start on that.

Many thanks!
   -Felipe Brandão Cavalcanti
   LARA - Automation and Robotics Laboratory
   Department of Electrical Engineering
   UnB - University of Brasília, Brazil
   http://www.lara.unb.br/~fbcavalcanti/

On Fri, Jan 20, 2012 at 12:41 PM, Fabrice Gasnier <
fabrice.gasn...@cenosys.com> wrote:

> Dear all, Manfred,
>
> Please find interleaved answers/questions.
>
> On 20/01/2012 13:03, Manfred wrote:
> > Hi All,
> >
> > I tested the patch on my omap3630 and I ran the cross-link test.
> > It works. I want to thank Fabrice Gasnier from my side.
> you're welcome.
> >
> > I have, however, the following suggestions/questions to the patch:
> > - If I got it right, the errata only affects the RX_fifo (not the
> tx_fifo), so I suggest to handle those cases separately and usually call
> the normal reg_in, and put the cases were we access RHR in "#ifdef
> omap"-clauses
> It also cares about tx fifo full condition: in rt_16550_reg_out():
> lsr = rt_16550_omap_raw_reg_in(io_mode, base, rshift, LSR);
> while (!(lsr & RTSER_LSR_THR_EMTPY)) {
>/* Wait up to 10ms for the character(s) to be sent. */
>if(--tmout == 0)
>break;
>rtdm_task_sleep(1000);
>lsr = rt_16550_omap_raw_reg_in(io_mode, base, rshift, LSR);
> }
>
> > - There is however another errata (or 'quirk') about the mdr1 register
> > http://www.ti.com/pdfs/wtbu/SWPZ017B_4460_Public_SE.pdf
> > but I don't think that this register is ever touched by the xeno_16550A
> driver. (If we would touch it in the future, one would have to add #ifdef
> clauses and use omapsafe_reg_out)
> > - in the mach-omap2/serial.c  in function "serial_out_override" there is
> this 10ms timeout-value, which should probably be avoided at any cost (it
> will increase the latency). I actually don't see why we should wait for the
> transmit_fifo to empty. Why is this necc.? Is there still another errata
> about the tx_fifo?
> I think you're right it adds latencies, but what can we do about this?
> e.g. I've made some testing without such a handling: trying to write "lots
> of" bytes (I assume more than fifo size) freezes target. It has to be
> handled somehow. Maybe it's wrong to do this way?
> Maybe it would be better to write up to fifo full and then return...
> - an error ?
> - or just the number of written bytes with no error?
> This way responsibility would be let to the caller (writting to much bytes
> will cause a lantency in the end, no ?)
> I'm not sure of expected behavior on other platforms such as x86 ?
>
> >
> > So I suggest to usually call the normal reg_out (formerly
> omap_raw_reg_out) and only call the modified one when necc. (now renamed to
> omapsafe_reg_out)
> >
> > I have made the changes along these lines and attached them in a patch.
> (this patch is to be applied after the patch from Fabrice Gasnier)
> >
> > When I compare the timings between the original patch and with my latest
> changes (using cross-link and creating load with dohell -s ) I
> get about 25% better timings under load. (I only ran each test once for
> 3min each, though). Without load, there is of course no big change in the
> latencies.
> >
> > @Fabrice: Can you check with cross-link.c on your platform? I get
> worst-case timings of 150micros with your patch, and 115micros with my
> additional changes. (I think these are round-trip timings, but I am not
> sure)
> I shall try these, but I own a PhyCARD-L that only has one serial port...
> Cannot run cross-link.
> >
> > Let me know, what you think.
> > Regards
> > Manfred
> >
> > On 1/19/12 6:09 PM, Fabrice Gasnier wrote:
> >> Finally, I find out that UART was in sleep mode.
> >> According to omap's reference manual, it enters this mode when
> conditions are met:
> >> rx line is idle,
> >> tx fifo and shift register are empty,
> >> rx fifo is empty
> >> no interrupts pending
> >>
> >> One solution that i've tested successfully is to disable sleep mode in
> rt_16550_open().
> >> TX interrupts are then being triggered as expected.
> >
> >>> other quirks, see:
> >>>
> >>> http://lxr.linux.no/#linux+v3.2.1/arch/arm/mach-omap2/serial.c#L742
> >> Thank you for this link! It helps handle the fifo full condition.
> >> However, I noticed a strange value regarding version register. My
> omap3530 reports 0x46?
> >> Linux serial driver assume this bug is present on revision>= 0x52 ...
> >> But my target freeze when I send more than 16 chars at once (Fifo full
> without errata handling).
> >> It works when using errata handling.
> >
> >>
> >> You'll find attached a patch that works for me.
> >> Please advise. Maybe we can enhance it and push it?
> >>
> >> Thanks!
> >> Regards,
> >>
> >> Fabrice
>
> ___
> Xenoma

[Xenomai-help] rtdm difficulties

2012-01-20 Thread Terry Fryar

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

Re: [Xenomai-help] rtdm difficulties

2012-01-20 Thread Philippe Gerum


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] troubles with library inclusion

2012-01-20 Thread Jakub Nowacki


On 11 Jan 2012, at 22:53, Gilles Chanteperdrix wrote:

> On 01/11/2012 11:49 PM, Daniele wrote:
>> Hello,
>> 
>> We are trying to use xenomai with analogy library
>> 
>> [xenomai 2.6.0, kernel 2.6.38.8]
>> 
>> Compiling the program  we got the following error:
>> 
>> 
>> "undefined reference to
>> a4l_open
>> "
>> 
>> The compiler detects correctly the function prototypes but it can't found
>> their complete definition.
>> 
>> taking care of our MakeFile we also have read this:
>> 
>> https://mail.gna.org/public/xenomai-help/2011-07/msg00036.html
>> 
>> but we noticed that our makefile already contains this instructions for our
>> skin, native.
>> 
>> How could we get rid of this?
> 
> You need to link with the libanalogy driver, so, simply add "-lanalogy"
> on the compiler command line.
> 

I had a similar problem. Namely, it was complaining about having undefined 
reference. I added the -lanalogy to the flags generated with 'xeno-config 
--skin=native --ldflags' and everything compiled and linked correctly, but when 
I start my application I get error:

/usr/xenomai/lib/libanalogy.so.1: undefined symbol: rt_dev_ioctl

I after adding -lrtdm after -lanalogy everything, again, complied and linked 
correctly, but I get new error:

librtdm.so.1: shared object cannot be dlopen()ed

If I add -lrtdm before -lanalogy, I get the previous undefined symbol. To be 
absolutely sure I don't have a problem with my Xenomai-2.6.0 setup, I 
recompiled and installed it, but I'm still getting the errors. It does not seem 
to be a problem with other Xenomai shared objects path, since other SO are 
loaded correctly (Xenomai native skin threads work fine).

Thanks for the help in advance.

Best wishes,

Jakub
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] rtdm difficulties

2012-01-20 Thread Terry Fryar

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] Omap3630, rtserial, xeno_16550A: crash on insmod

2012-01-20 Thread Wolfgang Grandegger

Hi Fabrice and Manfred,

On 01/19/2012 06:09 PM, Fabrice Gasnier wrote:
> On 18/01/2012 17:32, Wolfgang Grandegger wrote:
>>> Further investigation indicates that when writing, tx interrupt is not 
>>> asserted as expected (rt_16550_write):
 /* unmask tx interrupt */
 ctx->ier_status |= IER_TX;
 rt_16550_reg_out(rt_16550_io_mode_from_ctx(ctx),
 ctx->base_addr, IER,
 ctx->ier_status,
 ctx->regshift);

 >From my understanding this should trigger an irq for data to be put in 
 >rt_16550_tx_interrupt().
 It seems this is not always the case. Moreover, TX interrupt seem to be 
 triggered by a new RX interrupt.
>> The TX interrupt will be enabled as long as there are chars to send,
>> IIRC. The isr the puts the chars into the FIFO and triggers the xfer.
> Finally, I find out that UART was in sleep mode.
> According to omap's reference manual, it enters this mode when conditions are 
> met:
> rx line is idle,
> tx fifo and shift register are empty,
> rx fifo is empty
> no interrupts pending
> 
> One solution that i've tested successfully is to disable sleep mode in 
> rt_16550_open(). TX interrupts are then being triggered as expected.
>>

 Would you have an explanation for such a behavior?
 I'm not sure how to solve this.
>> Depending on the hardware/uart revision, you may need to take care of
>> other quirks, see:
>>
>> http://lxr.linux.no/#linux+v3.2.1/arch/arm/mach-omap2/serial.c#L742
> Thank you for this link! It helps handle the fifo full condition.
> However, I noticed a strange value regarding version register. My omap3530 
> reports 0x46?
> Linux serial driver assume this bug is present on revision >= 0x52 ...
> But my target freeze when I send more than 16 chars at once (Fifo full 
> without errata handling).
> It works when using errata handling.

It seems the 16550-compatible UARTs on the OMAP processor are special
and also buggy requiring more or less heavy workarounds, unfortunately.
I can't comment on that as I do not have experience with OMAP processors.

> You'll find attached a patch that works for me.
> Please advise. Maybe we can enhance it and push it?

To handle hardware-specific initialization I/O properly, I think we need
first a more flexible interface using callback functions. The existing
interface with

base = ctx->base_addr;
mode = rt_16550_io_mode_from_ctx(ctx);
regshift = ctx->regshift;
rt_16550_reg_in(mode, base, regshift, offset)",

#ifdef's and switch statements in the I/O functions is really horrible.
A more elegant solution would make integration of the OMAP specialities
much easier.

Wolfgang.


___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] rtdm difficulties

2012-01-20 Thread Gilles Chanteperdrix

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] troubles with library inclusion

2012-01-20 Thread Gilles Chanteperdrix

On 01/20/2012 06:18 PM, Jakub Nowacki wrote:
> 
> On 11 Jan 2012, at 22:53, Gilles Chanteperdrix wrote:
> 
>> On 01/11/2012 11:49 PM, Daniele wrote:
>>> Hello,
>>> 
>>> We are trying to use xenomai with analogy library
>>> 
>>> [xenomai 2.6.0, kernel 2.6.38.8]
>>> 
>>> Compiling the program  we got the following error:
>>> 
>>> 
>>> "undefined reference to 
>>> a4l_open
>>>
>>> 
"
>>> 
>>> The compiler detects correctly the function prototypes but it
>>> can't found their complete definition.
>>> 
>>> taking care of our MakeFile we also have read this:
>>> 
>>> https://mail.gna.org/public/xenomai-help/2011-07/msg00036.html
>>> 
>>> but we noticed that our makefile already contains this
>>> instructions for our skin, native.
>>> 
>>> How could we get rid of this?
>> 
>> You need to link with the libanalogy driver, so, simply add
>> "-lanalogy" on the compiler command line.
>> 
> 
> I had a similar problem. Namely, it was complaining about having
> undefined reference. I added the -lanalogy to the flags generated
> with 'xeno-config --skin=native --ldflags' and everything compiled
> and linked correctly, but when I start my application I get error:
> 
> /usr/xenomai/lib/libanalogy.so.1: undefined symbol: rt_dev_ioctl
> 
> I after adding -lrtdm after -lanalogy everything, again, complied and
> linked correctly, but I get new error:
> 
> librtdm.so.1: shared object cannot be dlopen()ed

If you need to dlopen librtdm, please reconfigure xenomai passing:
--enable-dlopen-skins

-- 
Gilles.

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] rtdm difficulties

2012-01-20 Thread Terry Fryar

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

2012-01-20 Thread Gilles Chanteperdrix

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] Omap3630, rtserial, xeno_16550A: crash on insmod

2012-01-20 Thread Gilles Chanteperdrix

On 01/20/2012 07:03 PM, Wolfgang Grandegger wrote:
> Hi Fabrice and Manfred,
> 
> On 01/19/2012 06:09 PM, Fabrice Gasnier wrote:
>> On 18/01/2012 17:32, Wolfgang Grandegger wrote:
 Further investigation indicates that when writing, tx interrupt is not 
 asserted as expected (rt_16550_write):
> /* unmask tx interrupt */
> ctx->ier_status |= IER_TX;
> rt_16550_reg_out(rt_16550_io_mode_from_ctx(ctx),
>ctx->base_addr, IER,
>ctx->ier_status,
>ctx->regshift);
>
> >From my understanding this should trigger an irq for data to be put in 
> >rt_16550_tx_interrupt().
> It seems this is not always the case. Moreover, TX interrupt seem to be 
> triggered by a new RX interrupt.
>>> The TX interrupt will be enabled as long as there are chars to send,
>>> IIRC. The isr the puts the chars into the FIFO and triggers the xfer.
>> Finally, I find out that UART was in sleep mode.
>> According to omap's reference manual, it enters this mode when conditions 
>> are met:
>> rx line is idle,
>> tx fifo and shift register are empty,
>> rx fifo is empty
>> no interrupts pending
>>
>> One solution that i've tested successfully is to disable sleep mode in 
>> rt_16550_open(). TX interrupts are then being triggered as expected.
>>>
>
> Would you have an explanation for such a behavior?
> I'm not sure how to solve this.
>>> Depending on the hardware/uart revision, you may need to take care of
>>> other quirks, see:
>>>
>>> http://lxr.linux.no/#linux+v3.2.1/arch/arm/mach-omap2/serial.c#L742
>> Thank you for this link! It helps handle the fifo full condition.
>> However, I noticed a strange value regarding version register. My omap3530 
>> reports 0x46?
>> Linux serial driver assume this bug is present on revision >= 0x52 ...
>> But my target freeze when I send more than 16 chars at once (Fifo full 
>> without errata handling).
>> It works when using errata handling.
> 
> It seems the 16550-compatible UARTs on the OMAP processor are special
> and also buggy requiring more or less heavy workarounds, unfortunately.
> I can't comment on that as I do not have experience with OMAP processors.
> 
>> You'll find attached a patch that works for me.
>> Please advise. Maybe we can enhance it and push it?
> 
> To handle hardware-specific initialization I/O properly, I think we need
> first a more flexible interface using callback functions. The existing
> interface with
> 
>   base = ctx->base_addr;
>   mode = rt_16550_io_mode_from_ctx(ctx);
>   regshift = ctx->regshift;
>   rt_16550_reg_in(mode, base, regshift, offset)",
> 
> #ifdef's and switch statements in the I/O functions is really horrible.
> A more elegant solution would make integration of the OMAP specialities
> much easier.

I will wait for Wolfgang's ack before merging anything, then.

-- 
Gilles.

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

2012-01-20 Thread Wolfgang Grandegger

On 01/20/2012 07:46 PM, Gilles Chanteperdrix wrote:
> On 01/20/2012 07:03 PM, Wolfgang Grandegger wrote:
>> Hi Fabrice and Manfred,
>>
>> On 01/19/2012 06:09 PM, Fabrice Gasnier wrote:
>>> On 18/01/2012 17:32, Wolfgang Grandegger wrote:
> Further investigation indicates that when writing, tx interrupt is not 
> asserted as expected (rt_16550_write):
>> /* unmask tx interrupt */
>> ctx->ier_status |= IER_TX;
>> rt_16550_reg_out(rt_16550_io_mode_from_ctx(ctx),
>>   ctx->base_addr, IER,
>>   ctx->ier_status,
>>   ctx->regshift);
>>
>> >From my understanding this should trigger an irq for data to be put in 
>> >rt_16550_tx_interrupt().
>> It seems this is not always the case. Moreover, TX interrupt seem to be 
>> triggered by a new RX interrupt.
 The TX interrupt will be enabled as long as there are chars to send,
 IIRC. The isr the puts the chars into the FIFO and triggers the xfer.
>>> Finally, I find out that UART was in sleep mode.
>>> According to omap's reference manual, it enters this mode when conditions 
>>> are met:
>>> rx line is idle,
>>> tx fifo and shift register are empty,
>>> rx fifo is empty
>>> no interrupts pending
>>>
>>> One solution that i've tested successfully is to disable sleep mode in 
>>> rt_16550_open(). TX interrupts are then being triggered as expected.

>>
>> Would you have an explanation for such a behavior?
>> I'm not sure how to solve this.
 Depending on the hardware/uart revision, you may need to take care of
 other quirks, see:

 http://lxr.linux.no/#linux+v3.2.1/arch/arm/mach-omap2/serial.c#L742
>>> Thank you for this link! It helps handle the fifo full condition.
>>> However, I noticed a strange value regarding version register. My omap3530 
>>> reports 0x46?
>>> Linux serial driver assume this bug is present on revision >= 0x52 ...
>>> But my target freeze when I send more than 16 chars at once (Fifo full 
>>> without errata handling).
>>> It works when using errata handling.
>>
>> It seems the 16550-compatible UARTs on the OMAP processor are special
>> and also buggy requiring more or less heavy workarounds, unfortunately.
>> I can't comment on that as I do not have experience with OMAP processors.
>>
>>> You'll find attached a patch that works for me.
>>> Please advise. Maybe we can enhance it and push it?
>>
>> To handle hardware-specific initialization I/O properly, I think we need
>> first a more flexible interface using callback functions. The existing
>> interface with
>>
>>  base = ctx->base_addr;
>>  mode = rt_16550_io_mode_from_ctx(ctx);
>>  regshift = ctx->regshift;
>>  rt_16550_reg_in(mode, base, regshift, offset)",
>>
>> #ifdef's and switch statements in the I/O functions is really horrible.
>> A more elegant solution would make integration of the OMAP specialities
>> much easier.
> 
> I will wait for Wolfgang's ack before merging anything, then.

Well, I'm actually not the maintainer. Jan?

Wolfgang.



___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] rtdm difficulties

2012-01-20 Thread Terry Fryar

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

2012-01-20 Thread Philippe Gerum


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...

2012-01-20 Thread Terry Fryar

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...not fixed....

2012-01-20 Thread Terry Fryar

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] troubles with library inclusion

2012-01-20 Thread Jakub Nowacki


On 20/01/12 18:22, Gilles Chanteperdrix wrote:

If you need to dlopen librtdm, please reconfigure xenomai passing:
--enable-dlopen-skins


Problem solved! Thanks a lot!

Cheers,

Jakub

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

Re: [Xenomai-help] ensuring code running in kernel modules has realtime priority

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

[Xenomai-help] rtdm difficulties

Re: [Xenomai-help] rtdm difficulties

Re: [Xenomai-help] troubles with library inclusion

Re: [Xenomai-help] rtdm difficulties

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

Re: [Xenomai-help] rtdm difficulties

Re: [Xenomai-help] troubles with library inclusion

Re: [Xenomai-help] rtdm difficulties

Re: [Xenomai-help] rtdm difficulties

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

Re: [Xenomai-help] Omap3630, rtserial, xeno_16550A: crash on insmod

Re: [Xenomai-help] rtdm difficulties

Re: [Xenomai-help] rtdm difficulties

Re: [Xenomai-help] rtdm difficulties..fixed...

Re: [Xenomai-help] rtdm difficulties...not fixed....

Re: [Xenomai-help] troubles with library inclusion

20 matches

Site Navigation

Mail list logo

Footer information