Re: [Xenomai-help] Xenomai 2.6.0 - kernel seg faults on AT91

[at91_enthus <nwromania@domain.hid>]

On 11/06/2011 02:27 PM, Gilles Chanteperdrix wrote:
> On 11/06/2011 09:23 PM, at91_enthus wrote:
>> On 11/06/2011 02:02 PM, Gilles Chanteperdrix wrote:
>>> On 11/06/2011 08:54 PM, at91_enthus wrote:
>>>> On 11/06/2011 01:03 PM, Gilles Chanteperdrix wrote:
>>>>> On 11/06/2011 08:00 PM, at91_enthus wrote:
>>>>>> On 11/06/2011 12:32 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 11/06/2011 07:25 PM, at91_enthus wrote:
>>>>>>>> On 11/06/2011 12:10 PM, at91_enthus wrote:
>>>>>>>>> On 11/06/2011 12:01 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 11/06/2011 06:56 PM, at91_enthus wrote:
>>>>>>>>>>> Hi.
>>>>>>>>>>>
>>>>>>>>>>> I gave Xenomai 2.6.0 a try and installed a newly patched kernel on my
>>>>>>>>>>> AT91SAM9G20 board.
>>>>>>>>>>>
>>>>>>>>>>> Here is my setup:
>>>>>>>>>>>
>>>>>>>>>>> proc:   AT91SAM9G20
>>>>>>>>>>> kernel: 2.6.35.9
>>>>>>>>>>> OS: embedded Debian Squeeze
>>>>>>>>>>>
>>>>>>>>>>> The board boots fine up to stage 2 (user terminal). Sometimes, I am able
>>>>>>>>>>> to get a login terminal, despite seg fault messages.
>>>>>>>>>>>
>>>>>>>>>>> A similar behavior occurs in a Xenomai capable 2.6.37 kernel, only
>>>>>>>>>>> without the fault messages. In this case the board simply freezes.
>>>>>>>>>>>
>>>>>>>>>>> I included the files (.config and fault messages) in the attachments.
>>>>>>>>>>>
>>>>>>>>>> You enabled CONFIG_FCSE_GUARANTEED, I do not think Debian squeeze can
>>>>>>>>>> boot with that, you need a real embedded filesystem, or use
>>>>>>>>>> CONFIG_FCSE_BEST_EFFORT.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Since I've started looking in to Xenomai, I have been using FCSE
>>>>>>>>> "guaranteed" and "best efort"  along with both Debian Squeeze and Lenny
>>>>>>>>> (Xenomai 2.5 series) without any issues.
>>>>>>>>>
>>>>>>>>> I'll change the FCSE setting to see if I get a different behavior.
>>>>>>>>>
>>>>>>>>> Regards.
>>>>>>>> I put the results for CONFIG_FCSE_BEST_EFFORT in the attachment.
>>>>>>> Unusable. To make it usable, the following options are lacking:
>>>>>>> CONFIG_FCSE_MESSAGES
>>>>>>> CONFIG_FRAME_POINTER
>>>>>> I couldn't find this option.
>>>>> You need to disable STACK_UNWIND. Without it, some stack traces are
>>>>> unreadable such as the one you keep sending.
>>>>>
>>>> rc.local looked suspicious in the debug messages.
>>>>
>>>> To be more exact, it contained the following lines:
>>>>
>>>> #! /bin/sh
>>>> chmod 777 /proc/xenomai/latency
>>>> echo "1000" > /proc/xenomai/latency
>>>> exit 0
>>>>
>>>> The setting came from the previous installation, because I kept getting
>>>> negative values for latencies.
>>> Note that you can hardwire a value for the latency in the kernel
>>> configuration.
>>>
>>>> Anyway, I removed the offending lines and my system boots correctly. If
>>>> I enter the lines by hand, I get no segfaults. However, if I try to
>>>> execute /etc/rc.local (with the two lines uncommented) by hand, the
>>>> kernel seg faults and the system freezes.
>>>>
>>>>  Odd.
>>> Yes, really odd. I am unable to reproduce this issue.
>>>
>>> What was the last version known to be working?
>>>
>> I think I found the main culprit, although I can't figure out the mechanism.
>>
>> In an earlier post, I stated that the contents in rc.local crashed the
>> system and if I entered the lines manually nothing happened.
>>
>> BASH is used at console level, sh in rc.local.
>>
>> If I set "sh" in the console and execute the two lines manually, the
>> system locks. Therefore, for some strange reason, sh is detrimental to
>> xenomai.
>>
>> The question is why this happens in 2.6 and not 2.5.*.
> The bug you have is a fault during a copy_from_user made by xenomai when
> writing to /proc/xenomai/latency, it probably has nothing to do with sh.
> I am simply trying to understand how this could happen, as on my AT91
> board there is no such behaviour (as should be).
>
>>  
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
>
Just switched "sh" to "bash" in rc.local.
It simply works. I booted the board 3 times with no issues.