[Xenomai] Question regarding rt_sem_p

[Xenomai] Question regarding rt_sem_p

[PRADHAN, MAKARAND (RC-CA)]

Hi All,

I am facing a unique problem related to Semaphores and would appreciate any suggestions that you may have.

My system:
CPU: DRA7xx (Arch: arm. Texas Inst, OMAP based SOC with Dual Core A-15s)
Linux: 3.12-1

rt_sem_p is returning ENOSYS after some time only while running under GDB. When I run without GDB everything seems to work. The timeout used is TM_INFINITE. I've tried to dig into the Xenomai user space and the kernel code to see where ENOSYS may be returned by rt_sem_p. All the same, I have not been successful in identifying the root cause.

Any opinions/views?

Thanks and Rgds,
Makarand.

This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation

Re: [Xenomai] Question regarding rt_sem_p

[Gilles Chanteperdrix]

On 08/05/2014 10:33 PM, PRADHAN, MAKARAND (RC-CA) wrote:
> Hi All,
> 
> I am facing a unique problem related to Semaphores and would appreciate any suggestions that you may have.
> 
> My system:
> CPU: DRA7xx (Arch: arm. Texas Inst, OMAP based SOC with Dual Core A-15s)
> Linux: 3.12-1

Do you have the same problem with the for-ipipe-3.14.0 branch from
ipipe-gch git, running with xenomai 2.6 git head?

-- 
                                                                Gilles.

Re: [Xenomai] Question regarding rt_sem_p

[PRADHAN, MAKARAND (RC-CA)]

Hi,

[Gilles] Do you have the same problem with the for-ipipe-3.14.0 branch from
ipipe-gch git, running with xenomai 2.6 git head?

Unfortunately I cannot upgrade the ipipe patch in the near foreseeable future. Our system has to continue running on Linux 3.12 and xenomai 2.6.3 and the ipipe patch which I believe is ipipe-core-3.8.13-arm-3.patch.

Another issue noted is with rt_task_sleep. It is also returning -38. A simple test program to reproduce the problem is given at the end of the email along with a log of my session.
Tracing the kernel shows that the system call (__rt_task_sleep) is returning -4(EINTR. XNBREAK) immediately without suspending. All the same, the user space mysteriously sees a return code of -38.
The problem goes away once all the tasks have spawned and are running. This tends to indicate that it's some race condition.
I've tried powerpc and the powerpc seems to run without any issues for the same configuration.

Outside gdb this test program runs ok. All the same, we have noticed the -38 return code in other applications running xenomai even without gdb. I have not been able to write a test code that reproduces the issue without gdb.

Any pointers is resolving the issue would be highly appreciated.

Rgds,
Makarand.

My system:
CPU: DRA7xx (Arch: arm. Texas Inst, OMAP based SOC with Dual Core A-15s)
Linux: 3.12-1
Xenomai 2.6.3

Steps to reproduce the problem:
g++ sem1.c -I/usr/include/xenomai/ -lnative -lxenomai -g
root@ruggedcom:~# gdb a.out
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/a.out...done.
(gdb) run 3
Starting program: /root/a.out 3
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb6d73460 (LWP 27232)]
sem1 create. rc: 0
Spawning tasks
Spawning: task 0. Name: TASK_0
[New Thread 0xb6d6b460 (LWP 27233)]
[New Thread 0xb6d63460 (LWP 27234)]
[New Thread 0xb6d5b460 (LWP 27235)]
Spawning: task 1. Name: TASK_1
Task0: sleeping: 2000000000
task 0: rt_task_sleep: rc: -38
Task0: sleeping: 2000000000
Spawning: task 2. Name: TASK_2
Task1: sleeping: 2000000000
task 1: rt_task_sleep: rc: -38
Task1: sleeping: 2000000000
task 0: rt_task_sleep: rc: -38
Task0: sleeping: 2000000000
Task2: sleeping: 2000000000
Task1: sleeping: 2000000000
Task0: sleeping: 2000000000
Task2: sleeping: 2000000000
Task1: sleeping: 2000000000
Task0: sleeping: 2000000000
Task2: sleeping: 2000000000
^C
Program received signal SIGINT, Interrupt.
0xb6fd16bc in rt_task_sleep (delay=100000000000) at task.c:321
321             err = XENOMAI_SKINCALL1(__native_muxid, __native_task_sleep, &delay);
(gdb) quit
A debugging session is active.

        Inferior 1 [process 27229] will be killed.

Quit anyway? (y or n) y
root@ruggedcom:~#

