* [Xenomai-help] Scheduling while atomic
@ 2006-01-16 16:09 Jeroen Van den Keybus
2006-01-16 17:26 ` Jan Kiszka
2006-01-16 17:31 ` Gilles Chanteperdrix
0 siblings, 2 replies; 5+ messages in thread
From: Jeroen Van den Keybus @ 2006-01-16 16:09 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
I got a fair number of 'scheduling while atomic' entries in the dmesg log
after running a multithread Xenomai program. What do they mean ?
Jeroen.
[-- Attachment #2: Type: text/html, Size: 200 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-help] Scheduling while atomic
2006-01-16 16:09 [Xenomai-help] Scheduling while atomic Jeroen Van den Keybus
@ 2006-01-16 17:26 ` Jan Kiszka
2006-01-16 17:31 ` Gilles Chanteperdrix
1 sibling, 0 replies; 5+ messages in thread
From: Jan Kiszka @ 2006-01-16 17:26 UTC (permalink / raw)
To: Jeroen Van den Keybus; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
Jeroen Van den Keybus wrote:
> I got a fair number of 'scheduling while atomic' entries in the dmesg log
> after running a multithread Xenomai program. What do they mean ?
>
Backtraces, i.e. the dmesg logs, please.
The general meaning is that the Linux scheduler was invoked in a
non-schedulable context, e.g. with preemption lock held. The precise
meaning can only be derived from that output.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-help] Scheduling while atomic
2006-01-16 16:09 [Xenomai-help] Scheduling while atomic Jeroen Van den Keybus
2006-01-16 17:26 ` Jan Kiszka
@ 2006-01-16 17:31 ` Gilles Chanteperdrix
[not found] ` <fd6a47a90601170609u594d4fd4k@domain.hid>
1 sibling, 1 reply; 5+ messages in thread
From: Gilles Chanteperdrix @ 2006-01-16 17:31 UTC (permalink / raw)
To: Jeroen Van den Keybus; +Cc: xenomai
Jeroen Van den Keybus wrote:
> I got a fair number of 'scheduling while atomic' entries in the dmesg log
> after running a multithread Xenomai program. What do they mean ?
You may have found a bug. Could you provide an program (preferably as
short as possible) which causes these messages ?
--
Gilles Chanteperdrix.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Xenomai-help] Scheduling while atomic
[not found] ` <fd6a47a90601170609u594d4fd4k@domain.hid>
@ 2006-01-17 14:11 ` Jeroen Van den Keybus
2006-01-17 15:45 ` [Xenomai-core] " Gilles Chanteperdrix
1 sibling, 0 replies; 5+ messages in thread
From: Jeroen Van den Keybus @ 2006-01-17 14:11 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 19588 bytes --]
Gilles, Jan,
The offending program is quite complex (several .c files and
a considerable .h file tree) and involves 2 computers. However, I think I
can narrow down the problem to concurrent access (from 2 Xenomai threads in
2nd domain) to the same Linux file descriptor for a TCP/IP connection.
In order to rule this out, I have put RT_MUTEXes around the send() and
recv() calls.However, I still received 'scheduling while atomic'. Further
investigation, however, has shown that the mutexes seem to fail:
rt_mutex_enquire() returns 0 or even -1 after acquisition of the lock. With
this program, I didn't (yet) receive the 'scheduling...' error, but by
increasing the task repetition rate, it should be a matter of (a long) time
(both tasks arriving at a blocking write).
I have compiled a program that represents the structure of the original
program. Could you have a look and see if I'm not making a mistake here ?
For proper following up, I've also attached the dmesg log asked for earlier
by Jan.
/* TEST_MUTEX.C */
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <signal.h>
#include <math.h>
#include <native/task.h>
#include <native/mutex.h>
#include <native/sem.h>
int fd, err;
RT_MUTEX m;
RT_SEM s;
#define CHECK(arg) check(arg, __LINE__)
int check(int r, int n)
{
if (r != 0)
fprintf(stderr, "L%d: %s.\n", n, strerror(-r));
return(r);
}
void output(char c) {
static int cnt = 0;
int n;
char buf[2];
RT_MUTEX_INFO mutexinfo;
buf[0] = c;
if (cnt == 80) {
buf[1] = '\n';
n = 2;
cnt = 0;
}
else {
n = 1;
cnt++;
}
CHECK(rt_mutex_inquire(&m, &mutexinfo));
if (mutexinfo.lockcnt <= 0) {
RT_TASK_INFO taskinfo;
CHECK(rt_task_inquire(NULL, &taskinfo));
fprintf(stderr, "ALERT: No lock! (lockcnt=%d) Offending task: %s\n",
mutexinfo.lockcnt, taskinfo.name );
}
if (write(fd, buf, n) != n) {
fprintf(stderr, "File write error.\n");
CHECK(rt_sem_v(&s));
}
}
void task0(void *arg)
{
while (1) {
CHECK(rt_task_sleep((float)rand()*1.0e7/(float)RAND_MAX));
CHECK(rt_mutex_lock(&m, TM_INFINITE));
output('0');
CHECK(rt_mutex_unlock(&m));
}
}
void task1(void *arg)
{
while (1) {
CHECK(rt_task_sleep((float)rand()*1.0e7/(float)RAND_MAX));
CHECK(rt_mutex_lock(&m, TM_INFINITE));
output('1');
CHECK(rt_mutex_unlock(&m));
}
}
void sighandler(int arg)
{
CHECK(rt_sem_v(&s));
}
int main(int argc, char *argv[])
{
RT_TASK t, t0, t1;
if ((fd = open("dump.txt", O_CREAT | O_RDWR)) < 0)
fprintf(stderr, "File open error.\n");
else {
CHECK(rt_timer_start(TM_ONESHOT));
CHECK(rt_mutex_create(&m, "mutex"));
CHECK(rt_sem_create(&s, "sem", 0, S_PRIO));
signal(SIGINT, sighandler);
CHECK(rt_task_create(&t0, "task0", 0, 30, T_FPU));
CHECK(rt_task_start(&t0, task0, NULL));
CHECK(rt_task_create(&t1, "task1", 0, 29, T_FPU));
CHECK(rt_task_start(&t1, task1, NULL));
CHECK(rt_task_shadow(&t, "main", 1, T_FPU));
CHECK(rt_sem_p(&s, TM_INFINITE));
signal(SIGINT, SIG_IGN);
CHECK(rt_task_delete(&t1));
CHECK(rt_task_delete(&t0));
CHECK(rt_sem_delete(&s));
CHECK(rt_mutex_delete(&m));
rt_timer_stop();
close(fd);
}
return 0;
}
Compiled with GCC 4.0.2:
gcc mtest.c -o mtest $(xeno-config --xeno-cflags) $(xeno-config
---xeno-ldflags)
Run on kernel 2.6.15, Adeos 1.1-03, Xenomai SVN rev. 462
dmesg output (usually not that long - the truncated first line is actually
there - it is not the top of the dmesg log):
pe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
scheduling while atomic: ext_upload/0x00000002/12490
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0148ade>] ipipe_trace_end+0x35/0x37
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
note: ext_upload[12490] exited with preempt_count 2
scheduling while atomic: ext_upload/0x00000002/12661
[<c03b4c64>] schedule+0x4b4/0x790
[<c011a0ca>] __wake_up_sync+0x67/0xb8
[<c0155455>] xnshadow_harden+0xc6/0xdd
[<c0156c5b>] losyscall_event+0x8c/0x1c0
[<c0147473>] __ipipe_dispatch_event+0x90/0x173
[<c011697a>] __ipipe_syscall_root+0x36/0x110
[<c0103434>] system_call+0x20/0x41
note: ext_upload[12661] exited with preempt_count 2
[-- Attachment #2: Type: text/html, Size: 27176 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Xenomai-core] Re: [Xenomai-help] Scheduling while atomic
[not found] ` <fd6a47a90601170609u594d4fd4k@domain.hid>
2006-01-17 14:11 ` Jeroen Van den Keybus
@ 2006-01-17 15:45 ` Gilles Chanteperdrix
1 sibling, 0 replies; 5+ messages in thread
From: Gilles Chanteperdrix @ 2006-01-17 15:45 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 1694 bytes --]
Jeroen Van den Keybus wrote:
> Gilles, Jan,
>
>
> The offending program is quite complex (several .c files and
> a considerable .h file tree) and involves 2 computers. However, I think I
> can narrow down the problem to concurrent access (from 2 Xenomai threads in
> 2nd domain) to the same Linux file descriptor for a TCP/IP connection.
>
> In order to rule this out, I have put RT_MUTEXes around the send() and
> recv() calls.However, I still received 'scheduling while atomic'. Further
> investigation, however, has shown that the mutexes seem to fail:
> rt_mutex_enquire() returns 0 or even -1 after acquisition of the lock. With
> this program, I didn't (yet) receive the 'scheduling...' error, but by
> increasing the task repetition rate, it should be a matter of (a long) time
> (both tasks arriving at a blocking write).
>
> I have compiled a program that represents the structure of the original
> program. Could you have a look and see if I'm not making a mistake here ?
>
> For proper following up, I've also attached the dmesg log asked for earlier
> by Jan.
Looking at the message log, it seems xnshadow_harden is called at a
point where irqs are disabled. But is there no other error before these
"scheduling while atomic" messages ? If not, could you try and enable
the nucleus debugging ?
In case there is no error before the error messages, even with nucleus
debugging activated, I attached a patch which breaks nklock and
activates interrupts on xnshadow_harden entry and restore the caller
state on xnshadow_harden exit. Could you test it and report if you still
see the "scheduling while atomic" messages ?
--
Gilles Chanteperdrix.
[-- Attachment #2: xeno-harden.diff --]
[-- Type: text/plain, Size: 1128 bytes --]
Index: ksrc/nucleus/shadow.c
===================================================================
--- ksrc/nucleus/shadow.c (revision 464)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -439,13 +439,17 @@
preemption. */
struct __gatekeeper *gk = &gatekeeper[task_cpu(this_task)];
xnthread_t *thread = xnshadow_thread(this_task);
+ spl_t s;
if (!thread)
return -EPERM;
+ xnlock_get_irqsave(&nklock, s);
+ xnlock_clear_irqon(&nklock);
+
if (signal_pending(this_task) ||
down_interruptible(&gk->sync)) /* Grab the request token. */
- return -ERESTARTSYS;
+ goto out_interrupted;
xnltt_log_event(xeno_ev_primarysw,this_task->comm);
@@ -495,6 +499,8 @@
thread->name,
xnthread_user_pid(thread));
#endif /* CONFIG_XENO_OPT_DEBUG */
+out_interrupted:
+ xnlock_put_irqrestore(&nklock, s);
return -ERESTARTSYS;
}
}
@@ -510,7 +516,7 @@
if (xnthread_signaled_p(thread))
xnpod_dispatch_signals();
- xnlock_clear_irqon(&nklock);
+ xnlock_put_irqrestore(&nklock, s);
xnltt_log_event(xeno_ev_primary,thread->name);
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-01-17 15:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-16 16:09 [Xenomai-help] Scheduling while atomic Jeroen Van den Keybus
2006-01-16 17:26 ` Jan Kiszka
2006-01-16 17:31 ` Gilles Chanteperdrix
[not found] ` <fd6a47a90601170609u594d4fd4k@domain.hid>
2006-01-17 14:11 ` Jeroen Van den Keybus
2006-01-17 15:45 ` [Xenomai-core] " Gilles Chanteperdrix
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.