[Xenomai-help] Powerpc alignment exception

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

  

Re: [Xenomai-help] Powerpc alignment exception

[Philippe Gerum]

On 04/30/2012 07:55 PM, Makarand Pradhan wrote:
> 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?

This is not related to the Xenomai core, this is a pipeline issue. You 
can use whatever pipeline patch you need to.

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

NOSTACK means "no linux task stack", i.e. Xenomai kernel thread context, 
i.e. primary only, therefore non-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.
>

The kernel is able to do some dynamic fixup when an alignment fault 
occurs, by decoding the offending instruction manually, unless this 
could only be resolved as an access fault.

If the entry context is not a linux task, then we can only divert the 
code to the Xenomai fault handler, which will suspend the Xenomai kernel 
thread then tell us to return (first patch hunk). Otherwise we want to 
let the kernel attempt a fix up for "current". If that does not work, 
then we need Xenomai to handle the fault for switching the context to 
secondary mode in case we entered the alignment handler in primary mode 
(second patch hunk).

The bottom line is that we shall either do the fix up then return 
immediately with no mode change, or run the linux access fault handler 
in secondary mode.

> Rgds,
> Makarand.
>
>
>
>


-- 
Philippe.

Re: [Xenomai-help] Powerpc alignment exception

[Makarand Pradhan]

Thanks Philippe. That helps.

Rgds,
Makarand.

On 01/05/12 03:45 AM, Philippe Gerum wrote:
> On 04/30/2012 07:55 PM, Makarand Pradhan wrote:
>> 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?
> This is not related to the Xenomai core, this is a pipeline issue. You
> can use whatever pipeline patch you need to.
>
>> 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.
> NOSTACK means "no linux task stack", i.e. Xenomai kernel thread context,
> i.e. primary only, therefore non-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.
>>
> The kernel is able to do some dynamic fixup when an alignment fault
> occurs, by decoding the offending instruction manually, unless this
> could only be resolved as an access fault.
>
> If the entry context is not a linux task, then we can only divert the
> code to the Xenomai fault handler, which will suspend the Xenomai kernel
> thread then tell us to return (first patch hunk). Otherwise we want to
> let the kernel attempt a fix up for "current". If that does not work,
> then we need Xenomai to handle the fault for switching the context to
> secondary mode in case we entered the alignment handler in primary mode
> (second patch hunk).
>
> The bottom line is that we shall either do the fix up then return
> immediately with no mode change, or run the linux access fault handler
> in secondary mode.
>
>> 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.
_____________________________________________________________________