kern.log for an instrumented xeno_native.ko:
Sep 12 20:49:58 ruggedcom kernel: [92692.073071] __rt_task_sleep: delay from US: 2000000000
Sep 12 20:49:58 ruggedcom kernel: [92692.073082] rt_task_sleep: Thread: TASK_0: starting: Delay: 2000000000
Sep 12 20:49:58 ruggedcom kernel: [92692.073211] rt_task_sleep: Thread: TASK_0: test info: 4. Returning: -4
Sep 12 20:49:58 ruggedcom kernel: [92692.073218] __rt_task_sleep: returning: rc: -4
Sep 12 20:49:58 ruggedcom kernel: [92692.075162] __rt_task_sleep: delay from US: 2000000000
Sep 12 20:49:58 ruggedcom kernel: [92692.075171] rt_task_sleep: Thread: TASK_0: starting: Delay: 2000000000
Sep 12 20:49:58 ruggedcom kernel: [92692.075749] __rt_task_sleep: delay from US: 2000000000
Sep 12 20:49:58 ruggedcom kernel: [92692.075757] rt_task_sleep: Thread: TASK_1: starting: Delay: 2000000000
Sep 12 20:49:58 ruggedcom kernel: [92692.075886] rt_task_sleep: Thread: TASK_1: test info: 4. Returning: -4
Sep 12 20:49:58 ruggedcom kernel: [92692.075892] __rt_task_sleep: returning: rc: -4
Sep 12 20:49:58 ruggedcom kernel: [92692.075932] rt_task_sleep: Thread: TASK_0: test info: 4. Returning: -4
Sep 12 20:49:58 ruggedcom kernel: [92692.075938] __rt_task_sleep: returning: rc: -4
Sep 12 20:49:59 ruggedcom kernel: [92692.077787] __rt_task_sleep: delay from US: 2000000000
Sep 12 20:49:59 ruggedcom kernel: [92692.077795] rt_task_sleep: Thread: TASK_1: starting: Delay: 2000000000
Sep 12 20:49:59 ruggedcom kernel: [92692.077842] __rt_task_sleep: delay from US: 2000000000
Sep 12 20:49:59 ruggedcom kernel: [92692.077849] rt_task_sleep: Thread: TASK_0: starting: Delay: 2000000000
Sep 12 20:49:59 ruggedcom kernel: [92692.077960] __rt_task_sleep: delay from US: 100000000000
Sep 12 20:49:59 ruggedcom kernel: [92692.077967] rt_task_sleep: Thread: Task 0: starting: Delay: 100000000000
Sep 12 20:49:59 ruggedcom kernel: [92692.078085] __rt_task_sleep: delay from US: 2000000000
Sep 12 20:49:59 ruggedcom kernel: [92692.078091] rt_task_sleep: Thread: TASK_2: starting: Delay: 2000000000
Sep 12 20:50:01 ruggedcom kernel: [92694.068470] rt_task_sleep: Thread: TASK_1: test info: 0. Returning: 0
Sep 12 20:50:01 ruggedcom kernel: [92694.068479] __rt_task_sleep: returning: rc: 0
Sep 12 20:50:01 ruggedcom kernel: [92694.068485] __rt_task_sleep: delay from US: 2000000000
Sep 12 20:50:01 ruggedcom kernel: [92694.068511] rt_task_sleep: Thread: TASK_1: starting: Delay: 2000000000
Sep 12 20:50:01 ruggedcom kernel: [92694.068518] rt_task_sleep: Thread: TASK_0: test info: 0. Returning: 0
Sep 12 20:50:01 ruggedcom kernel: [92694.068524] __rt_task_sleep: returning: rc: 0
Sep 12 20:50:01 ruggedcom kernel: [92694.068529] __rt_task_sleep: delay from US: 2000000000
Sep 12 20:50:01 ruggedcom kernel: [92694.068535] rt_task_sleep: Thread: TASK_0: starting: Delay: 2000000000
Sep 12 20:50:01 ruggedcom kernel: [92694.068753] rt_task_sleep: Thread: TASK_2: test info: 0. Returning: 0

root@ruggedcom:~# cat sem1.c
// ./a.out <no. of threads>

#include <sys/syscall.h>
#include <sys/mman.h>
#include <stdio.h>
#include <native/task.h>
#include <native/mutex.h>
#include <native/sem.h>
#include <native/timer.h>
#include <nucleus/thread.h>
#include <rtdk.h>
#include <stdlib.h>
#include <unistd.h>

#define NANO_SEC_IN_SEC 1000000000LL

RT_TASK rt_task_array[128], task0;
char buff[8192];
RT_SEM sem1;
int tasks_are_being_spawned = 0;

