headers
Mitchell Tasman | 2 Feb 2012 01:53
Picon

Handler executed on behalf of rtdm_nrtsig_pend() appears to be running in Linux hardirq, rather than softirq, context

Xenomai documents rtdm_nrtsig_pend() as follows:

> The signal handler will run in soft-IRQ context of the non-real-time subsystem. Note the implications of
this context, e.g. no invocation of blocking operations.

As a result, I would have anticipated that when invoked from within the 
signal handler, in_irq() would return 0, while in_softirq() would return 
non-zero.

Instead, I've found that in_irq() returns the value 0x10000, which 
(digging around in include/linux/hardirq.h) indicates that the hardirq 
count is 1.

A partial Linux kernel stack backtrace, leading up to execution of the 
signal handler, is as follows:

> [  217.844177] [<bf031838>] (my_signalClient+0x24/0x48 [my_rtdm_driver]) from [<c00df42c>] (__ipipe_sync_stage+0x164/0x198)
> [  217.844207] [<c00df42c>] (__ipipe_sync_stage+0x164/0x198) from [<c0058960>] (ipipe_trigger_irq+0x14/0x20)
> [  217.844238] [<c0058960>] (ipipe_trigger_irq+0x14/0x20) from [<c011ca78>] (gatekeeper_thread+0x1ac/0x398)

It seems that there are at least several possibilities:

1.  I've misunderstood the documentation, and the signal handler is 
intended to run in Linux hardirq context.  If so, and I need softirq 
context, I'd need to schedule a tasklet from within the signal handler.

2.  There's something broken about my specific environment.  I am 
presently using a Beagleboard xM Rev C, running a TI 2.6.37-derived OMAP 
kernel from the staging tree on Arago, with a tailored (by me) version 
of the ARM I-pipe patchset for 2.6.37.6 that ships with Xenomai-2.6.0.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philippe Gerum | 2 Feb 2012 10:03
Favicon

Re: Handler executed on behalf of rtdm_nrtsig_pend() appears to be running in Linux hardirq, rather than softirq, context

On 02/02/2012 01:53 AM, Mitchell Tasman wrote:
> Xenomai documents rtdm_nrtsig_pend() as follows:
>
>> The signal handler will run in soft-IRQ context of the non-real-time
>> subsystem. Note the implications of this context, e.g. no invocation
>> of blocking operations.
>
> As a result, I would have anticipated that when invoked from within the
> signal handler, in_irq() would return 0, while in_softirq() would return
> non-zero.

Actually, nrt_sig runs on behalf of a virtual interrupt, which is a hard 
IRQ context from Linux's standpoint.

>
> Instead, I've found that in_irq() returns the value 0x10000, which
> (digging around in include/linux/hardirq.h) indicates that the hardirq
> count is 1.
>
> A partial Linux kernel stack backtrace, leading up to execution of the
> signal handler, is as follows:
>
>> [ 217.844177] [<bf031838>] (my_signalClient+0x24/0x48
>> [my_rtdm_driver]) from [<c00df42c>] (__ipipe_sync_stage+0x164/0x198)
>> [ 217.844207] [<c00df42c>] (__ipipe_sync_stage+0x164/0x198) from
>> [<c0058960>] (ipipe_trigger_irq+0x14/0x20)
>> [ 217.844238] [<c0058960>] (ipipe_trigger_irq+0x14/0x20) from
>> [<c011ca78>] (gatekeeper_thread+0x1ac/0x398)
>
> It seems that there are at least several possibilities:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniele Nicolodi | 2 Feb 2012 18:29

Xenomai 3 documentation

Hello,

I'm looking with curiosity to the development of Xenomai 3 skimming
through the GIT commits. I'm a physicist writing data acquisition code,
looking at how experienced programmers solve problems is very
instructional. However, I have observed that most of the code that has
been added do not have documentation in the form of comment blocks.

There is some other place where I can learn about Xenomai 3 ?

Thank you. Cheers,
--

-- 
Daniele
Permalink | Reply | 2 comments |
headers
Philippe Gerum | 2 Feb 2012 19:01
Favicon

