Wolfgang Denk | 1 Apr 01:12 2010
Picon
Picon

Re: cyclictest -tn where n!=1 causes segfault with Kilauea

Dear Robert,

In message <4BB3BCF9.9080809 <at> reliableembeddedsystems.com> you wrote:
> 
> ulimit -s
> 8192

And what happens when you start cyclictest after running
"ulimit -s unlimited" ?

Best regards,

Wolfgang Denk

--

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd <at> denx.de
All he had was nothing, but that was something, and now it  had  been
taken away.                             - Terry Pratchett, _Sourcery_
qiuhj | 1 Apr 05:13 2010

uITRON skin problem

Hi

I want to porting uitron based application to linux, and I decided to use xenomai uitron skin.

I patched the kernel, make the xenomai package and installed user space library and header file 

The application can be built , but something was wrong when I ran the program

The error message is “Xenomai uITRON skin init: shd_tsk() failed, status -33”

I found the error code “-33” mean parameter error ,but I can not understood, any help?

Any doc for uitron api ?

Thank you!

--
This message was sent on behalf of qiuhj <at> neusoft.com at openSubscriber.com
http://opensubscriber.com/message/xenomai-help <at> gna.org/11843555.html

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Robert Berger | 1 Apr 06:26 2010

Re: cyclictest -tn where n!=1 causes segfault with Kilauea

Hi Wolfgang,

Wolfgang Denk wrote:
> Dear Robert,
> 
> In message <4BB3BCF9.9080809 <at> reliableembeddedsystems.com> you wrote:
>> ulimit -s
>> 8192
> 
> And what happens when you start cyclictest after running
> "ulimit -s unlimited" ?

ulimit -s unlimited
-bash-3.2# ./cyclictest -t3
Segmentation fault

We are still dying somewhere here:

Program terminated with signal 11, Segmentation fault.
#0  0x0ff4e37c in xeno_fault_stack ()
   from /usr/local/xenomai-head/lib/libxenomai.so.0
(gdb)

Regards,

Robert
> 
> Best regards,
> 
> Wolfgang Denk
(Continue reading)

robert165 | 1 Apr 07:08 2010

Re: Seeking RT SPI driver for Atmel AT91 series CPU

 

 

在2010-03-31 23:31:47,"Sherk Chung" <sherk.chung <at> pivotalsys.com> 写道:

Hi Robert,

 

No, I was not able to find one available for the AT91, it seems not many people use SPI for that chip.   We are considering hiring a firm to build a driver for us.

 

-Sherk

OK. Thanks a lot.

Regards

Luo



_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Patrice Kadionik | 1 Apr 12:49 2010
Picon

Re: Problem to cross-compile Xenomai user-space support

Le 31/03/2010 12:55, Chtourou Sonda a écrit :

Hi Chtourou,