void task_func(void *arg)
{
        int task_no = *(int *)arg;
        int sleep_for = 2;
        int rc = 0;

        while (1)
        {
                rt_printf("Task%i: sleeping: %llu\n", task_no, sleep_for*NANO_SEC_IN_SEC);
                rc = rt_task_sleep(sleep_for*NANO_SEC_IN_SEC);
                if (0 != rc)
                {
                        rt_printf("task %i: rt_task_sleep: rc: %i\n", task_no, rc);
                }
        }
}

#define MAX_TASKS 4096

int main(int argc, char **argv)
{
        int tasks = 0;
        char task_name[MAX_TASKS];
        int task_no[MAX_TASKS];
        int i = 0;
        int task_counter = 0;
        int rc = 0;

        // Get no. of threads to spawn.
        tasks = atoi(argv[1]);

        // Init
        mlockall(MCL_CURRENT|MCL_FUTURE);
        rt_print_auto_init(1);

        rt_task_shadow(&task0, "Task 0", 10, 0);

        rc = rt_sem_create(&sem1, "sem1", 1, S_PRIO);
        rt_printf("sem1 create. rc: %i\n", rc);

        rt_printf("Spawning tasks\n", rc);

        for (i = 0; i < tasks; i++)
        {
                sprintf(task_name, "TASK_%i", task_counter);
                task_no[i] = task_counter;
                rt_printf("Spawning: task %i. Name: %s\n", task_counter, task_name);
                rt_task_spawn(&rt_task_array[task_counter], task_name, 0, 2, 0, task_func, &task_no[task_counter]);
                task_counter++;
        }

        while (1) {
                rt_task_sleep(100000000000LL);
        }
}


----- Forwarded Message -----
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: "PRADHAN, MAKARAND (RC-CA)" <makarand.pradhan@siemens.com>; "xenomai@xenomai.org" <xenomai@xenomai.org>
Sent: Tuesday, August 5, 2014 5:23 PM
Subject: Re: [Xenomai] Question regarding rt_sem_p

On 08/05/2014 10:33 PM, PRADHAN, MAKARAND (RC-CA) wrote:
> Hi All,
>
> I am facing a unique problem related to Semaphores and would appreciate any suggestions that you may have.
>
> My system:
> CPU: DRA7xx (Arch: arm. Texas Inst, OMAP based SOC with Dual Core A-15s)
> Linux: 3.12-1

Do you have the same problem with the for-ipipe-3.14.0 branch from
ipipe-gch git, running with xenomai 2.6 git head?

--
                                                                Gilles.



_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai


This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation

Re: [Xenomai] Question regarding rt_sem_p

[Gilles Chanteperdrix]

On 09/12/2014 10:35 PM, PRADHAN, MAKARAND (RC-CA) wrote:
> Hi,
> 
> [Gilles] Do you have the same problem with the for-ipipe-3.14.0
> branch from ipipe-gch git, running with xenomai 2.6 git head?
> 
> Unfortunately I cannot upgrade the ipipe patch in the near
> foreseeable future. Our system has to continue running on Linux 3.12
> and xenomai 2.6.3 and the ipipe patch which I believe is
> ipipe-core-3.8.13-arm-3.patch.

I am not asking you to upgrade your system. I am asking you to simply
test the I-pipe patch for Linux 3.14, to see if the issue is still
there. It is a valuable information you have to provide if you want help.

-- 
                                                                Gilles.

Re: [Xenomai] Question regarding rt_sem_p

[PRADHAN, MAKARAND (RC-CA)]

Small correction:

The ipipe patch that we are using is derived from ipipe-3.12.0 branch.

Rgds,
Makarand.

-----Original Message-----
From: Xenomai [mailto:xenomai-bounces@xenomai.org] On Behalf Of PRADHAN, MAKARAND (RC-CA)
Sent: Friday, September 12, 2014 4:36 PM
To: gilles.chanteperdrix@xenomai.org
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] Question regarding rt_sem_p

Hi,

[Gilles] Do you have the same problem with the for-ipipe-3.14.0 branch from ipipe-gch git, running with xenomai 2.6 git head?

Unfortunately I cannot upgrade the ipipe patch in the near foreseeable future. Our system has to continue running on Linux 3.12 and xenomai 2.6.3 and the ipipe patch which I believe is ipipe-core-3.8.13-arm-3.patch.

Another issue noted is with rt_task_sleep. It is also returning -38. A simple test program to reproduce the problem is given at the end of the email along with a log of my session.
Tracing the kernel shows that the system call (__rt_task_sleep) is returning -4(EINTR. XNBREAK) immediately without suspending. All the same, the user space mysteriously sees a return code of -38.
The problem goes away once all the tasks have spawned and are running. This tends to indicate that it's some race condition.
I've tried powerpc and the powerpc seems to run without any issues for the same configuration.