Re: Xenomai 3 documentation

On 02/02/2012 06:29 PM, Daniele Nicolodi wrote:
> Hello,
>
> I'm looking with curiosity to the development of Xenomai 3 skimming
> through the GIT commits. I'm a physicist writing data acquisition code,
> looking at how experienced programmers solve problems is very
> instructional. However, I have observed that most of the code that has
> been added do not have documentation in the form of comment blocks.
>
> There is some other place where I can learn about Xenomai 3 ?

A general roadmap explaining high level issues:
http://www.xenomai.org/index.php/Xenomai:Roadmap#Toward_Xenomai_3

For the rest, the Cobalt kernel is fully documented in the sources, 
since it directly derives from v2.x's nucleus, check kernel/cobalt.

The really missing part is a documentation of the lib/copperplate API, 
providing the building blocks for the userland-based RTOS skins. That 
one is still wandering somewhere in my brain. But for sure, it will land 
in the sources at some point as well.

>
> Thank you. Cheers,

--

-- 
Philippe.
Permalink | Reply | 1 comment |
headers
Daniele Nicolodi | 2 Feb 2012 19:22

Re: Xenomai 3 documentation

On 02/02/12 19:01, Philippe Gerum wrote:
> On 02/02/2012 06:29 PM, Daniele Nicolodi wrote:
>> Hello,
>>
>> I'm looking with curiosity to the development of Xenomai 3 skimming
>> through the GIT commits. I'm a physicist writing data acquisition code,
>> looking at how experienced programmers solve problems is very
>> instructional. However, I have observed that most of the code that has
>> been added do not have documentation in the form of comment blocks.
>>
>> There is some other place where I can learn about Xenomai 3 ?
> 
> A general roadmap explaining high level issues:
> http://www.xenomai.org/index.php/Xenomai:Roadmap#Toward_Xenomai_3
> 
> For the rest, the Cobalt kernel is fully documented in the sources, 
> since it directly derives from v2.x's nucleus, check kernel/cobalt.
> 
> The really missing part is a documentation of the lib/copperplate API, 
> providing the building blocks for the userland-based RTOS skins. That 
> one is still wandering somewhere in my brain. But for sure, it will land 
> in the sources at some point as well.

Thank Philippe,

working mostly in user space, copperplate is the part I'm most
interested in. The code is self explanatory enough, but sometimes I fail
to see the big picture...

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Doyle | 3 Feb 2012 21:07
Picon

Get current wallclock time from RT task

What is the easiest way to determine the current wallclock time from
within an RT task?

I see that I can call rt_timer_inquire() and get back an RT_TIMER_INFO
structure containing an RTIME type field labeled "date" and a very
promising comment "Current wallclock time".

But how do I convert that to e.g. something I could pass to ctime() to
get something reasonably close to the current wallclock time?

--wpd
Permalink | Reply | 1 comment |
headers
Glen Wernersbach | 3 Feb 2012 21:19

Arm922T - Micrel KSZ8695P

Hi All,

Just wondering if anyone has ever successfully use RTAI on a Arm922T type chip?

Or have an idea on how hard to port.

Glen
--
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 – Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048
(513) 297-7550
----
"Support Dyslexia Research"
 
_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Permalink | Reply | 1 comment |
headers
Gilles Chanteperdrix | 3 Feb 2012 22:22
Favicon

Re: Get current wallclock time from RT task

On 02/03/2012 09:07 PM, Patrick Doyle wrote:
> What is the easiest way to determine the current wallclock time from
> within an RT task?
> 
> I see that I can call rt_timer_inquire() and get back an RT_TIMER_INFO
> structure containing an RTIME type field labeled "date" and a very
> promising comment "Current wallclock time".
> 
> But how do I convert that to e.g. something I could pass to ctime() to
> get something reasonably close to the current wallclock time?

You need to divide it by one billion. But for the result to be
reasonably accurate, you should either:
- compile xenomai as module
- or having synchronized xenomai clock with linux clock at some earlier
point in time by calling timer_settime(CLOCK_REALTIME) (from posix skin).

