* [Xenomai] Question regarding rt_sem_p @ 2014-08-05 20:33 PRADHAN, MAKARAND (RC-CA) 2014-08-05 21:23 ` Gilles Chanteperdrix 0 siblings, 1 reply; 14+ messages in thread From: PRADHAN, MAKARAND (RC-CA) @ 2014-08-05 20:33 UTC (permalink / raw) To: xenomai@xenomai.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-08-05 20:33 [Xenomai] Question regarding rt_sem_p PRADHAN, MAKARAND (RC-CA) @ 2014-08-05 21:23 ` Gilles Chanteperdrix [not found] ` <1410537098.19920.YahooMailNeo@web142606.mail.bf1.yahoo.com> 0 siblings, 1 reply; 14+ messages in thread From: Gilles Chanteperdrix @ 2014-08-05 21:23 UTC (permalink / raw) To: PRADHAN, MAKARAND (RC-CA), xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <1410537098.19920.YahooMailNeo@web142606.mail.bf1.yahoo.com>]
* Re: [Xenomai] Question regarding rt_sem_p [not found] ` <1410537098.19920.YahooMailNeo@web142606.mail.bf1.yahoo.com> @ 2014-09-12 20:35 ` PRADHAN, MAKARAND (RC-CA) 2014-09-12 20:38 ` Gilles Chanteperdrix 2014-09-12 20:52 ` PRADHAN, MAKARAND (RC-CA) 0 siblings, 2 replies; 14+ messages in thread From: PRADHAN, MAKARAND (RC-CA) @ 2014-09-12 20:35 UTC (permalink / raw) To: gilles.chanteperdrix@xenomai.org; +Cc: xenomai@xenomai.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-12 20:35 ` PRADHAN, MAKARAND (RC-CA) @ 2014-09-12 20:38 ` Gilles Chanteperdrix 2014-09-12 20:52 ` PRADHAN, MAKARAND (RC-CA) 1 sibling, 0 replies; 14+ messages in thread From: Gilles Chanteperdrix @ 2014-09-12 20:38 UTC (permalink / raw) To: PRADHAN, MAKARAND (RC-CA); +Cc: xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-12 20:35 ` PRADHAN, MAKARAND (RC-CA) 2014-09-12 20:38 ` Gilles Chanteperdrix @ 2014-09-12 20:52 ` PRADHAN, MAKARAND (RC-CA) 2014-09-12 20:54 ` Gilles Chanteperdrix 1 sibling, 1 reply; 14+ messages in thread From: PRADHAN, MAKARAND (RC-CA) @ 2014-09-12 20:52 UTC (permalink / raw) To: PRADHAN, MAKARAND (RC-CA), gilles.chanteperdrix@xenomai.org Cc: xenomai@xenomai.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-12 20:52 ` PRADHAN, MAKARAND (RC-CA) @ 2014-09-12 20:54 ` Gilles Chanteperdrix 2014-09-14 2:44 ` Lennart Sorensen 0 siblings, 1 reply; 14+ messages in thread From: Gilles Chanteperdrix @ 2014-09-12 20:54 UTC (permalink / raw) To: PRADHAN, MAKARAND (RC-CA); +Cc: xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-12 20:54 ` Gilles Chanteperdrix @ 2014-09-14 2:44 ` Lennart Sorensen 2014-09-14 3:27 ` Gilles Chanteperdrix 2014-09-18 16:49 ` Lennart Sorensen 0 siblings, 2 replies; 14+ messages in thread From: Lennart Sorensen @ 2014-09-14 2:44 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-14 2:44 ` Lennart Sorensen @ 2014-09-14 3:27 ` Gilles Chanteperdrix 2014-09-14 7:40 ` Philippe Gerum 2014-09-16 15:56 ` Lennart Sorensen 2014-09-18 16:49 ` Lennart Sorensen 1 sibling, 2 replies; 14+ messages in thread From: Gilles Chanteperdrix @ 2014-09-14 3:27 UTC (permalink / raw) To: Lennart Sorensen; +Cc: xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-14 3:27 ` Gilles Chanteperdrix @ 2014-09-14 7:40 ` Philippe Gerum 2014-09-14 15:05 ` Gilles Chanteperdrix 2014-09-16 15:56 ` Lennart Sorensen 1 sibling, 1 reply; 14+ messages in thread From: Philippe Gerum @ 2014-09-14 7:40 UTC (permalink / raw) To: Gilles Chanteperdrix, Lennart Sorensen; +Cc: xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-14 7:40 ` Philippe Gerum @ 2014-09-14 15:05 ` Gilles Chanteperdrix 2014-09-15 15:09 ` PRADHAN, MAKARAND (RC-CA) 0 siblings, 1 reply; 14+ messages in thread From: Gilles Chanteperdrix @ 2014-09-14 15:05 UTC (permalink / raw) To: Philippe Gerum, Lennart Sorensen; +Cc: xenomai@xenomai.org 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-14 15:05 ` Gilles Chanteperdrix @ 2014-09-15 15:09 ` PRADHAN, MAKARAND (RC-CA) 0 siblings, 0 replies; 14+ messages in thread From: PRADHAN, MAKARAND (RC-CA) @ 2014-09-15 15:09 UTC (permalink / raw) To: Gilles Chanteperdrix, Philippe Gerum, Lennart Sorensen Cc: xenomai@xenomai.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-14 3:27 ` Gilles Chanteperdrix 2014-09-14 7:40 ` Philippe Gerum @ 2014-09-16 15:56 ` Lennart Sorensen 2014-09-16 17:52 ` Jan Kiszka 1 sibling, 1 reply; 14+ messages in thread From: Lennart Sorensen @ 2014-09-16 15:56 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-16 15:56 ` Lennart Sorensen @ 2014-09-16 17:52 ` Jan Kiszka 0 siblings, 0 replies; 14+ messages in thread From: Jan Kiszka @ 2014-09-16 17:52 UTC (permalink / raw) To: Lennart Sorensen, Gilles Chanteperdrix; +Cc: xenomai@xenomai.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] Question regarding rt_sem_p 2014-09-14 2:44 ` Lennart Sorensen 2014-09-14 3:27 ` Gilles Chanteperdrix @ 2014-09-18 16:49 ` Lennart Sorensen 1 sibling, 0 replies; 14+ messages in thread From: Lennart Sorensen @ 2014-09-18 16:49 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-09-18 16:49 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-05 20:33 [Xenomai] Question regarding rt_sem_p PRADHAN, MAKARAND (RC-CA)
2014-08-05 21:23 ` Gilles Chanteperdrix
[not found] ` <1410537098.19920.YahooMailNeo@web142606.mail.bf1.yahoo.com>
2014-09-12 20:35 ` PRADHAN, MAKARAND (RC-CA)
2014-09-12 20:38 ` Gilles Chanteperdrix
2014-09-12 20:52 ` PRADHAN, MAKARAND (RC-CA)
2014-09-12 20:54 ` Gilles Chanteperdrix
2014-09-14 2:44 ` Lennart Sorensen
2014-09-14 3:27 ` Gilles Chanteperdrix
2014-09-14 7:40 ` Philippe Gerum
2014-09-14 15:05 ` Gilles Chanteperdrix
2014-09-15 15:09 ` PRADHAN, MAKARAND (RC-CA)
2014-09-16 15:56 ` Lennart Sorensen
2014-09-16 17:52 ` Jan Kiszka
2014-09-18 16:49 ` Lennart Sorensen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.