Outside gdb this test program runs ok. All the same, we have noticed the -38 return code in other applications running xenomai even without gdb. I have not been able to write a test code that reproduces the issue without gdb.

Any pointers is resolving the issue would be highly appreciated.

Rgds,
Makarand.

My system:
CPU: DRA7xx (Arch: arm. Texas Inst, OMAP based SOC with Dual Core A-15s)
Linux: 3.12-1
Xenomai 2.6.3

Steps to reproduce the problem:
g++ sem1.c -I/usr/include/xenomai/ -lnative -lxenomai -g
root@ruggedcom:~# gdb a.out
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/a.out...done.
(gdb) run 3
Starting program: /root/a.out 3
[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb6d73460 (LWP 27232)]
sem1 create. rc: 0
Spawning tasks
Spawning: task 0. Name: TASK_0
[New Thread 0xb6d6b460 (LWP 27233)]
[New Thread 0xb6d63460 (LWP 27234)]
[New Thread 0xb6d5b460 (LWP 27235)]
Spawning: task 1. Name: TASK_1
Task0: sleeping: 2000000000
task 0: rt_task_sleep: rc: -38
Task0: sleeping: 2000000000
Spawning: task 2. Name: TASK_2
Task1: sleeping: 2000000000
task 1: rt_task_sleep: rc: -38
Task1: sleeping: 2000000000
task 0: rt_task_sleep: rc: -38
Task0: sleeping: 2000000000
Task2: sleeping: 2000000000
Task1: sleeping: 2000000000
Task0: sleeping: 2000000000
Task2: sleeping: 2000000000
Task1: sleeping: 2000000000
Task0: sleeping: 2000000000
Task2: sleeping: 2000000000
^C
Program received signal SIGINT, Interrupt.
0xb6fd16bc in rt_task_sleep (delay=100000000000) at task.c:321
321             err = XENOMAI_SKINCALL1(__native_muxid, __native_task_sleep, &delay);
(gdb) quit
A debugging session is active.

        Inferior 1 [process 27229] will be killed.

Quit anyway? (y or n) y
root@ruggedcom:~#

kern.log for an instrumented xeno_native.ko:
Sep 12 20:49:58 ruggedcom kernel: [92692.073071] __rt_task_sleep: delay from US: 2000000000 Sep 12 20:49:58 ruggedcom kernel: [92692.073082] rt_task_sleep: Thread: TASK_0: starting: Delay: 2000000000 Sep 12 20:49:58 ruggedcom kernel: [92692.073211] rt_task_sleep: Thread: TASK_0: test info: 4. Returning: -4 Sep 12 20:49:58 ruggedcom kernel: [92692.073218] __rt_task_sleep: returning: rc: -4 Sep 12 20:49:58 ruggedcom kernel: [92692.075162] __rt_task_sleep: delay from US: 2000000000 Sep 12 20:49:58 ruggedcom kernel: [92692.075171] rt_task_sleep: Thread: TASK_0: starting: Delay: 2000000000 Sep 12 20:49:58 ruggedcom kernel: [92692.075749] __rt_task_sleep: delay from US: 2000000000 Sep 12 20:49:58 ruggedcom kernel: [92692.075757] rt_task_sleep: Thread: TASK_1: starting: Delay: 2000000000 Sep 12 20:49:58 ruggedcom kernel: [92692.075886] rt_task_sleep: Thread: TASK_1: test info: 4. Returning: -4 Sep 12 20:49:58 ruggedcom kernel: [92692.075892] __rt_task_sleep: returning: rc: -4 Sep 12 20:49:58 ruggedcom kernel: [92692.075932] rt_task_sleep: Thread: TASK_0: test info: 4. Returning: -4 Sep 12 20:49:58 ruggedcom kernel: [92692.075938] __rt_task_sleep: returning: rc: -4 Sep 12 20:49:59 ruggedcom kernel: [92692.077787] __rt_task_sleep: delay from US: 2000000000 Sep 12 20:49:59 ruggedcom kernel: [92692.077795] rt_task_sleep: Thread: TASK_1: starting: Delay: 2000000000 Sep 12 20:49:59 ruggedcom kernel: [92692.077842] __rt_task_sleep: delay from US: 2000000000 Sep 12 20:49:59 ruggedcom kernel: [92692.077849] rt_task_sleep: Thread: TASK_0: starting: Delay: 2000000000 Sep 12 20:49:59 ruggedcom kernel: [92692.077960] __rt_task_sleep: delay from US: 100000000000 Sep 12 20:49:59 ruggedcom kernel: [92692.077967] rt_task_sleep: Thread: Task 0: starting: Delay: 100000000000 Sep 12 20:49:59 ruggedcom kernel: [92692.078085] __rt_task_sleep: delay from US: 2000000000 Sep 12 20:49:59 ruggedcom kernel: [92692.078091] rt_task_sleep: Thread: TASK_2: starting: Delay: 2000000000 Sep 12 20:50:01 ruggedcom kernel: [92694.068470] rt_task_sleep: Thread: TASK_1: test info: 0. Returning: 0 Sep 12 20:50:01 ruggedcom kernel: [92694.068479] __rt_task_sleep: returning: rc: 0 Sep 12 20:50:01 ruggedcom kernel: [92694.068485] __rt_task_sleep: delay from US: 2000000000 Sep 12 20:50:01 ruggedcom kernel: [92694.068511] rt_task_sleep: Thread: TASK_1: starting: Delay: 2000000000 Sep 12 20:50:01 ruggedcom kernel: [92694.068518] rt_task_sleep: Thread: TASK_0: test info: 0. Returning: 0 Sep 12 20:50:01 ruggedcom kernel: [92694.068524] __rt_task_sleep: returning: rc: 0 Sep 12 20:50:01 ruggedcom kernel: [92694.068529] __rt_task_sleep: delay from US: 2000000000 Sep 12 20:50:01 ruggedcom kernel: [92694.068535] rt_task_sleep: Thread: TASK_0: starting: Delay: 2000000000 Sep 12 20:50:01 ruggedcom kernel: [92694.068753] rt_task_sleep: Thread: TASK_2: test info: 0. Returning: 0