If your architecture supports it you may also use
clock_gettime(CLOCK_HOST_REALTIME) then you will get a result with very
good accuracy possibly without even a syscall.

--

-- 
                                                                Gilles.
Permalink | Reply | 0 comments |
headers
Gilles Chanteperdrix | 3 Feb 2012 22:39
Favicon

Re: Get current wallclock time from RT task

On 02/03/2012 10:33 PM, Patrick Doyle wrote:
> On Fri, Feb 3, 2012 at 4:22 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix <at> xenomai.org> wrote:
>> On 02/03/2012 09:07 PM, Patrick Doyle wrote:
>>> What is the easiest way to determine the current wallclock time from
>>> within an RT task?
>>>
>>> I see that I can call rt_timer_inquire() and get back an RT_TIMER_INFO
>>> structure containing an RTIME type field labeled "date" and a very
>>> promising comment "Current wallclock time".
>>>
>>> But how do I convert that to e.g. something I could pass to ctime() to
>>> get something reasonably close to the current wallclock time?
>>
>> You need to divide it by one billion. But for the result to be
>> reasonably accurate, you should either:
>> - compile xenomai as module
>> - or having synchronized xenomai clock with linux clock at some earlier
>> point in time by calling timer_settime(CLOCK_REALTIME) (from posix skin).
>>
>> If your architecture supports it you may also use
>> clock_gettime(CLOCK_HOST_REALTIME) then you will get a result with very
>> good accuracy possibly without even a syscall.
> 
> Hmmm...
> Is there any way to do this without using the posix skin?
> We are currently using the native skin quite happily, and I'm somewhat
> concerned that pulling in the posix skin (if it's even possible to mix
> and match skins) will lead to more problems than it will solve.

There is should be no problem mixing the skins.

> 
> How accurate is "unreasonably" accurate?  Accurate to within a second
> or so since we last booted should be plenty accurate for what I need
> this for.

The problem is that xenomai clock is synchronized with linux clock when
xenomai starts. When xenomai is build statically with the kernel, this
happens before linux clock is set with hwclock or ntp, so, xenomai clock
is completely off.

Anyway, you can create a binary using the posix skin which does just:

__real_clock_gettime(CLOCK_REALTIME, &ts);
clock_settime(CLOCK_REALTIME, &ts);

and launch it in an init script after Linux clock has been synchronized
with whatever clock you use.

> 
> --wpd
> 

--

-- 
                                                                Gilles.
Permalink | Reply | 0 comments |
headers
Gilles Chanteperdrix | 3 Feb 2012 22:43
Favicon

Re: Arm922T - Micrel KSZ8695P

On 02/03/2012 09:19 PM, Glen Wernersbach wrote:
> Hi All,
> 
> Just wondering if anyone has ever successfully use RTAI on a Arm922T type
> chip?
> 
> Or have an idea on how hard to port.

Well, the xenomai mailing list is not the best place to ask for an RTAI
port. However, we can answer the question for a xenomai port.

First, the arm core is irrelevant, what matters is what SOC exactly you
want to port to (that is because except starting with cortex a9, the arm
core does not contain a hardware timer, the timer is specific to the
SOC). Second, the port involved is more a port of adeos than a port of
xenomai, there is nothing SOC specific in xenomai. The adeos patch for
ARM already supports several SOC families, so we have some experience
doing this, it usually takes a few days to port adeos to a new ARM SOC.
If you are ready to do it yourself, we even propose an howto:

http://www.xenomai.org/index.php/I-pipe:ArmPorting

but it is starting to be seriously outdated, so, you probably have
better chances looking at how it is done for supported SOCs in an
existing patch. adeos patches for arm are available here:

http://download.gna.org/adeos/patches/v2.6/arm/
or here
http://download.gna.org/adeos/patches/v3.x/arm/

The list of SOCs currently supported:
http://www.xenomai.org/index.php/Embedded_Device_Support#ARM

--

-- 
                                                                Gilles.
Permalink | Reply | 0 comments |

Gmane