[Xenomai-help] Powerpc alignment exception

[Makarand Pradhan]

Hi,

There has been a thread on this topic in the past:

https://mail.gna.org/public/xenomai-help/2009-08/msg00023.html

A quick background: We get the alignment exception, as we pass 
-fpack-struct option to gcc and some data in structures is misaligned.


I have been testing the patch on Linux 3.0.0, Xenomai 2.6 and it seems 
to work well. Do you think, it requires any additional changes to be 
used with Xenomai 2.6?


Also, I am trying to understand how it works and have a question. Am 
summarizing my understanding below. Would appreciate your comments:


alignment_exception:

+ if (test_bit(IPIPE_NOSTACK_FLAG, &ipipe_this_cpudom_var(status)) &&
+ ipipe_trap_notify(IPIPE_TRAP_ALIGNMENT, regs))
  return;

I believe, the IPIPE_NOSTACK_FLAG is set when we are running in Linux. 
So we should invoke ipipe_trap_notify only while we are running in 
linux.  While running in the primary domain, we would go ahead and fix 
the alignment.



+ if (!ipipe_root_domain_p &&
+ ipipe_trap_notify(IPIPE_TRAP_ALIGNMENT, regs))
+ return;
+
I am not able to figure this part properly. If we are not in the root 
domain we invoke ipipe_trap_notify. (I believe root domain = Linux). So 
if we are in the primary, we would invoke ipipe_trap_notify. 
ipipe_trap_notify in turn would invoke the event handler 
(xnpod_trap_fault). This would send us to the secondary domain. All the 
same, we stay int he primary as per my tests. So, I am making a mistake 
somewhere. Would appreciate your opinion.


Rgds,
Makarand.




--
___
NOTICE OF CONFIDENTIALITY:
This e-mail and any attachments may contain confidential and privileged 
information.  If you are
not the intended recipient, please notify the sender immediately by return 
e-mail and delete this
e-mail and any copies.  Any dissemination or use of this information by a 
person other than the
intended recipient is unauthorized and may be illegal.
_

 



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

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Gilles Chanteperdrix]

On 04/25/2012 12:28 PM, Frederik Bayart wrote:
> Hallo,
> 
> We are switching from linux 2.6.30.8 with xenomai 2.4.10  to linux 2.6.38.8
> with xenomai 2.6.0 (stable release) on debian lenny.

If you are concerned with security (which seems to be the case since you
want to avoid running real-time programs as root):
- you should note that debian lenny is no longer maintained for security
update (since february actually), so, an upgrade to squeeze is
recommended. Chances are that it is possible to become root when running
as an ordinary user on a lenny system without too much trouble.
- it is entirely possible that it is possible to become root abusing
xenomai interfaces, xenomai interfaces are not implemented with security
in mind.

> 
> In our daemon (with real pid root), we are setting effective pid and gid to
> 1000 and are calling popen to execute a shell command.
> The popen succeeds, but when I try to read the output with fgets, I get the
> error :
> 
> Xenomai: binding failed: Operation not permitted.
> 
> I verified that the effective user for both commands is the same.
> 
> This was working on xenomai 2.4.10
> I added the user with pid 1000 already to the xenomai group but this
> doesn't work.

That is not enough, you should also do what is said here:
http://www.xenomai.org/index.php/Non-root_RT

-- 
Gilles.

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

Re: [Xenomai-help] Interrupt latency greater than 250ms

[Philippe Gerum]

On 04/12/2012 05:57 PM, Philippe Gerum wrote:
> On 04/12/2012 05:45 PM, Michael Pustylnik wrote:
>> The code masking the interrupt in IPIC (call for
>> ipipe_pre_cascade_noeoi()) initially showed up in the patch you
>> recommended (see your email attached).
>>
>> Later on it was integrated in Xenomai commit
>> "9a5e42df8bccc59620c08caeb4b9fe92dbf94a1b".
>>
>> As shown in the trail below, it keeps interrupts all the time until the
>> scheduler returns, thus breaking real-time responsiveness.
>>
>> A solution to this is probably to remove calling
>> ipipe_pre_cascade_noeoi() and let the cascading handler mask the
>> interrupt. Am I missing something? Do you think it is safe to use this
>> solution?
> 
> No, as interrupts could be re-enabled before invoking the handler, you 
> would get an IRQ storm.
> 
> The solution is to rework the cascaded IRQ handling in the generic 
> pipeline core, so that all decoded IRQs are acked/masked, then the 
> multiplex IRQ unmasked, then all the decoded IRQ handlers fired when 
> syncing the relevant pipeline stage.
> 
> A fix for this will follow when enough testing will have been done on 
> arm and ppc, to check whether that logic does not raise other issue.
> 

This is the patch series fixing the issue in the newest pipeline "core"
implementation, currently for kernel 3.2. Something along these lines would 
work for
earlier kernels as well.

http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=0a9a7b4e4ce9f4196a574471ad58f4389820c438
http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=f2ca3c2baf58bf43f4c00fb05b91b16da9fd77f2
http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=a4b909ccf80c5afa132aa7a9ccf0022cb8a6e6f2
http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=b47bc773ff07ce886aaf490921ac59e98ed9575a