root@ruggedcom:~# cat sem1.c
// ./a.out <no. of threads>

#include <sys/syscall.h>
#include <sys/mman.h>
#include <stdio.h>
#include <native/task.h>
#include <native/mutex.h>
#include <native/sem.h>
#include <native/timer.h>
#include <nucleus/thread.h>
#include <rtdk.h>
#include <stdlib.h>
#include <unistd.h>

#define NANO_SEC_IN_SEC 1000000000LL

RT_TASK rt_task_array[128], task0;
char buff[8192];
RT_SEM sem1;
int tasks_are_being_spawned = 0;

void task_func(void *arg)
{
        int task_no = *(int *)arg;
        int sleep_for = 2;
        int rc = 0;

        while (1)
        {
                rt_printf("Task%i: sleeping: %llu\n", task_no, sleep_for*NANO_SEC_IN_SEC);
                rc = rt_task_sleep(sleep_for*NANO_SEC_IN_SEC);
                if (0 != rc)
                {
                        rt_printf("task %i: rt_task_sleep: rc: %i\n", task_no, rc);
                }
        }
}

#define MAX_TASKS 4096

int main(int argc, char **argv)
{
        int tasks = 0;
        char task_name[MAX_TASKS];
        int task_no[MAX_TASKS];
        int i = 0;
        int task_counter = 0;
        int rc = 0;

        // Get no. of threads to spawn.
        tasks = atoi(argv[1]);

        // Init
        mlockall(MCL_CURRENT|MCL_FUTURE);
        rt_print_auto_init(1);

        rt_task_shadow(&task0, "Task 0", 10, 0);

        rc = rt_sem_create(&sem1, "sem1", 1, S_PRIO);
        rt_printf("sem1 create. rc: %i\n", rc);

        rt_printf("Spawning tasks\n", rc);

        for (i = 0; i < tasks; i++)
        {
                sprintf(task_name, "TASK_%i", task_counter);
                task_no[i] = task_counter;
                rt_printf("Spawning: task %i. Name: %s\n", task_counter, task_name);
                rt_task_spawn(&rt_task_array[task_counter], task_name, 0, 2, 0, task_func, &task_no[task_counter]);
                task_counter++;
        }

        while (1) {
                rt_task_sleep(100000000000LL);
        }
}


----- Forwarded Message -----
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: "PRADHAN, MAKARAND (RC-CA)" <makarand.pradhan@siemens.com>; "xenomai@xenomai.org" <xenomai@xenomai.org>
Sent: Tuesday, August 5, 2014 5:23 PM
Subject: Re: [Xenomai] Question regarding rt_sem_p

On 08/05/2014 10:33 PM, PRADHAN, MAKARAND (RC-CA) wrote:
> Hi All,
>
> I am facing a unique problem related to Semaphores and would appreciate any suggestions that you may have.
>
> My system:
> CPU: DRA7xx (Arch: arm. Texas Inst, OMAP based SOC with Dual Core
> A-15s)
> Linux: 3.12-1