Hi Patrice,
OK. Please, verify first that you can boot µClinux without Xenomai on your board with the 2 extra hrtimer and hrclock peripherals.
There is no priority on IRQ with NIOS.
So, If I have understood, I could put:
IRO = 7 for hrtimer
IRQ = 8 for hrclock
IRQ = 1 for sys_clk_timer
with  this configuration µClinux without Xenomai with the 2 extra hrtimer and hrclock peripherals can boot  on the board .
But I'm wondering why with the first configuration (IRO = 1 for hrtimer,IRQ = 2 for hrclock and IRQ = 3 for sys_clk_timer), it didn't boot?
Huan Fang (https://mail.gna.org/public/xenomai-help/2010-04/msg00013.html) has detected the problem.
I have done some investigations.

For recall,
- From the HW point of view, when you build your SoPC system with SOPC Builder tool in Quartus II, you add different peripherals (Altera peripheral and your own peripherals). After that you lanch a generate command. At this, it creates a .ptf (and now a .sopc) file. This file is an ASCII file (in a synthax like XML), a declarative file that gives all informations for HDL synthesis. After that, you compile (a synthesis) your SoPC system that gives the .sof file for programming your Altera FPGA.
- From the SW point of view, when you do a "$ make vendor_hwselect SYSPTF=your_ptf_file.ptf", you generate (through Perl scripts) a nios2.h file under  .../uClinux-dist/linux-2.6.x/include/asm-nios2 directory that translates the .ptf file into .h file with #define declarations.

The sys_clk_timer must be the Linux timer even with the 2 Xenomai extra timers. sys_cllk_timer is renamed in the nios2.h as timer0:
/* Redefining sys_clk_timer -> timer0 */
#undef na_sys_clk_timer
#undef na_sys_clk_timer_irq

#define na_timer0                                  ((void *) 0xXXXXXXXX)
#define na_timer0_irq                                                  Y

The Perl script (altera_avalon_timer.pm) used by the "make vendor_hwselect" command parses the .ptf file and takes the first encountered timer as Linux timer! So, if it is not the sys_clk_timer (hrtimer or hrclock or your own timer...), it will be bad and you can't boot.

How can you have sys_clk_timer as the first timer in your .ptf file?
If you change the order in the graphical view under SOPC builder, it doesn't care.
The order of the peripherals in the generated .ptf file is their creation order.
So, you MUST first create in SOPC Builder sys_clk_timer and then the 2 other timers for Xenomai hrtimer and hrclock.
If you are note sure, delete all timers in the SoPC, save the SoPC and create finally in the right order the 3 timers.

If all is OK, you must have in the nios2.h something like:
/* Redefining sys_clk_timer -> timer0 */
#undef na_sys_clk_timer
#undef na_sys_clk_timer_irq

#define na_timer0                                  ((void *) 0xXXXXXXXX)
#define na_timer0_irq                                                  Y

Another verification is when you generate your SoPC system. The traces during SoPC generation with SOPC Builder gives the order in the .ptf file. For example, a good example:
# 2010.03.31 22:06:55 (*) Running Generator Program for ext_flash
# 2010.03.31 22:06:57 (*) Running Generator Program for ext_ram
# 2010.03.31 22:06:58 (*) Running Generator Program for onchip_ram_64_kbytes
# 2010.03.31 22:06:59 (*) Running Generator Program for sys_clk_timer
. . .
# 2010.03.31 22:07:05 (*) Running Generator Program for hrclock
. . .
# 2010.03.31 22:07:18 (*) Running Generator Program for uart_0
# 2010.03.31 22:07:21 (*) Running Generator Program for hrtimer
# 2010.03.31 22:07:22 (*) Running Generator Program for std_1s10_clock_0

So verify this point, it should be your problem.
Please verify that you have correctly enabled all the right options under SOPC builder for hrtimer and hrclock.
Because we have flexibility in HW configuration with SoPC, we must be more careful.
Configuration of hrtimer with the SoPC Builder:
• Timer: 32 bits.
• Timeout period: 1 µs.
• Preset : custom. Writable period, readable snapshot, Start/Stop control bits.

Configuration of hrclock with the SoPC Builder:
in the snapshot mode. Its configuration with the SoPC Builder tool is:
• 64-bit timer.
• Timeout period: 5 clocks. clock=20 ns (100 ns). The timer functionality is not used by Xenomai.
• Preset: custom. Writable period, readable snapshot, Start/Stop control bits.

Is it correct?
According to errno.h, code -19  is ENODEV, please verify your timer configuration and respect naming convention
Here, you speek about "sys_clock_timer"?
It is sys_clk_timer, sorry. I'll correct the typo error.

Patrice
Configuration of sys_clock_timer with the SoPC Builder:
• 32-bit timer.
• Timeout period: 10 ms.
• Preset: custom. Writable period, readable snapshot, Start/Stop control bits.

Regards,




-- Patrice Kadionik. F6KQH / F4CUQ ----------- +----------------------------------------------------------------------+ +"Tout doit etre aussi simple que possible, pas seulement plus simple" + +----------------------------------------------------------------------+ + Patrice Kadionik http://www.enseirb.fr/~kadionik + + IMS Laboratory http://www.ims-bordeaux.fr/ + + ENSEIRB http://www.enseirb.fr + + PO BOX 99 fax : +33 5.56.37.20.23 + + 33402 TALENCE Cedex voice : +33 5.56.84.23.47 + + FRANCE mailto:patrice.kadionik <at> ims-bordeaux.fr + +----------------------------------------------------------------------+
_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Philippe Gerum | 1 Apr 17:45 2010

Re: uITRON skin problem

On Wed, 2010-03-31 at 23:13 -0400, qiuhj <at> neusoft.com wrote:
> Hi
> 
> I want to porting uitron based application to linux, and I decided to use xenomai uitron skin.
> 
> I patched the kernel, make the xenomai package and installed user space library and header file 
> 
> The application can be built , but something was wrong when I ran the program
> 
> The error message is “Xenomai uITRON skin init: shd_tsk() failed, status -33”
> 

So you already know that an invalid parameter was sent to the routine,
right?

> I found the error code “-33” mean parameter error ,but I can not understood, any help?
> 

Any code from your end to help us understand what might fail on our end?

> Any doc for uitron api ?

uITRON is a public spec. If you meant "any doc for the Xenomai uITRON
skin implementation", then -ENOPARSE. "Documentation"? No idea what it
is, sorry.

PS: please refrain from posting to xenomai-core for such inquiries in
the hope of getting an answer faster, you won't get help this way, it
was in fact "that close" to be counter-productive. As stated here:
http://www.xenomai.org/index.php/Main_Page
xenomai-help is the perfect list for this question.

> 
> Thank you!
> 
>  
> 
> 
> --
> This message was sent on behalf of qiuhj <at> neusoft.com at openSubscriber.com
> http://opensubscriber.com/message/xenomai-help <at> gna.org/11843555.html
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help <at> gna.org
> https://mail.gna.org/listinfo/xenomai-help

--

-- 
Philippe.

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Gilles Chanteperdrix | 1 Apr 21:47 2010

Re: Analogy cmd_write example explanation

Philippe Gerum wrote:
> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote:
>> Philippe Gerum wrote:
>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote:
>>>> Hi,
>>>>
>>>> Philippe Gerum wrote:
>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Sorry for answering so late. I took a few days off far from any internet
>>>>>> connection.
>>>>>>
>>>>>> It seems you sent many mails related with Analogy. Many thanks for your
>>>>>> interest. I have not read all of them yet. However, I am beginning by
>>>>>> this one (which seems unanswered). The answer is quick and easy :)
>>>>>>
>>>>>> Daniele Nicolodi wrote:
>>>>>>> Hello. I'm looking into the analogy cmd_write example.
>>>>>>>
>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function
>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code
>>>>>>> shipped with xenomai 2.5.1).
>>>>>>>
>>>>>>> I do not understand why we have to set the primary mode at every
>>>>>>> iteration, when we set it before for the task (line 380).
>>>>>>>
>>>>>>> Is it because the dump_function() uses system calls that can make the
>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing?
>>>>>>>
>>>>>> You are right. The dumping routine triggers a switch to secondary mode.
>>>>>> That is why, the program switches back to primary mode after.
>>>>> This is wrong. The Xenomai core will switch your real-time thread to
>>>>> primary mode automatically when running a4l_insn* calls that end up
>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point
>>>>> for this one.
>>>>>
>>>> I don't understand. I thought that rt_dev_ioctl() triggered an
>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared
>>>> with the flags "__xn_exec_current | __xn_exec_adaptive".
>>>>
>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will
>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares
>>>> both RT and NRT fops entries), I thought there was no automatic
>>>> mode-switching.
>>> The point is that your ioctl_nrt handler should return -ENOSYS when it
>>> detects that the current request should be processed by the converse
>>> domain, to trigger the switch to primary mode. This is why the adaptive
>>> tag is provided in the first place.
>> The problem is that rtdm does not provide any function to know whether
>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us
>> whether the thread is RT or not. If it is NRT, we cannot distinguish a
>> Linux thread from a Xenomai one.
>>
>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we 
>> could force -ENOSYS if the calling thread was a Xenomai NRT thread:
>>
>>   diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c
>> index 8677c47..cc0cfe9 100644
>> --- a/ksrc/skins/rtdm/core.c
>> +++ b/ksrc/skins/rtdm/core.c
>>  <at>  <at>  -423,6 +423,9  <at>  <at>  do {									\
>>   									\
>>   	if (rtdm_in_rt_context())					\
>>   		ret = ops->operation##_rt(context, user_info, args);	\
>> +	else if (xnshadow_thread(user_info) != NULL &&			\
>> +		 ops->operation##_rt != (void *)rtdm_no_support)	\
>> +		ret = -ENOSYS;						\
>>   	else								\
>>   		ret = ops->operation##_nrt(context, user_info, args);	\
>>   									\
> 
> No, this would be a half-working kludge. But I think you have pinpointed
> a more general issue with RTDM: syscalls should be tagged as both
> adaptive and conforming, instead of bearing the __xn_exec_current bit.
> Actually, we do want the current domain to change when it is not the
> most appropriate, which __xn_exec_current prevents so far.
> 
> What we rather want is to have shadows migrating to primary mode when
> running rtdm_ioctl, since this is the preferred mode of operation for
> Xenomai threads, so that ioctl_rt is always invoked first when present,
> giving an opportunity to forward the request to secondary mode by
> returning -ENOSYS. Conforming calls always enforce the preferred runtime
> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks.
> That logic applies to all RTDM syscalls actually.
> 
> __xn_exec_current allows application code to infer that the RTDM driver
> might behave differently depending on the current runtime mode of the
> calling thread, which is very much error-prone, and likely not what was
> envisioned initially.

Argh.... The switchtest driver is relying on __xn_exec_current to have
context switches occur precisely in the mode we want. __xn_exec_adaptive
introduce more context switches around which we can not place separate
checks for fpu context, so, in short, breaks it badly. Fixing this
requires turning the switchtest driver into a skin with its own syscalls.

Note the sequence which occurs when a shadowed thread running in
secondary mode calls an ioctl for which only an nrt implementation occurs:
the thread is hardened to handle the ioctl
ioctl_rt is called which returns -ENOSYS
the thread is relaxed
ioctl_nrt is called

It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
syscall made by a thread with a shadow, and in fact seems to result in
as bad a result. Is it really what we want? The __xn_exec_current bit
resulted in a more lazy behaviour.

Also note that, at least when using the posix skin, almost all threads
have shadows, and only the priority makes the difference between a
really critical thread, and non critical threads with the null priority.
So, this will happen all the time.

--

-- 
					    Gilles.
Gilles Chanteperdrix | 1 Apr 22:11 2010

Re: cyclictest -tn where n!=1 causes segfault with Kilauea

Robert Berger wrote:
> ./cyclictest -t2
> Segmentation fault

This issue is fixed by commit 428aa42410efe575f7bb9729447e6dc49159ef5e
http://git.xenomai.org/?p=xenomai-2.5.git;a=commit;h=428aa42410efe575f7bb9729447e6dc49159ef5e

--

-- 
					    Gilles.
Jan Kiszka | 1 Apr 23:13 2010
Picon

Re: Analogy cmd_write example explanation

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote:
>>> Philippe Gerum wrote:
>>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote:
>>>>> Hi,
>>>>>
>>>>> Philippe Gerum wrote:
>>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Sorry for answering so late. I took a few days off far from any internet
>>>>>>> connection.
>>>>>>>
>>>>>>> It seems you sent many mails related with Analogy. Many thanks for your
>>>>>>> interest. I have not read all of them yet. However, I am beginning by
>>>>>>> this one (which seems unanswered). The answer is quick and easy :)
>>>>>>>
>>>>>>> Daniele Nicolodi wrote:
>>>>>>>> Hello. I'm looking into the analogy cmd_write example.
>>>>>>>>
>>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function
>>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code
>>>>>>>> shipped with xenomai 2.5.1).
>>>>>>>>
>>>>>>>> I do not understand why we have to set the primary mode at every
>>>>>>>> iteration, when we set it before for the task (line 380).
>>>>>>>>
>>>>>>>> Is it because the dump_function() uses system calls that can make the
>>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing?
>>>>>>>>
>>>>>>> You are right. The dumping routine triggers a switch to secondary mode.
>>>>>>> That is why, the program switches back to primary mode after.
>>>>>> This is wrong. The Xenomai core will switch your real-time thread to
>>>>>> primary mode automatically when running a4l_insn* calls that end up
>>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point
>>>>>> for this one.
>>>>>>
>>>>> I don't understand. I thought that rt_dev_ioctl() triggered an
>>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared
>>>>> with the flags "__xn_exec_current | __xn_exec_adaptive".
>>>>>
>>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will
>>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares
>>>>> both RT and NRT fops entries), I thought there was no automatic
>>>>> mode-switching.
>>>> The point is that your ioctl_nrt handler should return -ENOSYS when it
>>>> detects that the current request should be processed by the converse
>>>> domain, to trigger the switch to primary mode. This is why the adaptive
>>>> tag is provided in the first place.
>>> The problem is that rtdm does not provide any function to know whether
>>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us
>>> whether the thread is RT or not. If it is NRT, we cannot distinguish a
>>> Linux thread from a Xenomai one.
>>>
>>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we 
>>> could force -ENOSYS if the calling thread was a Xenomai NRT thread:
>>>
>>>   diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c
>>> index 8677c47..cc0cfe9 100644
>>> --- a/ksrc/skins/rtdm/core.c
>>> +++ b/ksrc/skins/rtdm/core.c
>>>  <at>  <at>  -423,6 +423,9  <at>  <at>  do {									\
>>>   									\
>>>   	if (rtdm_in_rt_context())					\
>>>   		ret = ops->operation##_rt(context, user_info, args);	\
>>> +	else if (xnshadow_thread(user_info) != NULL &&			\
>>> +		 ops->operation##_rt != (void *)rtdm_no_support)	\
>>> +		ret = -ENOSYS;						\
>>>   	else								\
>>>   		ret = ops->operation##_nrt(context, user_info, args);	\
>>>   									\
>> No, this would be a half-working kludge. But I think you have pinpointed
>> a more general issue with RTDM: syscalls should be tagged as both
>> adaptive and conforming, instead of bearing the __xn_exec_current bit.
>> Actually, we do want the current domain to change when it is not the
>> most appropriate, which __xn_exec_current prevents so far.
>>
>> What we rather want is to have shadows migrating to primary mode when
>> running rtdm_ioctl, since this is the preferred mode of operation for
>> Xenomai threads, so that ioctl_rt is always invoked first when present,
>> giving an opportunity to forward the request to secondary mode by
>> returning -ENOSYS. Conforming calls always enforce the preferred runtime
>> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks.
>> That logic applies to all RTDM syscalls actually.
>>
>> __xn_exec_current allows application code to infer that the RTDM driver
>> might behave differently depending on the current runtime mode of the
>> calling thread, which is very much error-prone, and likely not what was
>> envisioned initially.
> 
> Argh.... The switchtest driver is relying on __xn_exec_current to have
> context switches occur precisely in the mode we want. __xn_exec_adaptive
> introduce more context switches around which we can not place separate
> checks for fpu context, so, in short, breaks it badly. Fixing this
> requires turning the switchtest driver into a skin with its own syscalls.
> 
> Note the sequence which occurs when a shadowed thread running in
> secondary mode calls an ioctl for which only an nrt implementation occurs:
> the thread is hardened to handle the ioctl
> ioctl_rt is called which returns -ENOSYS
> the thread is relaxed
> ioctl_nrt is called
> 
> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
> syscall made by a thread with a shadow, and in fact seems to result in
> as bad a result. Is it really what we want? The __xn_exec_current bit
> resulted in a more lazy behaviour.
> 
> Also note that, at least when using the posix skin, almost all threads
> have shadows, and only the priority makes the difference between a
> really critical thread, and non critical threads with the null priority.
> So, this will happen all the time.

Right. Actually, we only need the conforming property for the (fairly
rare) case that a service is provided in both flavors. And if such a
service is hidden behind a single IOCTL command, it's even not possible
to detect this at RTDM level. We do need help from the driver or its
user space library, or we need to give them the tools to do the adaptive
switch themselves.

So three options:
 - Implement adaptive switching inside RTDM
    o For all major functions != ioctl, we need to check for a shadow
      thread and the availability of an RT handler => switch
    o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace
      to indicate the availability of an RT handler. This comes at the
      risk of colliding with existing drivers that do not use the
      standard IOCTL encoding scheme.
 - Push adaptive switching into the driver
    o That means providing the information if the caller could be
      switched to RT context.
 - Push adaptive switching into the helper library
    o That means exporting a service that performs a switch if the
      caller is switchable, but currently relaxed.

The second option is the least invasive one, I think. The first one is
most transparent, but also more fragile and complex than the rest. Three
is likely not Philippe's favorite as it would introduce yet another
explicit mode switching mechanism.

Opinions? Other ideas?

Jan

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Philippe Gerum | 1 Apr 23:22 2010

Re: Analogy cmd_write example explanation

On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> >> On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote:
> >>> Philippe Gerum wrote:
> >>>> On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Philippe Gerum wrote:
> >>>>>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Sorry for answering so late. I took a few days off far from any internet
> >>>>>>> connection.
> >>>>>>>
> >>>>>>> It seems you sent many mails related with Analogy. Many thanks for your
> >>>>>>> interest. I have not read all of them yet. However, I am beginning by
> >>>>>>> this one (which seems unanswered). The answer is quick and easy :)
> >>>>>>>
> >>>>>>> Daniele Nicolodi wrote:
> >>>>>>>> Hello. I'm looking into the analogy cmd_write example.
> >>>>>>>>
> >>>>>>>> I'm not sure I understand the reason for the rt_task_set_mode() function
> >>>>>>>> call into the data acquisition loop (lines 413 or 464 in the code
> >>>>>>>> shipped with xenomai 2.5.1).
> >>>>>>>>
> >>>>>>>> I do not understand why we have to set the primary mode at every
> >>>>>>>> iteration, when we set it before for the task (line 380).
> >>>>>>>>
> >>>>>>>> Is it because the dump_function() uses system calls that can make the
> >>>>>>>> task to switch to secondary mode, or there is a deeper reason I'm missing?
> >>>>>>>>
> >>>>>>> You are right. The dumping routine triggers a switch to secondary mode.
> >>>>>>> That is why, the program switches back to primary mode after.
> >>>>>> This is wrong. The Xenomai core will switch your real-time thread to
> >>>>>> primary mode automatically when running a4l_insn* calls that end up
> >>>>>> invoking rt_dev_ioctl(), since you did declare a real-time entry point
> >>>>>> for this one.
> >>>>>>
> >>>>> I don't understand. I thought that rt_dev_ioctl() triggered an
> >>>>> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared
> >>>>> with the flags "__xn_exec_current | __xn_exec_adaptive".
> >>>>>
> >>>>> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will
> >>>>> return -ENOSYS neither in RT nor in NRT mode (because analogy declares
> >>>>> both RT and NRT fops entries), I thought there was no automatic
> >>>>> mode-switching.
> >>>> The point is that your ioctl_nrt handler should return -ENOSYS when it
> >>>> detects that the current request should be processed by the converse
> >>>> domain, to trigger the switch to primary mode. This is why the adaptive
> >>>> tag is provided in the first place.
> >>> The problem is that rtdm does not provide any function to know whether
> >>> the thread is shadowed. We just have rtdm_in_rt_context() which tells us
> >>> whether the thread is RT or not. If it is NRT, we cannot distinguish a
> >>> Linux thread from a Xenomai one.
> >>>
> >>> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we 
> >>> could force -ENOSYS if the calling thread was a Xenomai NRT thread:
> >>>
> >>>   diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c
> >>> index 8677c47..cc0cfe9 100644
> >>> --- a/ksrc/skins/rtdm/core.c
> >>> +++ b/ksrc/skins/rtdm/core.c
> >>>  <at>  <at>  -423,6 +423,9  <at>  <at>  do {									\
> >>>   									\
> >>>   	if (rtdm_in_rt_context())					\
> >>>   		ret = ops->operation##_rt(context, user_info, args);	\
> >>> +	else if (xnshadow_thread(user_info) != NULL &&			\
> >>> +		 ops->operation##_rt != (void *)rtdm_no_support)	\
> >>> +		ret = -ENOSYS;						\
> >>>   	else								\
> >>>   		ret = ops->operation##_nrt(context, user_info, args);	\
> >>>   									\
> >> No, this would be a half-working kludge. But I think you have pinpointed
> >> a more general issue with RTDM: syscalls should be tagged as both
> >> adaptive and conforming, instead of bearing the __xn_exec_current bit.
> >> Actually, we do want the current domain to change when it is not the
> >> most appropriate, which __xn_exec_current prevents so far.
> >>
> >> What we rather want is to have shadows migrating to primary mode when
> >> running rtdm_ioctl, since this is the preferred mode of operation for
> >> Xenomai threads, so that ioctl_rt is always invoked first when present,
> >> giving an opportunity to forward the request to secondary mode by
> >> returning -ENOSYS. Conforming calls always enforce the preferred runtime
> >> mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks.
> >> That logic applies to all RTDM syscalls actually.
> >>
> >> __xn_exec_current allows application code to infer that the RTDM driver
> >> might behave differently depending on the current runtime mode of the
> >> calling thread, which is very much error-prone, and likely not what was
> >> envisioned initially.
> > 
> > Argh.... The switchtest driver is relying on __xn_exec_current to have
> > context switches occur precisely in the mode we want. __xn_exec_adaptive
> > introduce more context switches around which we can not place separate
> > checks for fpu context, so, in short, breaks it badly. Fixing this
> > requires turning the switchtest driver into a skin with its own syscalls.
> > 
> > Note the sequence which occurs when a shadowed thread running in
> > secondary mode calls an ioctl for which only an nrt implementation occurs:
> > the thread is hardened to handle the ioctl
> > ioctl_rt is called which returns -ENOSYS
> > the thread is relaxed
> > ioctl_nrt is called
> > 
> > It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
> > syscall made by a thread with a shadow, and in fact seems to result in
> > as bad a result. Is it really what we want? The __xn_exec_current bit
> > resulted in a more lazy behaviour.
> > 
> > Also note that, at least when using the posix skin, almost all threads
> > have shadows, and only the priority makes the difference between a
> > really critical thread, and non critical threads with the null priority.
> > So, this will happen all the time.
> 
> Right. Actually, we only need the conforming property for the (fairly
> rare) case that a service is provided in both flavors.

Wrong. You want conforming because real-time is the preferred mode of
operations for real-time threads.

>  And if such a
> service is hidden behind a single IOCTL command, it's even not possible
> to detect this at RTDM level. We do need help from the driver or its
> user space library, or we need to give them the tools to do the adaptive
> switch themselves.
> 
> So three options:
>  - Implement adaptive switching inside RTDM
>     o For all major functions != ioctl, we need to check for a shadow
>       thread and the availability of an RT handler => switch
>     o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace
>       to indicate the availability of an RT handler. This comes at the
>       risk of colliding with existing drivers that do not use the
>       standard IOCTL encoding scheme.
>  - Push adaptive switching into the driver
>     o That means providing the information if the caller could be
>       switched to RT context.
>  - Push adaptive switching into the helper library
>     o That means exporting a service that performs a switch if the
>       caller is switchable, but currently relaxed.
> 
> The second option is the least invasive one, I think. The first one is
> most transparent, but also more fragile and complex than the rest. Three
> is likely not Philippe's favorite as it would introduce yet another
> explicit mode switching mechanism.
> 
> Opinions? Other ideas?
> 
> Jan
> 

--

-- 
Philippe.

Gmane