>>
>> Michael Pustylnik, P.Eng.
>> Senior Software Engineer
>> *RuggedCom Inc.*
>> www.ruggedcom.com 
>> 300 Applewood Crescent
>> Concord, Ontario, L4K 5C7
>> Tel: (905)482-4523
>> Fax: (905)856-1995
>>
>> 
>>
>> *From:*xenomai-help-boun...@gna.org
>> [mailto:xenomai-help-boun...@gna.org] *On Behalf Of *Makarand Pradhan
>> *Sent:* Wednesday, April 04, 2012 12:59 PM
>> *To:* Philippe Gerum
>> *Cc:* xenomai-help@gna.org
>> *Subject:* Re: [Xenomai-help] Interrupt latency greater than 250ms.
>> Question.
>>
>> Hi Philippe,
>>
>> We have found that the problem is that the interrupt is unexpectedly
>> held masked at the IPIC level for a long time. Please find the trace 
>> below:
>>
>> 2552 :| + func -54413 0.590 qe_ic_cascade_low_ipic+0x8
>> (__ipipe_ack_irq+0x2c)
>> 2553 :| + func -54412 0.696 qe_ic_get_low_irq+0x8
>> (qe_ic_cascade_low_ipic+0x30)
>> 2554 :| + func -54411 0.666 irq_linear_revmap+0x8 
>> (qe_ic_get_low_irq+0x5c)
>>
>> *MASK in IPIC (SIMSR_H register bit 1)*
>> 2555 :| + func -54411 0.606 ipic_mask_irq+0x8 
>> (qe_ic_cascade_low_ipic+0x48)
>> 2556 :| + func -54410 0.590 irqd_to_hwirq+0x8 (ipic_mask_irq+0x30)
>> 2557 :| + func -54410 0.909 __ipipe_spin_lock_irqsave+0x8
>> (ipic_mask_irq+0x40)
>> 2558 :| # func -54409 0.727 __ipipe_spin_unlock_irqrestore+0x8
>> (ipic_mask_irq+0xa8 )
>> 2559 :| + func -54408 0.560 __ipipe_qe_ic_cascade_irq+0x8
>> (qe_ic_cascade_low_ipic+ 0x5c)
>> 2560 :| + begin 0x002b -54407 0.530 __ipipe_qe_ic_cascade_irq+0x2c
>> (qe_ic_cascade_low_ipic +0x5c)
>> 2561 :| + func -54407 0.651 __ipipe_handle_irq+0x8
>> (__ipipe_qe_ic_cascade_irq+0x38 )
>> 2562 :| + func -54406 0.939 __ipipe_ack_level_irq+0x8
>> (__ipipe_handle_irq+0xbc)
>>
>> *MASK in QUICC (CIMR register bit 11)*
>> 2563 :| + func -54405 0.787 qe_ic_mask_irq+0x8 
>> (__ipipe_ack_level_irq+0x40)
>>
>> *XENOMAI SCHEDULER IS INVOKED*
>> 2576 :| # func -54393 0.590 __xnpod_schedule+0x8 
>> (xnintr_irq_handler+0x1f8)
>> *
>> UNMASK in QUICC (done by our user space handler)*
>> 2595 : + func -54377 0.621 __rt_intr_enable+0x8 [xeno_native]
>> (hisyscall_event+0x 1e4)
>>
>> *UNMASK in IPIC (after 50ms, i.e. only after the scheduler returns):*
>> 31637 :| #end 0x002b -518+ 2.272 __ipipe_qe_ic_cascade_irq+0x40
>> (qe_ic_cascade_low_ipic+ 0x5c)
>> 31638 :| #func -516+ 1.090 ipic_unmask_irq+0x8 
>> (qe_ic_cascade_low_ipic+0x70)
>>
>> As you can see from the trace above, the interrupt is held masked at the
>> IPIC level all the time until the Xenomai scheduler returns and is only
>> unmasked after that.
>>
>> Is it really the way it should be? Shouldn’t the interrupt be unmasked
>> at the IPIC level right after masking it at the QUICC engine level?
>>
>> Rgds,
>> Mak.
>>
>>
>>
>> On 28/03/12 02:23 PM, Makarand Pradhan wrote:
>>
>> Hi Philippe,
>>
>>
>>
>> On 28/03/12 12:17 PM, Philippe Gerum wrote:
>>
>>> The log says your code wants to control when the IRQ is enabled again,
>>> by calling rt_intr_enable() from userland. I guess you are setting
>>> I_NOAUTOENA too. Correct?
>>
>>
>> That is correct. I_NOAUTOENA is used in rt_intr_create. Otherwise the
>>
>> level trigerred interrupt will not allow the use

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Gilles Chanteperdrix]

On 04/25/2012 04:00 PM, Frederik Bayart wrote:
> Migration to squeeze is the next step planned.
> In attachment a small test program to reproduce the problem and a makefile.
> The program is running as root but we want e.g. the command executed
> by the popen command running as user 'triphase'
> 
> if you run the program and press CTRL-C, you get Xenomai: binding
> failed on 2.6.0 and output (of part of the output) from 'ls' on
> 2.4.10.

I am afraid you will have to add the triphase user to the xenomai group
and pass the xeno_nucleus.xenomai_gid option to the kernel. Or else
rewrite the vfork + exec yourself dropping root privileges after the fork.

The reason is that the native api assumes that if you fork in a xenomai
program, chances are you will want to use the native api in the child
program.
-- 
Gilles.

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