Do you have the same problem with the for-ipipe-3.14.0 branch from ipipe-gch git, running with xenomai 2.6 git head?

--
                                                                Gilles.



_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai


This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation

Re: [Xenomai] Question regarding rt_sem_p

[Gilles Chanteperdrix]

On 09/12/2014 10:52 PM, PRADHAN, MAKARAND (RC-CA) wrote:
> Small correction:
> 
> The ipipe patch that we are using is derived from ipipe-3.12.0 branch.

This means a patch that has not even been tested. It just fixes merge
conflicts, and has been compile checked, it has not run on real
hardware. The one which has been tested on real hardware is the I-pipe
patch for 3.14.0 or 3.14.17.


-- 
                                                                Gilles.

Re: [Xenomai] Question regarding rt_sem_p

[Lennart Sorensen]

On Fri, Sep 12, 2014 at 10:54:21PM +0200, Gilles Chanteperdrix wrote:
> On 09/12/2014 10:52 PM, PRADHAN, MAKARAND (RC-CA) wrote:
> > Small correction:
> > 
> > The ipipe patch that we are using is derived from ipipe-3.12.0 branch.
> 
> This means a patch that has not even been tested. It just fixes merge
> conflicts, and has been compile checked, it has not run on real
> hardware. The one which has been tested on real hardware is the I-pipe
> patch for 3.14.0 or 3.14.17.

Well 3.12 did pass the xenomai testsuite.

Unfortunately TI isn't quite done moving their patches to the 3.14
branch yet, so we are still stuck at 3.12 (And the 3.8 branch was way
too unstable to use for anything at all even before considering xenomai).
Problem with new chips is that they aren't merged into the official
kernel yet, so jumping to a new kernel version isn't trivial.

I will be checking if the 3.14 branch has enough to boot on Monday
(A lot of stuff was merged in yesterday so it might be getting close now).

-- 
Len Sorensen

Re: [Xenomai] Question regarding rt_sem_p

[Gilles Chanteperdrix]

On 09/14/2014 04:44 AM, Lennart Sorensen wrote:
> On Fri, Sep 12, 2014 at 10:54:21PM +0200, Gilles Chanteperdrix wrote:
>> On 09/12/2014 10:52 PM, PRADHAN, MAKARAND (RC-CA) wrote:
>>> Small correction:
>>>
>>> The ipipe patch that we are using is derived from ipipe-3.12.0 branch.
>>
>> This means a patch that has not even been tested. It just fixes merge
>> conflicts, and has been compile checked, it has not run on real
>> hardware. The one which has been tested on real hardware is the I-pipe
>> patch for 3.14.0 or 3.14.17.
> 
> Well 3.12 did pass the xenomai testsuite.
> 
> Unfortunately TI isn't quite done moving their patches to the 3.14
> branch yet, so we are still stuck at 3.12 (And the 3.8 branch was way
> too unstable to use for anything at all even before considering xenomai).
> Problem with new chips is that they aren't merged into the official
> kernel yet, so jumping to a new kernel version isn't trivial.
> 
> I will be checking if the 3.14 branch has enough to boot on Monday
> (A lot of stuff was merged in yesterday so it might be getting close now).
> 
I am almost sure I fixed an issue with user-space getting -EINTR with
gdb. I simply did not want to look for the commit if you still have the
issue with 3.14. If 3.14 does not boot, it looks like I will have to
search the commit anyway.

-- 
                                                                Gilles.

Re: [Xenomai] Question regarding rt_sem_p

[Philippe Gerum]

On 09/14/2014 05:27 AM, Gilles Chanteperdrix wrote:
> On 09/14/2014 04:44 AM, Lennart Sorensen wrote:
>> On Fri, Sep 12, 2014 at 10:54:21PM +0200, Gilles Chanteperdrix wrote:
>>> On 09/12/2014 10:52 PM, PRADHAN, MAKARAND (RC-CA) wrote:
>>>> Small correction:
>>>>
>>>> The ipipe patch that we are using is derived from ipipe-3.12.0 branch.
>>>
>>> This means a patch that has not even been tested. It just fixes merge
>>> conflicts, and has been compile checked, it has not run on real
>>> hardware. The one which has been tested on real hardware is the I-pipe
>>> patch for 3.14.0 or 3.14.17.
>>
>> Well 3.12 did pass the xenomai testsuite.
>>
>> Unfortunately TI isn't quite done moving their patches to the 3.14
>> branch yet, so we are still stuck at 3.12 (And the 3.8 branch was way
>> too unstable to use for anything at all even before considering xenomai).
>> Problem with new chips is that they aren't merged into the official
>> kernel yet, so jumping to a new kernel version isn't trivial.
>>
>> I will be checking if the 3.14 branch has enough to boot on Monday
>> (A lot of stuff was merged in yesterday so it might be getting close now).
>>
> I am almost sure I fixed an issue with user-space getting -EINTR with
> gdb. I simply did not want to look for the commit if you still have the
> issue with 3.14. If 3.14 does not boot, it looks like I will have to
> search the commit anyway.
> 

