On 01/14/2013 09:52 PM, John Morris wrote:
> On 01/14/2013 07:36 AM, Jan Kiszka wrote:
>> On 2013-01-14 13:00, Jan Kiszka wrote:
>>> On 2013-01-14 12:57, Gilles Chanteperdrix wrote:
>>>> On 01/14/2013 05:47 AM, John Morris wrote:
>>>>
>>>>> On 01/13/2013 01:41 PM, Gilles Chanteperdrix wrote:
>>>>>> On 01/13/2013 08:14 PM, John Morris wrote:
>>>>>>
>>>>>>> Hi Gilles and Jan,
>>>>>>>
>>>>>>> Note change of thread subject. I'm starting to get confused.
>>>>>>>
>>>>>>> On 01/13/2013 06:16 AM, Gilles Chanteperdrix wrote:
>>>>>>>> On 01/13/2013 05:36 AM, John Morris wrote:
>>>>>>>>
>>>>>>>>> On 01/12/2013 11:31 AM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 01/12/2013 06:26 PM, John Morris wrote:
>>>>>>>>>>> 1) Most worrisome is "kernel BUG at mm/mmap.c:2313! invalid
>>>>>>>>>>> opcode:
>>>>>>>>>>> 0000 [#2] SMP". Is this related to HEAPSZ or STACKPOOLSZ? My mind
>>>>>>>>>>> is
>>>>>>>>>>> getting foggy about all the things I've seen, but it seems like it
>>>>>>>>>>> was
>>>>>>>>>>> happening earlier in the tests until these config values were
>>>>>>>>>>> quadrupled.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Could you check whether you can reproduce this issue with the I-pipe
>>>>>>>>>> patch for 3.5.7 ? The next xenomai release will be based on this
>>>>>>>>>> version
>>>>>>>>>> on x86 anyway. Branch for-core-3.5.7 in ipipe-gch.git
>>>>>>>>>
>>>>>>>>> Different problem; Xenomai wouldn't start:
>>>>>>>>>
>>>>>>>>> I-pipe: could not find timer for cpu #0
>>>>>>>>>
>>>>>>>>> dmesg:
>>>>>>>>> http://www.zultron.com/static/2013/01/xenomai/3.5.7-test/foo-dmesg-3.5.7.log
>>>>>>>>>
>>>>>>>>> .config:
>>>>>>>>> www.zultron.com/static/2013/01/xenomai/3.5.7-test/foo-kernel-3.5.7.config
>>>>>>>>>
>>>>>>>>> FYI, I found this same problem on two of my systems while testing your
>>>>>>>>> Debian packages. Both AMD Athlon II 64-bit (one single, one dual
>>>>>>>>> core).
>>>>>>>>> They're about the same generation of motherboards, AM2 or AM2+
>>>>>>>>> socket.
>>>>>>>>> One is AMD 770 chipset, the other NVidia GeForce 6100 / nForce 430.
>>>>>>>>>
>>>>>>>>> Hardware looks similar to Mariusz's in this post, where he had the
>>>>>>>>> same
>>>>>>>>> problem:
>>>>>>>>>
>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2012-December/027121.html
>>>>>>>>>
>>>>>>>>> He's also running AMD 64-bit on a Gigabyte motherboard, but the next
>>>>>>>>> generation AM3 socket, Phenom CPU, AMD 890 chipset. I don't have a
>>>>>>>>> C1E
>>>>>>>>> BIOS option on these boards to enable/disable. These same
>>>>>>>>> motherboards
>>>>>>>>> don't suffer this problem with mainline Xenomai on 3.5.3.
>>>>>>>>
>>>>>>>>
>>>>>>>> If you had the same problem as Marius, you would have seen it with
>>>>>>>> 3.5.3, and you would get the message in the dmesg about C1E, so, it is
>>>>>>>> probably something else.
>>>>>>>
>>>>>>> Yes, I'm definitely getting confused. I did see the same problem with
>>>>>>> C1E, but only while running your 3.5.7 .debs, and not in the 3.5.7 el6
>>>>>>> packages that are the main subject of this sub-thread:
>>>>>>>
>>>>>>> http://www.zultron.com/static/2013/01/xenomai/3.5.7-deb-gilles/dmesg-3.5.7-deb-gilles.log
>>>>>>
>>>>>>
>>>>>> Ah, that is because I rebased the I-pipe tree in between, and at some
>>>>>> point the code printing the message was wrong (ATOMIC_INIT(0) instead of
>>>>>> ATOMIC_INIT(-1)). That is my fault then, sorry.
>>>>>>
>>>>>>>
>>>>>>>> Could you run
>>>>>>>>
>>>>>>>> cat /proc/timer_list
>>>>>>>
>>>>>>> Back to el6 again, 3.5.7 i-pipe:
>>>>>>>
>>>>>>> http://www.zultron.com/static/2013/01/xenomai/3.5.7-test/foo-cat-proc-timer_list-3.5.7-test.log
>>>>>>
>>>>>>
>>>>>> The LAPIC is definitely up and running (mode: 3). So, it probably means
>>>>>> that the erratum detection is not sufficient to decide not to use a
>>>>>> LAPIC. Checking your logs, we see:
>>>>>>
>>>>>> using AMD E400 aware idle routine
>>>>>>
>>>>>> which means the LAPIC could potentially be unusable, but the idle
>>>>>> routine also checks for a bit in a K8 specific MSR and prints the
>>>>>> message:
>>>>>>
>>>>>> System has AMD C1E enabled
>>>>>>
>>>>>> If this bit is set, and in your case the message is not printed so the
>>>>>> bit is not set. So, the LAPIC is usable, but due to the changes I made
>>>>>> to try and print a message in Marius case, I broke the detection in your
>>>>>> case.
>>>>>>
>>>>>> I have just pushed a rework for this commit in the for-core-3.5.7 branch
>>>>>> in ipipe-gch git.
>>>>>
>>>>> And it worked, no more C1E error! Thanks!
>>>>>
>>>>> It looks like the AMD-64 AM2/AM2+ socket CPUs were the last generation
>>>>> without C1E, and the AM3 socket CPUs were the first gen with.
>>>>>
>>>>> Back to the original problem, the posix/mprotect problem is confirmed to
>>>>> be in this branch:
>>>>>
>>>>> ++ /usr/lib64/xenomai/regression/posix/mprotect
>>>>> memory read
>>>>> FAILURE: sigdebug_handler triggered, reason 2
>>>>> memory write after exec enable
>>>>
>>>>
>>>> I will try to compile a kernel with the same configuration as you to see
>>>> if I can reproduce the issue.
>>>
>>> Unless you want to double-check: build is already running here. This
>>> feature is critical for us, but I have no clue ATM why it could fail
>>> over the latest patch queue.
>>
>> OK, would probably be good to double-check as I'm unable to reproduce
>> the issue over my queue with John's .config.
>>
>> The reason code is suspicious BTW: syscall. Would be good if someone who
>> can reproduce attaches gdb and provides a backtrace from the signal to
>> the call that triggered it. Could something have went wrong while
>> building the test case, that not all required functions are wrapped such
>> as printf?
>
> Hi Jan,
>
> Is this what you need?
>
> http://www.zultron.com/static/2013/01/xenomai/3.5.7-test/foo-gdb-posix-mprotect-3.5.7-test.log
So, you are compiling with _FORTIFY_SOURCE, that is the difference with
how we are compiling. Is it easy for you to set _FORTIFY_SOURCE to 0?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
