* [Xenomai-help] Native message queue and synchronisation
@ 2009-08-17 15:03 Berruer Sébastien
2009-08-19 16:09 ` Gilles Chanteperdrix
0 siblings, 1 reply; 13+ messages in thread
From: Berruer Sébastien @ 2009-08-17 15:03 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 4402 bytes --]
Hello,
I'm trying to make some basic test code using the native API of Xenomai. I declare two tasks (a consumer and a producer) and one queue from the main.
- the producer get the system time and pass it throw a named queue
- the consumer is supposed to block on the queue, waiting until the value is available in the queue
I issue a problem around the call to rt_queue_read().
- when I run the actual code, the application hangs. As if, there were no means for mesure_task to write in the queue.
- if I comment the sleep in the mesure_task and uncomment the one in display_task, the sleep is long enough (!) for data to be written and so, the call is issued correctly.
The parameter TM_INFINITE seems to be the cause. I can't figure why because, in the documentation, it's supposed to be rescheduled if there is no message yet.
I include my code and hope you can point me out what I am doing wrong.
I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture (PXA255).
Best regards,
#include <stdlib.h>
#include <sys/mman.h>
#include <native/queue.h>
#include <native/task.h>
#include <native/timer.h>
#define ONE_BILLION 1000000000
#define ONE_MILLION 1000000
#define LOOP_NB 10
#define LOOP_DELAY 2 * ONE_BILLION
char queue_name[] = "exchange_data";
void display(void* cookie)
{
RT_QUEUE disp_q;
RTIME disp;
int err, ret;
err = rt_queue_bind(&disp_q, queue_name, TM_INFINITE);
if(err) {
perror("Unable to find the queue");
return;
}
/*put a delay to be sure that other task write something*/
/*rt_task_sleep(LOOP_DELAY);*/
ret = rt_queue_read(&disp_q, (void*)&disp, sizeof(RTIME), TM_INFINITE);
if(ret < 0)
perror("Error reading");
else
printf("Value read from the queue: %lli\n", disp);
err = rt_queue_unbind(&disp_q);
if(err != 0) {
perror("Unable to release the queue");
return;
}
return;
}
void mesure(void* cookie)
{
RTIME date;
RT_QUEUE mes_q;
int err, ret;
err = rt_queue_bind(&mes_q, queue_name, TM_INFINITE);
if(err) {
perror("Unable to find the queue");
return;
}
/*put a delay to be sure that other task block on queue*/
rt_task_sleep(LOOP_DELAY);
date = rt_timer_read();
ret = rt_queue_write(&mes_q, (void*)&date, sizeof(RTIME), Q_NORMAL);
if(ret < 0)
perror("Error writing");
err = rt_queue_unbind(&mes_q);
if(err != 0) {
perror("Unable to release the queue");
return;
}
return;
}
int main(int argc, char* argv[])
{
RT_QUEUE queue;
RT_TASK display_task, mesure_task;
int err;
mlockall(MCL_CURRENT|MCL_FUTURE);
err = rt_queue_create(&queue, queue_name, sizeof(int), Q_UNLIMITED, Q_FIFO|Q_SHARED);
if(err) {
perror("Unable to create the queue");
exit(EXIT_FAILURE);
}
err = rt_task_create(&display_task, "display task", 0, 0, T_FPU|T_JOINABLE);
err = rt_task_create(&mesure_task, "mesure task", 10, 0, T_FPU|T_JOINABLE);
if(err) {
perror("Unable to create a task");
exit(EXIT_FAILURE);
}
err = rt_task_start(&display_task, &display, NULL);
err = rt_task_start(&mesure_task, &mesure, NULL);
if(err) {
perror("Unable to start a task");
exit(EXIT_FAILURE);
}
/*wait for terminaison of tasks*/
rt_task_join(&mesure_task);
rt_task_join(&display_task);
/*delete all previously allocated ressources*/
err = rt_task_delete(&display_task);
err = rt_task_delete(&mesure_task);
err = rt_queue_delete(&queue);
exit(EXIT_SUCCESS);
}
=================================
| BERRUER Sébastien |
| Trainee at Altran Ouest |
| Centre d'Affaires Alphasis |
| 35760 Saint-Grégoire - FRANCE |
| Tel: 06-76-35-29-55 |
=================================
[-- Attachment #2: Type: text/html, Size: 9053 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Xenomai-help] Native message queue and synchronisation
2009-08-17 15:03 [Xenomai-help] Native message queue and synchronisation Berruer Sébastien
@ 2009-08-19 16:09 ` Gilles Chanteperdrix
2009-08-20 7:13 ` [Xenomai-help] RE : " Berruer Sébastien
0 siblings, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2009-08-19 16:09 UTC (permalink / raw)
To: Berruer Sébastien; +Cc: xenomai
Berruer Sébastien wrote:
> I include my code and hope you can point me out what I am doing wrong.
> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
> (PXA255).
Could you try Xenomai 2.4.9?
--
Gilles
^ permalink raw reply [flat|nested] 13+ messages in thread* [Xenomai-help] RE : Native message queue and synchronisation
2009-08-19 16:09 ` Gilles Chanteperdrix
@ 2009-08-20 7:13 ` Berruer Sébastien
2009-08-21 9:02 ` Gilles Chanteperdrix
0 siblings, 1 reply; 13+ messages in thread
From: Berruer Sébastien @ 2009-08-20 7:13 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
Hi,
>> I include my code and hope you can point me out what I am doing wrong.
>> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
>> (PXA255).
>
>Could you try Xenomai 2.4.9?
I did it yesterday with the version 2.4.9. But, I still issue the same problem with the same code.
I recently pointed out another problem: during the deletion of a task descriptor, I receive the error value -3 (-ESRCH). I quickly checked it and, that's right, she didn't appear in the /proc/registry.
May it be a registration problem for the queue, too?
=================================
| BERRUER Sébastien |
| Trainee at Altran Ouest |
| Centre d'Affaires Alphasis |
| 35760 Saint-Grégoire - FRANCE |
| Tel: 06-76-35-29-55 |
=================================
[-- Attachment #2: Type: text/html, Size: 1528 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] RE : Native message queue and synchronisation
2009-08-20 7:13 ` [Xenomai-help] RE : " Berruer Sébastien
@ 2009-08-21 9:02 ` Gilles Chanteperdrix
2009-08-21 14:13 ` Berruer Sébastien
0 siblings, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2009-08-21 9:02 UTC (permalink / raw)
To: Berruer Sébastien; +Cc: xenomai
Berruer Sébastien wrote:
> Hi,
>
>>> I include my code and hope you can point me out what I am doing wrong.
>>> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
>>> (PXA255).
>>
>>Could you try Xenomai 2.4.9?
>
>
>
> I did it yesterday with the version 2.4.9. But, I still issue the same
> problem with the same code.
>
> I recently pointed out another problem: during the deletion of a task
> descriptor, I receive the error value -3 (-ESRCH). I quickly checked it
> and, that's right, she didn't appear in the /proc/registry.
>
> May it be a registration problem for the queue, too?
Ok. Please keep 2.4.8. I did not try to reproduce the bug yet, but in the
mean time, could you try the following patch?
diff --git a/ksrc/skins/native/queue.c b/ksrc/skins/native/queue.c
index 8b7c43e..9184da6 100644
--- a/ksrc/skins/native/queue.c
+++ b/ksrc/skins/native/queue.c
@@ -228,7 +228,8 @@ int rt_queue_create(RT_QUEUE *q,
err = xnheap_init_mapped(&q->bufpool,
poolsize,
- (mode & Q_DMA) ? GFP_DMA : 0);
+ XNARCH_SHARED_HEAP_FLAGS |
+ ((mode & Q_DMA) ? GFP_DMA : 0));
if (err)
return err;
--
Gilles
^ permalink raw reply related [flat|nested] 13+ messages in thread* [Xenomai-help] RE : Native message queue and synchronisation
2009-08-21 9:02 ` Gilles Chanteperdrix
@ 2009-08-21 14:13 ` Berruer Sébastien
2009-08-21 14:18 ` Gilles Chanteperdrix
2009-08-21 22:23 ` Gilles Chanteperdrix
0 siblings, 2 replies; 13+ messages in thread
From: Berruer Sébastien @ 2009-08-21 14:13 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]
Hi,
>>>> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
>>>> (PXA255).
>>>
>>>Could you try Xenomai 2.4.9?
>>
>> I did it yesterday with the version 2.4.9. But, I still issue the same
>> problem with the same code.
>>
>
>Ok. Please keep 2.4.8. I did not try to reproduce the bug yet, but in the
>mean time, could you try the following patch?
>
>diff --git a/ksrc/skins/native/queue.c b/ksrc/skins/native/queue.c
>index 8b7c43e..9184da6 100644
>--- a/ksrc/skins/native/queue.c
>+++ b/ksrc/skins/native/queue.c
>@@ -228,7 +228,8 @@ int rt_queue_create(RT_QUEUE *q,
>
> err = xnheap_init_mapped(&q->bufpool,
> poolsize,
>- (mode & Q_DMA) ? GFP_DMA : 0);
>+ XNARCH_SHARED_HEAP_FLAGS |
>+ ((mode & Q_DMA) ? GFP_DMA : 0));
> if (err)
> return err;
I've applied the patch against library's sources.
In fact, if I remove the sleep from the "display" routine, it works. But, I can't assert what was the scheduling of threads. Maybe, it was favourable to the other thread to write the data.
If I enable the sleep call in "mesure" routine, I still issue the same problem that before: the system hangs. I tried to investigate the role of sleep, but it's a little confuse to me for debugging. Furthermore, the hang doesn't append in the reverse situation. I'm keeping in that way, waiting if you've got a better idea.
Thanks,
+================================
| BERRUER Sébastien
| Trainee at Altran Ouest
| Centre d'Affaires Alphasis
| 35760 Saint-Grégoire - FRANCE
| Tel: 06-76-35-29-55
+================================
[-- Attachment #2: Type: text/html, Size: 3605 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] RE : Native message queue and synchronisation
2009-08-21 14:13 ` Berruer Sébastien
@ 2009-08-21 14:18 ` Gilles Chanteperdrix
2009-08-21 22:23 ` Gilles Chanteperdrix
1 sibling, 0 replies; 13+ messages in thread
From: Gilles Chanteperdrix @ 2009-08-21 14:18 UTC (permalink / raw)
To: Berruer Sébastien; +Cc: xenomai
Berruer Sébastien wrote:
> Hi,
>
>>>>> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
>>>>> (PXA255).
>>>>
>>>>Could you try Xenomai 2.4.9?
>>>
>>> I did it yesterday with the version 2.4.9. But, I still issue the same
>>> problem with the same code.
>>>
>>
>>Ok. Please keep 2.4.8. I did not try to reproduce the bug yet, but in the
>>mean time, could you try the following patch?
>>
>>diff --git a/ksrc/skins/native/queue.c b/ksrc/skins/native/queue.c
>>index 8b7c43e..9184da6 100644
>>--- a/ksrc/skins/native/queue.c
>>+++ b/ksrc/skins/native/queue.c
>>@@ -228,7 +228,8 @@ int rt_queue_create(RT_QUEUE *q,
>>
>> err = xnheap_init_mapped(&q->bufpool,
>> poolsize,
>>- (mode & Q_DMA) ? GFP_DMA : 0);
>>+ XNARCH_SHARED_HEAP_FLAGS |
>>+ ((mode & Q_DMA) ? GFP_DMA : 0));
>> if (err)
>> return err;
>
> I've applied the patch against library's sources.
The code modified by the patch is kernel only, not library. So, in
particular you should recompile Xenomai kernel-space support. Did you do
this.
>
> In fact, if I remove the sleep from the "display" routine, it works.
> But, I can't assert what was the scheduling of threads. Maybe, it was
> favourable to the other thread to write the data.
>
> If I enable the sleep call in "mesure" routine, I still issue the same
> problem that before: the system hangs.
How does it hang? Do you get a message on the serial console?
--
Gilles
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Xenomai-help] RE : Native message queue and synchronisation
2009-08-21 14:13 ` Berruer Sébastien
2009-08-21 14:18 ` Gilles Chanteperdrix
@ 2009-08-21 22:23 ` Gilles Chanteperdrix
2009-08-24 9:17 ` Berruer Sébastien
1 sibling, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2009-08-21 22:23 UTC (permalink / raw)
To: Berruer Sébastien; +Cc: xenomai
Berruer Sébastien wrote:
> Hi,
>
>>>>> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
>>>>> (PXA255).
>>>>
>>>>Could you try Xenomai 2.4.9?
>>>
>>> I did it yesterday with the version 2.4.9. But, I still issue the same
>>> problem with the same code.
>>>
>>
>>Ok. Please keep 2.4.8. I did not try to reproduce the bug yet, but in the
>>mean time, could you try the following patch?
>>
>>diff --git a/ksrc/skins/native/queue.c b/ksrc/skins/native/queue.c
>>index 8b7c43e..9184da6 100644
>>--- a/ksrc/skins/native/queue.c
>>+++ b/ksrc/skins/native/queue.c
>>@@ -228,7 +228,8 @@ int rt_queue_create(RT_QUEUE *q,
>>
>> err = xnheap_init_mapped(&q->bufpool,
>> poolsize,
>>- (mode & Q_DMA) ? GFP_DMA : 0);
>>+ XNARCH_SHARED_HEAP_FLAGS |
>>+ ((mode & Q_DMA) ? GFP_DMA : 0));
>> if (err)
>> return err;
>
> I've applied the patch against library's sources.
>
> In fact, if I remove the sleep from the "display" routine, it works.
> But, I can't assert what was the scheduling of threads. Maybe, it was
> favourable to the other thread to write the data.
>
> If I enable the sleep call in "mesure" routine, I still issue the same
> problem that before: the system hangs. I tried to investigate the role
> of sleep, but it's a little confuse to me for debugging. Furthermore,
> the hang doesn't append in the reverse situation. I'm keeping in that
> way, waiting if you've got a better idea.
Ok. Your test program was tested on ppc and ARM, and works as far as we
can tell. So, unless you show us your full serial console trace, from
boot to the oops/or panic if any, as welll as your kernel configuration,
we will consider this issue closed.
--
Gilles.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Xenomai-help] RE : Native message queue and synchronisation
2009-08-21 22:23 ` Gilles Chanteperdrix
@ 2009-08-24 9:17 ` Berruer Sébastien
2009-08-24 9:36 ` Gilles Chanteperdrix
0 siblings, 1 reply; 13+ messages in thread
From: Berruer Sébastien @ 2009-08-24 9:17 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 8016 bytes --]
Hi,
Sorry for the delay, I've issued a problem using the serial line.
As I can see in the Oops trace, the problem is due to my compiler. I'll checked my compilation parameters or a newer version of my compiler.
I can also see that there is a problem with the CPU_FREQ option. It's mentioned as a "latency killer" in the TROUBLESHOOTING document. I'll checked it too.
Thanks a lot,
Linux version 2.6.28-dirty (berruer@domain.hid) (gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)) #2 Fri Aug 21 16:46:20 CEST 2009
CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE), cr=0000397f
CPU: VIVT data cache, VIVT instruction cache
Machine: Arcom/Eurotech VIPER SBC
Memory policy: ECC disabled, Data cache writeback
Memory clock: 99.53MHz (*27)
Run Mode clock: 99.53MHz (*1)
Turbo Mode clock: 99.53MHz (*1.0, inactive)
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: root=/dev/nfs nfsroot=/srv/nfsboot,nfsvers=3,tcp ip=192.168.0.118:192.168.0.117:::::off: console=ttyS1,115200
PID hash table entries: 256 (order: 8, 1024 bytes)
I-pipe 1.12-02: pipeline enabled.
Console: colour dummy device 80x30
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 62004KB available (2500K code, 263K data, 100K init)
Calibrating delay loop... 99.32 BogoMIPS (lpj=496640)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 288 bytes
NET: Registered protocol family 16
viper: hardware v2i3 detected. CPLD revision 1.
I2C: i2c-0: PXA I2C adapter
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
PXA CPU frequency change support initialized
CPU PXA: Unknown policy found. Using CPUFREQ_POLICY_PERFORMANCE
CPU PXA: Unknown policy found. Using CPUFREQ_POLICY_PERFORMANCE
CPU PXA: Unknown policy found. Using CPUFREQ_POLICY_PERFORMANCE
CPU PXA: Unknown policy found. Using CPUFREQ_POLICY_PERFORMANCE
I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: real-time nucleus v2.4.8 (Lords Of Karma) loaded.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 121
io scheduler noop registered
io scheduler deadline registered (default)
pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 38) is a FFUART
pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 37) is a BTUART
console [ttyS1] enabled
pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 36) is a STUART
pxa2xx-uart.3: ttyS3 at MMIO 0x41600000 (irq = 23) is a HWUART
smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@domain.hid>
eth0: SMC91C11xFD (rev 1) at c486c300 IRQ 24 [nowait]
eth0: Ethernet addr: 00:80:66:10:52:b3
physmap platform flash device: 02000000 at 04000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.0 at offset 0x0
3 RedBoot partitions found on MTD device physmap-flash.0
Creating 3 MTD partitions on "physmap-flash.0":
0x00000000-0x0001f000 : "FIS directory"
mtd: partition "FIS directory" doesn't end on an erase block -- force read-only
0x0001f000-0x00020000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't start on an erase block boundary -- force read-only
0x00020000-0x02000000 : "filesystem"
physmap platform flash device: 00100000 at 00000000
Found: AMD AM29LV800BB
physmap-flash.1: Found 1 x16 devices at 0x0 in 16-bit bank
number of JEDEC chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.1 at offset 0x0
No RedBoot partition table detected in physmap-flash.1
Using physmap partition information
Creating 1 MTD partitions on "physmap-flash.1":
0x00000000-0x00100000 : "RedBoot"
i2c /dev entries driver
i2c-gpio i2c-gpio.1: using pins 83 (SDA) and 84 (SCL)
CPU PXA: Unknown policy found. Using CPUFREQ_POLICY_PERFORMANCE
CPU PXA: Unknown policy found. Using CPUFREQ_POLICY_PERFORMANCE
CPU PXA: Unknown policy found. Using CPUFREQ_POLICY_PERFORMANCE
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
XScale DSP coprocessor detected.
eth0: link down
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.0.118, mask=255.255.255.0, gw=255.255.255.255,
host=192.168.0.118, domain=, nis-domain=(none),
bootserver=192.168.0.117, rootserver=192.168.0.117, rootpath=
Looking up port of RPC 100003/3 on 192.168.0.117
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Looking up port of RPC 100005/3 on 192.168.0.117
VFS: Mounted root (nfs filesystem).
Freeing init memory: 100K
INIT: version 2.86 booting
hwclock: can't open '/dev/misc/rtc': No such file or directory
INIT: Entering runlevel: 3
login[303]: root login on 'pts/0'
Internal error: Oops - undefined instruction: 0 [#1]
Modules linked in:
CPU: 0 Not tainted (2.6.28-dirty #2)
PC is at dsp_do+0x34/0x54
LR is at notifier_call_chain+0x34/0x78
pc : [<c0027c80>] lr : [<c004dd68>] psr: 60000093
sp : c0293f10 ip : c0293f20 fp : c0293f1c
r10: c0292000 r9 : 69052d06 r8 : 00000002
r7 : c39e2000 r6 : 00000000 r5 : fffffffe r4 : 00000000
r3 : c0292000 r2 : c0293f10 r1 : 00000002 r0 : c39e2000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 0000397f Table: a39cc000 DAC: 00000015
Process swapper (pid: 0, stack limit = 0xc0292270)
Stack: (0xc0293f10 to 0xc0294000)
3f00: c0293f44 c0293f20 c004dd68 c0027c58
3f20: c39e201c c02950c0 00000015 c3823680 c38b2960 69052d06 c0293f5c c0293f48
3f40: c004ddc8 c004dd40 00000000 c02ad700 c0293f74 c0293f60 c004ddf0 c004ddb8
3f60: 00000000 c0292000 c0293f9c c0293f78 c0021fe8 c004dddc c00236e0 c0292000
3f80: c029eb60 c0295d40 a0019ea0 a0019e38 c0293fb4 c0293fa0 c00235dc c0206a3c
3fa0: c02c7e58 c02accc0 c0293fc4 c0293fb8 c0205294 c002359c c0293ff4 c0293fc8
3fc0: c00089cc c0205248 c0008380 00000000 00000000 c001bd98 00000000 0000397d
3fe0: c02acdd8 c001bd94 00000000 c0293ff8 a0008034 c000879c 00000000 00000000
Backtrace:
[<c0027c4c>] (dsp_do+0x0/0x54) from [<c004dd68>] (notifier_call_chain+0x34/0x78)
[<c004dd34>] (notifier_call_chain+0x0/0x78) from [<c004ddc8>] (__atomic_notifier_call_chain+0x1c/0x24)
r9:69052d06 r8:c38b2960 r7:c3823680 r6:00000015 r5:c02950c0
r4:c39e201c
[<c004ddac>] (__atomic_notifier_call_chain+0x0/0x24) from [<c004ddf0>] (atomic_notifier_call_chain+0x20/0x28)
[<c004ddd0>] (atomic_notifier_call_chain+0x0/0x28) from [<c0021fe8>] (__switch_to+0x30/0x38)
[<c0206a30>] (schedule+0x0/0x400) from [<c00235dc>] (cpu_idle+0x4c/0x58)
[<c0023590>] (cpu_idle+0x0/0x58) from [<c0205294>] (rest_init+0x58/0x6c)
r5:c02accc0 r4:c02c7e58
[<c020523c>] (rest_init+0x0/0x6c) from [<c00089cc>] (start_kernel+0x23c/0x288)
[<c0008790>] (start_kernel+0x0/0x288) from [<a0008034>] (0xa0008034)
r6:c001bd94 r5:c02acdd8 r4:0000397d
Code: 1a000008 e1a0200d e3c23d7f e3c3303f (ec521000)
---[ end trace 0ae9945a496219a0 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
+================================
| BERRUER Sébastien
| Trainee at Altran Ouest
| Centre d'Affaires Alphasis
| 35760 Saint-Grégoire - FRANCE
| Tel: 06-76-35-29-55
+================================
[-- Attachment #2: Type: text/html, Size: 9685 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Xenomai-help] RE : Native message queue and synchronisation
2009-08-24 9:17 ` Berruer Sébastien
@ 2009-08-24 9:36 ` Gilles Chanteperdrix
2009-08-25 7:26 ` Berruer Sébastien
0 siblings, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2009-08-24 9:36 UTC (permalink / raw)
To: Berruer Sébastien; +Cc: xenomai
Berruer Sébastien wrote:
> Hi,
>
> Sorry for the delay, I've issued a problem using the serial line.
>
> As I can see in the Oops trace, the problem is due to my compiler. I'll
> checked my compilation parameters or a newer version of my compiler.
No. The problem is due to the FPU handling. Coud you try and apply the
patch below to Xenomai sources?
Once you have done that, recompile the kernel and user-space, and be
sure, when you compile Xenomai user-space applications to compile them
not to use the FPU, by passing -msoft-float in the CFLAGS.
Please keep us informed.
> I can also see that there is a problem with the CPU_FREQ option. It's
> mentioned as a "latency killer" in the TROUBLESHOOTING document. I'll
> checked it too.
Yes, you should disable CPU_FREQ.
--
Gilles
diff --git a/ksrc/arch/arm/switch.S b/ksrc/arch/arm/switch.S
index a7c3dba..384f2cd 100644
--- a/ksrc/arch/arm/switch.S
+++ b/ksrc/arch/arm/switch.S
@@ -102,10 +102,12 @@ ENTRY(rthal_thread_switch)
strex r5, r4, [ip] @ Clear exclusive monitor
#endif
#endif
+#if 0
#if defined(CONFIG_CPU_XSCALE) && !defined(CONFIG_IWMMXT)
mra r4, r5, acc0
stmia ip, {r4, r5}
#endif
+#endif
#if defined(CONFIG_HAS_TLS_REG)
mcr p15, 0, r3, c13, c0, 3 @ set TLS register
#elif !defined(CONFIG_TLS_REG_EMUL)
@@ -129,6 +131,7 @@ ENTRY(rthal_thread_switch)
#endif
VFPFMXR FPEXC, r4
#endif
+#if 0
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 18) &&
defined(CONFIG_IWMMXT)
bl iwmmxt_task_switch
#endif
@@ -137,13 +140,16 @@ ENTRY(rthal_thread_switch)
ldmib r4, {r4, r5}
mar acc0, r4, r5
#endif
+#endif
add r4, r2, #TI_CPU_SAVE
+#if 0
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 18) &&
defined(CONFIG_IWMMXT)
mov r5, r0
mov r0, r2
bl iwmmxt_task_switch
mov r0, r5
-#endif
+#endif
+#endif
ldmia r4, {r4 - sl, fp, sp, pc} @ Load all regs saved
previously
/*
^ permalink raw reply related [flat|nested] 13+ messages in thread* [Xenomai-help] RE : Native message queue and synchronisation
2009-08-24 9:36 ` Gilles Chanteperdrix
@ 2009-08-25 7:26 ` Berruer Sébastien
2009-08-25 8:12 ` Gilles Chanteperdrix
0 siblings, 1 reply; 13+ messages in thread
From: Berruer Sébastien @ 2009-08-25 7:26 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 2961 bytes --]
Hello,
It works for me.
It also solve some problem for me using the latency program in the test suite. I suppose it was the same kind of lock.
There is still the registration problem, that cause an error at the deletion of the task. If it persists and I can find any information from the mail archive, I'll opened a new thread.
Thank you for help,
+================================
| BERRUER Sébastien
| Trainee at Altran Ouest
| Centre d'Affaires Alphasis
| 35760 Saint-Grégoire - FRANCE
| Tel: 06-76-35-29-55
+================================
-------- Message d'origine--------
De: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
Date: lun. 24/08/2009 11:36
À: Berruer Sébastien
Cc: xenomai@xenomai.org
Objet : Re: RE : [Xenomai-help] Native message queue and synchronisation
Berruer Sébastien wrote:
> Hi,
>
> Sorry for the delay, I've issued a problem using the serial line.
>
> As I can see in the Oops trace, the problem is due to my compiler. I'll
> checked my compilation parameters or a newer version of my compiler.
No. The problem is due to the FPU handling. Coud you try and apply the
patch below to Xenomai sources?
Once you have done that, recompile the kernel and user-space, and be
sure, when you compile Xenomai user-space applications to compile them
not to use the FPU, by passing -msoft-float in the CFLAGS.
Please keep us informed.
> I can also see that there is a problem with the CPU_FREQ option. It's
> mentioned as a "latency killer" in the TROUBLESHOOTING document. I'll
> checked it too.
Yes, you should disable CPU_FREQ.
--
Gilles
diff --git a/ksrc/arch/arm/switch.S b/ksrc/arch/arm/switch.S
index a7c3dba..384f2cd 100644
--- a/ksrc/arch/arm/switch.S
+++ b/ksrc/arch/arm/switch.S
@@ -102,10 +102,12 @@ ENTRY(rthal_thread_switch)
strex r5, r4, [ip] @ Clear exclusive monitor
#endif
#endif
+#if 0
#if defined(CONFIG_CPU_XSCALE) && !defined(CONFIG_IWMMXT)
mra r4, r5, acc0
stmia ip, {r4, r5}
#endif
+#endif
#if defined(CONFIG_HAS_TLS_REG)
mcr p15, 0, r3, c13, c0, 3 @ set TLS register
#elif !defined(CONFIG_TLS_REG_EMUL)
@@ -129,6 +131,7 @@ ENTRY(rthal_thread_switch)
#endif
VFPFMXR FPEXC, r4
#endif
+#if 0
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 18) &&
defined(CONFIG_IWMMXT)
bl iwmmxt_task_switch
#endif
@@ -137,13 +140,16 @@ ENTRY(rthal_thread_switch)
ldmib r4, {r4, r5}
mar acc0, r4, r5
#endif
+#endif
add r4, r2, #TI_CPU_SAVE
+#if 0
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 18) &&
defined(CONFIG_IWMMXT)
mov r5, r0
mov r0, r2
bl iwmmxt_task_switch
mov r0, r5
-#endif
+#endif
+#endif
ldmia r4, {r4 - sl, fp, sp, pc} @ Load all regs saved
previously
/*
[-- Attachment #2: Type: text/html, Size: 4942 bytes --]
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [Xenomai-help] RE : Native message queue and synchronisation
2009-08-25 7:26 ` Berruer Sébastien
@ 2009-08-25 8:12 ` Gilles Chanteperdrix
2009-08-25 14:53 ` [Xenomai-help] RE : " Berruer Sébastien
0 siblings, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2009-08-25 8:12 UTC (permalink / raw)
To: Berruer Sébastien; +Cc: xenomai
Berruer Sébastien wrote:
> Hello,
>
> It works for me.
>
> It also solve some problem for me using the latency program in the test
> suite. I suppose it was the same kind of lock.
An issue with the latency test is the first thing you should mention. We
know the latency program is supposed to work without any problem, not
the programs you write.
Could you try something: with the patch still applied, could you try to
compile Xenomai user-space without the -msoft-float option?
>
> There is still the registration problem, that cause an error at the
> deletion of the task. If it persists and I can find any information from
> the mail archive, I'll opened a new thread.
Please post a short example exhibiting the bug you think you found.
--
Gilles
^ permalink raw reply [flat|nested] 13+ messages in thread* [Xenomai-help] RE : RE : Native message queue and synchronisation
2009-08-25 8:12 ` Gilles Chanteperdrix
@ 2009-08-25 14:53 ` Berruer Sébastien
2009-08-25 15:19 ` Gilles Chanteperdrix
0 siblings, 1 reply; 13+ messages in thread
From: Berruer Sébastien @ 2009-08-25 14:53 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]
Hello,
>
>Could you try something: with the patch still applied, could you try to
>compile Xenomai user-space without the -msoft-float option?
I've done the compilation of the kernel support with both previous patches applied.
I've done the compilation of the user space support once with CFLAGS=-msoft-float, and once without.
I've run almost all the applications from the testsuite. However, some noticed points;
- I can't run irqbench. I've got the following error:
root@domain.hid:$ ./irqbench/run
*
*
* Type ^C to stop this application.
*
*
irqloop: error starting test: Inappropriate ioctl for device
Must I used the serial RT driver from Xenomai for this test?
- When I run swithtest without any argument, I receive the message:
root@domain.hid:$ ./switchtest/run
*
*
* Type ^C to stop this application.
*
*
== Testing FPU check routines...
== FPU check routines: unimplemented, skipping FPU switches tests.
== Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
RTT| 00:00:01
RTH|ctx switches|-------total
RTD| 900| 900
RTD| 891| 1791
RTD| 909| 2700
RTD| 909| 3609
RTD| 900| 4509
RTD| 909| 5418
RTD| 909| 6327
RTD| 909| 7236
RTD| 900| 8136
RTD| 909| 9045
RTD| 909| 9954
But nothing appear when I explicitly run:
root@domain.hid:$ ./switchtest/run rtup_ufpp
*
*
* Type ^C to stop this application.
*
*
== Threads: sleeper_ufps-0 rtup_ufpp-1
RTT| 00:00:01
RTH|ctx switches|-------total
RTD| 200| 200
RTD| 198| 398
RTD| 202| 600
RTD| 202| 802
RTD| 202| 1004
RTD| 202| 1206
RTD| 200| 1406
RTD| 202| 1608
RTD| 200| 1808
Maybe some of this already have a solution. I report the results and try to find some ideas on mail archive.
Thanks a lot,
+================================
| BERRUER Sébastien
| Trainee at Altran Ouest
| Centre d'Affaires Alphasis
| 35760 Saint-Grégoire - FRANCE
| Tel: 06-76-35-29-55
+================================
[-- Attachment #2: Type: text/html, Size: 4614 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] RE : RE : Native message queue and synchronisation
2009-08-25 14:53 ` [Xenomai-help] RE : " Berruer Sébastien
@ 2009-08-25 15:19 ` Gilles Chanteperdrix
0 siblings, 0 replies; 13+ messages in thread
From: Gilles Chanteperdrix @ 2009-08-25 15:19 UTC (permalink / raw)
To: Berruer Sébastien; +Cc: xenomai
Berruer Sébastien wrote:
> Hello,
>
>>
>>Could you try something: with the patch still applied, could you try to
>>compile Xenomai user-space without the -msoft-float option?
>
> I've done the compilation of the kernel support with both previous
> patches applied.
>
>
> I've done the compilation of the user space support once with
> CFLAGS=-msoft-float, and once without.
>
>
> I've run almost all the applications from the testsuite. However, some
> noticed points;
> - I can't run irqbench. I've got the following error:
>
> root@domain.hid:$ ./irqbench/run
> *
> *
> * Type ^C to stop this application.
> *
> *
> irqloop: error starting test: Inappropriate ioctl for device
>
> Must I used the serial RT driver from Xenomai for this test?
>
> - When I run swithtest without any argument, I receive the message:
Yes, irqbench only works on x86, as far as I know.
> root@domain.hid:$ ./switchtest/run
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Testing FPU check routines...
> == FPU check routines: unimplemented, skipping FPU switches tests.
> == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
> RTT| 00:00:01
> RTH|ctx switches|-------total
> RTD| 900| 900
> RTD| 891| 1791
> RTD| 909| 2700
> RTD| 909| 3609
> RTD| 900| 4509
> RTD| 909| 5418
> RTD| 909| 6327
> RTD| 909| 7236
> RTD| 900| 8136
> RTD| 909| 9045
> RTD| 909| 9954
>
> But nothing appear when I explicitly run:
Yes, using FPU in Xenomai applications only works with VFP. The Xscale
FPU support is unimplemented.
>
> root@domain.hid:$ ./switchtest/run rtup_ufpp
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Threads: sleeper_ufps-0 rtup_ufpp-1
> RTT| 00:00:01
> RTH|ctx switches|-------total
> RTD| 200| 200
> RTD| 198| 398
> RTD| 202| 600
> RTD| 202| 802
> RTD| 202| 1004
> RTD| 202| 1206
> RTD| 200| 1406
> RTD| 202| 1608
> RTD| 200| 1808
It does not really make sense to try this configuration, since the
Xscale fpu support is unsupported. Though I think it should exit with an
error instead of doing what it currently does.
--
Gilles
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-08-25 15:19 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-17 15:03 [Xenomai-help] Native message queue and synchronisation Berruer Sébastien
2009-08-19 16:09 ` Gilles Chanteperdrix
2009-08-20 7:13 ` [Xenomai-help] RE : " Berruer Sébastien
2009-08-21 9:02 ` Gilles Chanteperdrix
2009-08-21 14:13 ` Berruer Sébastien
2009-08-21 14:18 ` Gilles Chanteperdrix
2009-08-21 22:23 ` Gilles Chanteperdrix
2009-08-24 9:17 ` Berruer Sébastien
2009-08-24 9:36 ` Gilles Chanteperdrix
2009-08-25 7:26 ` Berruer Sébastien
2009-08-25 8:12 ` Gilles Chanteperdrix
2009-08-25 14:53 ` [Xenomai-help] RE : " Berruer Sébastien
2009-08-25 15:19 ` 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.