Could be this one, which also fixed a spurious assertion trigger:
http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.14&id=d7a5e4762535f55bfff8eafbf1c1dde214d09bd6

-- 
Philippe.

Re: [Xenomai] Question regarding rt_sem_p

[Gilles Chanteperdrix]

On 09/14/2014 09:40 AM, Philippe Gerum wrote:
> On 09/14/2014 05:27 AM, Gilles Chanteperdrix wrote:
>> On 09/14/2014 04:44 AM, Lennart Sorensen wrote:
>>> On Fri, Sep 12, 2014 at 10:54:21PM +0200, Gilles Chanteperdrix wrote:
>>>> On 09/12/2014 10:52 PM, PRADHAN, MAKARAND (RC-CA) wrote:
>>>>> Small correction:
>>>>>
>>>>> The ipipe patch that we are using is derived from ipipe-3.12.0 branch.
>>>>
>>>> This means a patch that has not even been tested. It just fixes merge
>>>> conflicts, and has been compile checked, it has not run on real
>>>> hardware. The one which has been tested on real hardware is the I-pipe
>>>> patch for 3.14.0 or 3.14.17.
>>>
>>> Well 3.12 did pass the xenomai testsuite.
>>>
>>> Unfortunately TI isn't quite done moving their patches to the 3.14
>>> branch yet, so we are still stuck at 3.12 (And the 3.8 branch was way
>>> too unstable to use for anything at all even before considering xenomai).
>>> Problem with new chips is that they aren't merged into the official
>>> kernel yet, so jumping to a new kernel version isn't trivial.
>>>
>>> I will be checking if the 3.14 branch has enough to boot on Monday
>>> (A lot of stuff was merged in yesterday so it might be getting close now).
>>>
>> I am almost sure I fixed an issue with user-space getting -EINTR with
>> gdb. I simply did not want to look for the commit if you still have the
>> issue with 3.14. If 3.14 does not boot, it looks like I will have to
>> search the commit anyway.
>>
> 
> Could be this one, which also fixed a spurious assertion trigger:
> http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.14&id=d7a5e4762535f55bfff8eafbf1c1dde214d09bd6
> 
Indeed, that is the one.

-- 
                                                                Gilles.

Re: [Xenomai] Question regarding rt_sem_p

[PRADHAN, MAKARAND (RC-CA)]

Hi,

I've tried the commit and it seems to work. Am running more tests.

Thanks everyone.

Warm Rgds,
Makarand.

-----Original Message-----
From: Xenomai [mailto:xenomai-bounces@xenomai.org] On Behalf Of Gilles Chanteperdrix
Sent: Sunday, September 14, 2014 11:05 AM
To: Philippe Gerum; Lennart Sorensen
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] Question regarding rt_sem_p

On 09/14/2014 09:40 AM, Philippe Gerum wrote:
> On 09/14/2014 05:27 AM, Gilles Chanteperdrix wrote:
>> On 09/14/2014 04:44 AM, Lennart Sorensen wrote:
>>> On Fri, Sep 12, 2014 at 10:54:21PM +0200, Gilles Chanteperdrix wrote:
>>>> On 09/12/2014 10:52 PM, PRADHAN, MAKARAND (RC-CA) wrote:
>>>>> Small correction:
>>>>>
>>>>> The ipipe patch that we are using is derived from ipipe-3.12.0 branch.
>>>>
>>>> This means a patch that has not even been tested. It just fixes
>>>> merge conflicts, and has been compile checked, it has not run on
>>>> real hardware. The one which has been tested on real hardware is
>>>> the I-pipe patch for 3.14.0 or 3.14.17.
>>>
>>> Well 3.12 did pass the xenomai testsuite.
>>>
>>> Unfortunately TI isn't quite done moving their patches to the 3.14
>>> branch yet, so we are still stuck at 3.12 (And the 3.8 branch was
>>> way too unstable to use for anything at all even before considering xenomai).
>>> Problem with new chips is that they aren't merged into the official
>>> kernel yet, so jumping to a new kernel version isn't trivial.
>>>
>>> I will be checking if the 3.14 branch has enough to boot on Monday
>>> (A lot of stuff was merged in yesterday so it might be getting close now).
>>>
>> I am almost sure I fixed an issue with user-space getting -EINTR with
>> gdb. I simply did not want to look for the commit if you still have
>> the issue with 3.14. If 3.14 does not boot, it looks like I will have
>> to search the commit anyway.
>>
>
> Could be this one, which also fixed a spurious assertion trigger:
> http://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.14&id=d7a5e4762535f
> 55bfff8eafbf1c1dde214d09bd6
>
Indeed, that is the one.

--
                                                                Gilles.

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation

Re: [Xenomai] Question regarding rt_sem_p

[Lennart Sorensen]

On Sun, Sep 14, 2014 at 05:27:04AM +0200, Gilles Chanteperdrix wrote:
> I am almost sure I fixed an issue with user-space getting -EINTR with
> gdb. I simply did not want to look for the commit if you still have the
> issue with 3.14. If 3.14 does not boot, it looks like I will have to
> search the commit anyway.

I am trying to bacport the 3.14 git tree to 3.12 (so far looking not
too hard).  Just trying to get any of the fixes 3.14 has to see if it
helps (the commit mentioned did help with some things, so gdb works now).

I spotted this though that looks like a mistake (although clearly harmless
is CONFIG_IPIPE is enabled)

diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index b30a292..27376a0 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -242,6 +242,10 @@ u64 sched_clock_cpu(int cpu)
        struct sched_clock_data *scd;
        u64 clock;
        
+#ifndef CONFIG_IPIPE
+       WARN_ON_ONCE(!irqs_disabled());
+#endif 
+
        if (sched_clock_stable())
                return sched_clock();
                

The kernel purposely removed that warning, so why should the ipipe patch
put it back, and only when ipipe is disabled?

-- 
Len Sorensen

Re: [Xenomai] Question regarding rt_sem_p

[Jan Kiszka]

On 2014-09-16 17:56, Lennart Sorensen wrote:
> On Sun, Sep 14, 2014 at 05:27:04AM +0200, Gilles Chanteperdrix wrote:
>> I am almost sure I fixed an issue with user-space getting -EINTR with
>> gdb. I simply did not want to look for the commit if you still have the
>> issue with 3.14. If 3.14 does not boot, it looks like I will have to
>> search the commit anyway.
> 
> I am trying to bacport the 3.14 git tree to 3.12 (so far looking not
> too hard).  Just trying to get any of the fixes 3.14 has to see if it
> helps (the commit mentioned did help with some things, so gdb works now).
> 
> I spotted this though that looks like a mistake (although clearly harmless
> is CONFIG_IPIPE is enabled)
> 
> diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
> index b30a292..27376a0 100644
> --- a/kernel/sched/clock.c
> +++ b/kernel/sched/clock.c
> @@ -242,6 +242,10 @@ u64 sched_clock_cpu(int cpu)
>         struct sched_clock_data *scd;
>         u64 clock;
>         
> +#ifndef CONFIG_IPIPE
> +       WARN_ON_ONCE(!irqs_disabled());
> +#endif 
> +
>         if (sched_clock_stable())
>                 return sched_clock();
>                 
> 
> The kernel purposely removed that warning, so why should the ipipe patch
> put it back, and only when ipipe is disabled?
> 

Usually such things come in when merge conflicts are resolved.

Upstream replaced local_irq_disable with preempt_enable/disable for the
sched clock. That's fine for our usage, tracing, as we have that under
control when I-pipe is enabled. Without I-pipe, this piece will cause a
false-positive. So a patch to remove this also in 3.14 is definitely
welcome.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Question regarding rt_sem_p

[Lennart Sorensen]

On Sat, Sep 13, 2014 at 10:44:50PM -0400, Lennart Sorensen wrote:
> Well 3.12 did pass the xenomai testsuite.
> 
> Unfortunately TI isn't quite done moving their patches to the 3.14
> branch yet, so we are still stuck at 3.12 (And the 3.8 branch was way
> too unstable to use for anything at all even before considering xenomai).
> Problem with new chips is that they aren't merged into the official
> kernel yet, so jumping to a new kernel version isn't trivial.
> 
> I will be checking if the 3.14 branch has enough to boot on Monday
> (A lot of stuff was merged in yesterday so it might be getting close now).

Still no bootable 3.14 kernel for the dra7xx.

So instead I backported the ipipe-3.14 branch to 3.12.27 and so far it
is running and I haven't seen any issues with it yet, so time to test
if that solves any of the issues we have seen.

And I updated xenomai to the latest xenomai-2.6 git tree while at it too.

Running the xeno-regression-test on it now, although it passed before
so who knows.

-- 
Len Sorensen