Adeos/Xenomai - blocage pendant l'exécution des tests
86 views
Skip to first unread message
AleaJactaEst
Sep 29, 2012, 10:45:10 AM9/29/12
to concours-li...@googlegroups.com
Bonjour,
J'essaye de démarrer avec le temps réel Adeos/Xenomai.
Mais tous les tests se terminent par un blocage.
visiblement, j'ai un problème de timer.
test avec latency :
# latency -f
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
test avec clocktest :
# clocktest
== Tested clock: 0 (CLOCK_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 -1196309965381617.2 101524.200 0 0.0
test avec xeno-test :
# xeno-test
Started child 804: /bin/sh /usr/bin/xeno-test-run-wrapper /usr/bin/xeno-test
+ echo 0
+ /usr/bin/arith
mul: 0x79364d93, shft: 26
integ: 30, frac: 0x4d9364d9364d9364
signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 238.473 ns, rejected 2/10000
inlined llimd: 0x79364d9364d9362f: 5360.822 ns, rejected 12/10000
inlined llmulshft: 0x79364d92ffffffe1: 103.041 ns, rejected 3/10000
inlined nodiv_llimd: 0x79364d9364d9362f: 198.935 ns, rejected 5/10000
out of line calibration: 0x0000000000000000: 262.569 ns, rejected 3/10000
out of line llimd: 0x79364d9364d9362f: 5337.426 ns, rejected 21/10000
out of line llmulshft: 0x79364d92ffffffe1: 80.640 ns, rejected 8/10000
out of line nodiv_llimd: 0x79364d9364d9362f: 174.556 ns, rejected 5/10000
signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 238.628 ns, rejected 1/10000
inlined llimd: 0x86c9b26c9b26c9d1: 5360.869 ns, rejected 15/10000
inlined llmulshft: 0x86c9b26d0000001e: 103.764 ns, rejected 5/10000
inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 198.591 ns, rejected 7/10000
out of line calibration: 0x0000000000000000: 262.734 ns, rejected 3/10000
out of line llimd: 0x86c9b26c9b26c9d1: 5335.055 ns, rejected 14/10000
out of line llmulshft: 0x86c9b26d0000001e: 80.178 ns, rejected 5/10000
out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 174.568 ns, rejected 5/10000
unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 238.509 ns, rejected 1/10000
inlined nodiv_ullimd: 0x79364d9364d9362f: 147.272 ns, rejected 7/10000
out of line calibration: 0x0000000000000000: 262.734 ns, rejected 2/10000
out of line nodiv_ullimd: 0x79364d9364d9362f: 168.310 ns, rejected 4/10000
+ /usr/bin/clocktest -C 42 -T 30
== Tested clock: 42 (CLOCK_HOST_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 0.0 0.000 0 0.0
clock_gettime failed for clock id 42
hostrt data area is not live
+ /usr/bin/clocktest -T 30
== Tested clock: 0 (CLOCK_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 0.0 0.000 0 0.0
Analyse :
# cat /proc/xenomai/sched
CPU PID CLASS PRI TIMEOUT TIMEBASE STAT NAME
0 0 idle -1 - master R ROOT
0 823 rt 0 - master W display-822
0 824 rt 99 �� À� ��Y��N� 99 master Dt sampling-822
# cat /proc/interrupts
CPU0
24: 0 s3c s3c2410-rtc tick
30: 18310 s3c S3C2410 Timer Tick
32: 0 s3c s3c2410-lcd
37: 0 s3c s3c-mci
43: 8 s3c s3c2440-i2c
46: 0 s3c s3c2410-rtc alarm
51: 16155 s3c-ext eth0
60: 0 s3c-ext s3c-mci
70: 26 s3c-uart0 s3c2440-uart
71: 128 s3c-uart0 s3c2440-uart
79: 0 s3c-adc s3c2410_ts_pen
80: 0 s3c-adc s3c24xx-adc
83: 0 - s3c2410-wdt
Err: 0
après le blocage, la commande date renvoie toujours la même information.
Avez-vous une piste?
@+
AleaJactaEst
J'essaye de démarrer avec le temps réel Adeos/Xenomai.
Mais tous les tests se terminent par un blocage.
visiblement, j'ai un problème de timer.
test avec latency :
# latency -f
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
test avec clocktest :
# clocktest
== Tested clock: 0 (CLOCK_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 -1196309965381617.2 101524.200 0 0.0
test avec xeno-test :
# xeno-test
Started child 804: /bin/sh /usr/bin/xeno-test-run-wrapper /usr/bin/xeno-test
+ echo 0
+ /usr/bin/arith
mul: 0x79364d93, shft: 26
integ: 30, frac: 0x4d9364d9364d9364
signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 238.473 ns, rejected 2/10000
inlined llimd: 0x79364d9364d9362f: 5360.822 ns, rejected 12/10000
inlined llmulshft: 0x79364d92ffffffe1: 103.041 ns, rejected 3/10000
inlined nodiv_llimd: 0x79364d9364d9362f: 198.935 ns, rejected 5/10000
out of line calibration: 0x0000000000000000: 262.569 ns, rejected 3/10000
out of line llimd: 0x79364d9364d9362f: 5337.426 ns, rejected 21/10000
out of line llmulshft: 0x79364d92ffffffe1: 80.640 ns, rejected 8/10000
out of line nodiv_llimd: 0x79364d9364d9362f: 174.556 ns, rejected 5/10000
signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 238.628 ns, rejected 1/10000
inlined llimd: 0x86c9b26c9b26c9d1: 5360.869 ns, rejected 15/10000
inlined llmulshft: 0x86c9b26d0000001e: 103.764 ns, rejected 5/10000
inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 198.591 ns, rejected 7/10000
out of line calibration: 0x0000000000000000: 262.734 ns, rejected 3/10000
out of line llimd: 0x86c9b26c9b26c9d1: 5335.055 ns, rejected 14/10000
out of line llmulshft: 0x86c9b26d0000001e: 80.178 ns, rejected 5/10000
out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 174.568 ns, rejected 5/10000
unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 238.509 ns, rejected 1/10000
inlined nodiv_ullimd: 0x79364d9364d9362f: 147.272 ns, rejected 7/10000
out of line calibration: 0x0000000000000000: 262.734 ns, rejected 2/10000
out of line nodiv_ullimd: 0x79364d9364d9362f: 168.310 ns, rejected 4/10000
+ /usr/bin/clocktest -C 42 -T 30
== Tested clock: 42 (CLOCK_HOST_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 0.0 0.000 0 0.0
clock_gettime failed for clock id 42
hostrt data area is not live
+ /usr/bin/clocktest -T 30
== Tested clock: 0 (CLOCK_REALTIME)
CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
--- -------------------- ---------------- ---------- --------------
0 0.0 0.000 0 0.0
Analyse :
# cat /proc/xenomai/sched
CPU PID CLASS PRI TIMEOUT TIMEBASE STAT NAME
0 0 idle -1 - master R ROOT
0 823 rt 0 - master W display-822
0 824 rt 99 �� À� ��Y��N� 99 master Dt sampling-822
# cat /proc/interrupts
CPU0
24: 0 s3c s3c2410-rtc tick
30: 18310 s3c S3C2410 Timer Tick
32: 0 s3c s3c2410-lcd
37: 0 s3c s3c-mci
43: 8 s3c s3c2440-i2c
46: 0 s3c s3c2410-rtc alarm
51: 16155 s3c-ext eth0
60: 0 s3c-ext s3c-mci
70: 26 s3c-uart0 s3c2440-uart
71: 128 s3c-uart0 s3c2440-uart
79: 0 s3c-adc s3c2410_ts_pen
80: 0 s3c-adc s3c24xx-adc
83: 0 - s3c2410-wdt
Err: 0
après le blocage, la commande date renvoie toujours la même information.
Avez-vous une piste?
@+
AleaJactaEst
Romain Naour
Sep 29, 2012, 11:16:02 AM9/29/12
to concours-li...@googlegroups.com
Bonjour,
J'ai été confronté récemment à ce problème pour le kernel 3.2.21.
Apparemment le problème du timer est dû à un rechargement avec un événement ayant une échéance inférieure au temps de chargement du timer 4 (clockevent).
En imposant un "min_delay_ticks" cela règle le problème.
Pour l'instant c'est une valeur expérimentale, j'ai utilisé la même valeur que pour un processeur iMX.
Il y a un autre bug depuis la version 3.0.36 avec Adeos.
Lorsque l'on affiche beaucoup de caractères sur la console de debug, celle-ci ce bloque.
Il y a apparemment un problème de démasquage de la ligne d'interruption TX (IRQ 71)
Vous semblez utiliser la console de debug, avez vous eu ce problème ?
Sur ma carte la console se bloquait en faisant par exemple dmesg....
Bon test
Romain Naour
J'ai été confronté récemment à ce problème pour le kernel 3.2.21.
Apparemment le problème du timer est dû à un rechargement avec un événement ayant une échéance inférieure au temps de chargement du timer 4 (clockevent).
En imposant un "min_delay_ticks" cela règle le problème.
Pour l'instant c'est une valeur expérimentale, j'ai utilisé la même valeur que pour un processeur iMX.
Il y a un autre bug depuis la version 3.0.36 avec Adeos.
Lorsque l'on affiche beaucoup de caractères sur la console de debug, celle-ci ce bloque.
Il y a apparemment un problème de démasquage de la ligne d'interruption TX (IRQ 71)
Vous semblez utiliser la console de debug, avez vous eu ce problème ?
Sur ma carte la console se bloquait en faisant par exemple dmesg....
Bon test
Romain Naour
2012/9/29 AleaJactaEst <jean.so...@laposte.net>
AleaJactaEst
Sep 29, 2012, 11:29:07 AM9/29/12
to concours-li...@googlegroups.com
Bonjour,
J'ai eu effectivement un blocage sur la console (sur des commandes comme "dmesg", "ls /proc").
Pour contourner le problème, j'ai démarré le démon ssh.
Je vais tester avec tes deux patch.
Merci.
AleaJactaEst
J'ai eu effectivement un blocage sur la console (sur des commandes comme "dmesg", "ls /proc").
Pour contourner le problème, j'ai démarré le démon ssh.
Je vais tester avec tes deux patch.
Merci.
AleaJactaEst
Romain Naour
Oct 4, 2012, 4:03:00 PM10/4/12
to concours-li...@googlegroups.com
Avez vous pu tester avec les patch ?
Romain
AleaJactaEst
Oct 4, 2012, 4:11:29 PM10/4/12
to concours-li...@googlegroups.com
Bonjour,
Oui, il marche.
J'arrive à faire fonctionner correctement latency.
Par contre, je ne dois pas descendre la période à moins de 500µs (latency -p 500), sinon je me retrouve fasse à un blocage.
J'ai essayé de diminuer la latence pour me retrouver en dessous de 100µs, mais sans succès.
--------------------------------------------------------------------
# latency
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 164.031| 224.121| 309.929| 0| 0| 164.031| 309.929
RTD| 129.897| 214.995| 307.559| 0| 0| 129.897| 309.929
RTD| 133.571| 217.484| 308.862| 0| 0| 129.897| 309.929
RTD| 121.364| 219.380| 324.981| 0| 0| 121.364| 324.981
RTD| 166.401| 224.713| 306.255| 0| 0| 121.364| 324.981
RTD| 171.972| 225.780| 307.440| 0| 0| 121.364| 324.981
RTD| 171.853| 225.069| 308.744| 0| 0| 121.364| 324.981
RTD| 161.305| 222.817| 312.774| 0| 0| 121.364| 324.981
RTD| 161.542| 223.291| 341.811| 0| 0| 121.364| 341.811
RTD| 161.187| 222.698| 310.285| 0| 0| 121.364| 341.811
--------------------------------------------------------------------
Encore, merci.
@+
AleaJactaEst
Oui, il marche.
J'arrive à faire fonctionner correctement latency.
Par contre, je ne dois pas descendre la période à moins de 500µs (latency -p 500), sinon je me retrouve fasse à un blocage.
J'ai essayé de diminuer la latence pour me retrouver en dessous de 100µs, mais sans succès.
--------------------------------------------------------------------
# latency
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
[ 325.530000] Xenomai: registered exported object dispsem-786 (semaphores)== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 164.031| 224.121| 309.929| 0| 0| 164.031| 309.929
RTD| 129.897| 214.995| 307.559| 0| 0| 129.897| 309.929
RTD| 133.571| 217.484| 308.862| 0| 0| 129.897| 309.929
RTD| 121.364| 219.380| 324.981| 0| 0| 121.364| 324.981
RTD| 166.401| 224.713| 306.255| 0| 0| 121.364| 324.981
RTD| 171.972| 225.780| 307.440| 0| 0| 121.364| 324.981
RTD| 171.853| 225.069| 308.744| 0| 0| 121.364| 324.981
RTD| 161.305| 222.817| 312.774| 0| 0| 121.364| 324.981
RTD| 161.542| 223.291| 341.811| 0| 0| 121.364| 341.811
RTD| 161.187| 222.698| 310.285| 0| 0| 121.364| 341.811
--------------------------------------------------------------------
Encore, merci.
@+
AleaJactaEst
Romain Naour
Oct 4, 2012, 7:57:56 PM10/4/12
to concours-li...@googlegroups.com
Avez vous fait les modifications nécessaires dans la configuration du kernel lors de l'activation de Xenomai ? (désactivation du power management...)
La latence max est élevée par rapport aux résultats que j'obtiens (et je n'ai pas de warning de Xenomai ;-) )
Il n'y a rien qui tourne en parallèle du test ?
La connexion ssh induit une latence max plus élevée, au début du test je suis en console de debug:
# latency -p200
== Sampling period: 200 us
== Sampling period: 200 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 200 us period, priority 99)
RTT| 00:00:01 (periodic user-mode task, 200 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| -12.682| -3.912| 48.000| 0| 0| -12.682| 48.000
RTD| -13.512| -3.675| 67.911| 0| 0| -13.512| 67.911
RTD| -13.630| -3.319| 67.556| 0| 0| -13.630| 67.911
RTD| -13.156| -3.201| 63.882| 0| 0| -13.630| 67.911
RTD| -13.512| -3.201| 62.578| 0| 0| -13.630| 67.911
avec dd if=/dev/zero of=/dev/null + la connexion ssh active
RTD| -12.919| 0.829| 128.357| 0| 0| -13.749| 128.357
RTD| 5.214| 23.348| 123.497| 0| 0| -13.749| 128.357
RTD| 7.229| 22.044| 115.675| 0| 0| -13.749| 128.357
RTD| 7.111| 21.689| 81.067| 0| 0| -13.749| 128.357
RTD| 7.229| 22.992| 84.741| 0| 0| -13.749| 128.357
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| -13.749| 10.311| 128.357| 0| 0| 00:01:42/00:01:42
RTD| -13.512| -3.675| 67.911| 0| 0| -13.512| 67.911
RTD| -13.630| -3.319| 67.556| 0| 0| -13.630| 67.911
RTD| -13.156| -3.201| 63.882| 0| 0| -13.630| 67.911
RTD| -13.512| -3.201| 62.578| 0| 0| -13.630| 67.911
avec dd if=/dev/zero of=/dev/null + la connexion ssh active
RTD| -12.919| 0.829| 128.357| 0| 0| -13.749| 128.357
RTD| 5.214| 23.348| 123.497| 0| 0| -13.749| 128.357
RTD| 7.229| 22.044| 115.675| 0| 0| -13.749| 128.357
RTD| 7.111| 21.689| 81.067| 0| 0| -13.749| 128.357
RTD| 7.229| 22.992| 84.741| 0| 0| -13.749| 128.357
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| -13.749| 10.311| 128.357| 0| 0| 00:01:42/00:01:42
Pour vous aider, je vous conseille le blog de Christophe Blaess : http://www.blaess.fr/christophe/2012/08/27/xenomai-sur-raspberry-pi/
Par contre je n'avais pas encore ajusté "l'anticipation sur les latences minimale":
cat /proc/xenomai/latency
9481
après un rapide test:
echo -4386 > /proc/xenomai/latency
# latency -p 200 -T 14400
== Sampling period: 200 us
== Test mode: periodic user-mode task
== All results in microseconds
RTT| 00:00:01 (periodic user-mode task, 200 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.118| 10.192| 82.015| 0| 0| 0.118| 82.015
RTD| 0.711| 10.548| 77.393| 0| 0| 0.118| 82.015
RTD| 0.355| 10.548| 77.156| 0| 0| 0.118| 82.015
...
avec dd if=/dev/zero of=/dev/null + la connexion ssh active
RTD| 20.622| 35.437| 95.764| 0| 0| 0.000| 137.364
RTD| 19.200| 35.437| 91.615| 0| 0| 0.000| 137.364
RTD| 19.200| 34.963| 125.275| 0| 0| 0.000| 137.364
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 0.000| 22.518| 137.364| 0| 0| 00:00:34/04:00:00
Ce qui est mieux :)
A+
Romain
AleaJactaEst
Oct 5, 2012, 5:34:36 PM10/5/12
to concours-li...@googlegroups.com
Bonjour,
Je vais regarder.
@+
AleaJactaEst
Je vais regarder.
@+
AleaJactaEst
Romain Naour
Oct 9, 2012, 8:02:45 PM10/9/12
to concours-li...@googlegroups.com
Bonjour,
Je me suis trompé dans mon message précédent, si on fait :
# cat /proc/xenomai/latency
on obtient : 509039189470
C'est donc une erreur de faire :
echo -4386 > /proc/xenomai/latency
Reprenons:
# echo 0 > /proc/xenomai/latency
# latency
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.200| 14.340| 55.822| 0| 0| 3.200| 55.822
RTD| 3.200| 14.459| 74.549| 0| 0| 3.200| 74.549
RTD| 3.200| 13.274| 78.815| 0| 0| 3.200| 78.815
RTD| 3.200| 12.681| 91.615| 0| 0| 3.200| 91.615
RTD| 3.200| 12.681| 68.741| 0| 0| 3.200| 91.615
RTD| 3.200| 12.444| 75.260| 0| 0| 3.200| 91.615
RTD| 3.200| 12.563| 74.430| 0| 0| 3.200| 91.615
RTD| 3.200| 12.800| 71.230| 0| 0| 3.200| 91.615
RTD| 3.200| 12.681| 78.578| 0| 0| 3.200| 91.615
RTD| -4.267| 13.037| 77.512| 0| 0| -4.267| 91.615 <<
RTD| 3.200| 12.563| 80.593| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 68.741| 0| 0| -4.267| 91.615
RTD| 3.200| 13.511| 72.889| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 74.311| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 84.623| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 73.008| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 77.156| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 78.341| 0| 0| -4.267| 91.615
RTD| 3.200| 14.340| 63.289| 0| 0| -4.267| 91.615
RTD| 3.200| 13.866| 77.037| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 80.949| 0| 0| -4.267| 91.615
RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.200| 14.340| 77.512| 0| 0| -4.267| 91.615
RTD| 3.200| 13.985| 79.289| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 82.489| 0| 0| -4.267| 91.615
RTD| 3.200| 14.340| 67.911| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 78.223| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 79.289| 0| 0| -4.267| 91.615
RTD| 3.200| 14.340| 78.697| 0| 0| -4.267| 91.615
RTD| 3.200| 14.340| 77.037| 0| 0| -4.267| 91.615
RTD| 3.200| 13.866| 74.904| 0| 0| -4.267| 91.615
RTD| -4.623| 11.614| 68.385| 0| 0| -4.623| 91.615 <<
RTD| 1.422| 14.459| 73.008| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 76.563| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 64.948| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 75.734| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 80.119| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 80.119| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 80.356| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 76.800| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 82.371| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 75.378| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 81.897| 0| 0| -4.623| 91.615
RTT| 00:00:43 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.200| 14.340| 78.341| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 80.712| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 74.074| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 74.786| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 75.260| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 83.675| 0| 0| -4.623| 91.615
RTD| 3.200| 14.577| 79.882| 0| 0| -4.623| 91.615
RTD| 3.200| 14.222| 75.971| 0| 0| -4.623| 91.615
RTD| 3.200| 13.866| 75.971| 0| 0| -4.623| 91.615
RTD| -4.267| 14.222| 78.104| 0| 0| -4.623| 91.615 <<
RTD| -2.845| 14.577| 82.252| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 88.889| 0| 0| -4.623| 91.615
Je n'explique pas pourquoi on a, périodiquement, la routine de traitement qui se déclenche plutôt !?
Si on veut prendre la latence min de 3,200µs, il faut faire attention:
# echo 3200 > /proc/xenomai/latency
# cat /proc/xenomai/latency
3081
# echo 3300 > /proc/xenomai/latency
# cat /proc/xenomai/latency
3200
On arrive à faire l'ajustement que l'on voulait obtenir mais on a toujours ce problème...
# latency
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
RTD| 0.000| 11.259| 77.037| 0| 0| 0.000| 77.037
RTD| 0.000| 9.481| 63.882| 0| 0| 0.000| 77.037
RTD| 0.000| 10.074| 72.652| 0| 0| 0.000| 77.037
RTD| 0.000| 9.126| 68.504| 0| 0| 0.000| 77.037
RTD| 0.000| 10.429| 75.971| 0| 0| 0.000| 77.037
RTD| -7.349| 8.651| 66.726| 0| 0| -7.349| 77.037 <<
RTD| 0.000| 9.955| 76.682| 0| 0| -7.349| 77.037
RTD| 0.000| 9.007| 66.726| 0| 0| -7.349| 77.037
RTD| 0.000| 10.548| 67.437| 0| 0| -7.349| 77.037
RTD| 0.000| 11.140| 72.889| 0| 0| -7.349| 77.037
RTD| 0.000| 11.140| 78.934| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 76.208| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 78.223| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 67.674| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 71.111| 0| 0| -7.349| 78.934
RTD| 0.000| 11.259| 75.260| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 66.134| 0| 0| -7.349| 78.934
RTD| 0.000| 11.259| 77.512| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 82.015| 0| 0| -7.349| 82.015
RTD| 0.000| 11.259| 75.141| 0| 0| -7.349| 82.015
RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.000| 11.140| 64.000| 0| 0| -7.349| 82.015
RTD| 0.000| 10.311| 75.023| 0| 0| -7.349| 82.015
RTD| 0.000| 11.140| 77.630| 0| 0| -7.349| 82.015
RTD| 0.000| 11.259| 69.926| 0| 0| -7.349| 82.015
RTD| 0.000| 11.140| 66.015| 0| 0| -7.349| 82.015
RTD| 0.000| 10.192| 66.252| 0| 0| -7.349| 82.015
RTD| -7.467| 11.140| 76.326| 0| 0| -7.467| 82.015 <<
RTD| 0.000| 11.140| 74.786| 0| 0| -7.467| 82.015
RTD| 0.000| 10.785| 69.215| 0| 0| -7.467| 82.015
RTD| 0.000| 11.140| 76.445| 0| 0| -7.467| 82.015
Curieusement le problème arrive plus régulièrement en réduisant la période de latency...
# latency -p500
== Sampling period: 500 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 500 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| -6.875| 5.096| 55.111| 0| 0| -6.875| 55.111 <<
RTD| 0.000| 5.451| 66.845| 0| 0| -6.875| 66.845
RTD| 0.000| 5.214| 75.615| 0| 0| -6.875| 75.615
RTD| -6.638| 5.214| 67.911| 0| 0| -6.875| 75.615 <<
RTD| 0.000| 5.214| 70.400| 0| 0| -6.875| 75.615
RTD| 0.000| 4.622| 66.489| 0| 0| -6.875| 75.615
RTD| -7.112| 4.859| 72.297| 0| 0| -7.112| 75.615 <<
RTD| 0.000| 4.622| 74.193| 0| 0| -7.112| 75.615
RTD| 0.000| 5.688| 73.600| 0| 0| -7.112| 75.615
RTD| -6.638| 5.214| 59.852| 0| 0| -7.112| 75.615 <<
Jusqu'à l'avoir tout le temps...
# latency -p100
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| -7.704| 0.948| 54.045| 0| 0| -7.704| 54.045
RTD| -7.467| 1.303| 61.274| 0| 0| -7.704| 61.274
RTD| -6.875| 1.422| 57.245| 0| 0| -7.704| 61.274
RTD| -6.993| 1.422| 62.104| 0| 0| -7.704| 62.104
RTD| -7.349| 1.422| 66.252| 0| 0| -7.704| 66.252
RTD| -7.230| 1.422| 62.815| 0| 0| -7.704| 66.252
Je vais continuer les tests pour savoir d'où viennent ces 4.623µs...
En ce qui concerne le patch sur le itimer, j'ai déterminé la valeur minimale du rechargement du timer matériel:
Valeurs testées:
100 -
110 -
115 -
120 ok
125 ok
150 ok
250 ok
500 ok
1000 ok
2000 ok
+ s3c2410_itimer.min_delay_ticks = ipipe_timer_ns2ticks(&s3c2410_itimer, 120);
Pour diminuer la latence, il faut désactiver les options de debug et de statistiques dans le kernel:
CONFIG_XENO_OPT_STATS
CONFIG_XENO_OPT_DEBUG
IPIPE_DEBUG
CONFIG_FTRACE
...
J'espère que cela vous aide,
A bientôt
Romain
Je me suis trompé dans mon message précédent, si on fait :
# cat /proc/xenomai/latency
on obtient : 509039189470
C'est donc une erreur de faire :
echo -4386 > /proc/xenomai/latency
Reprenons:
# echo 0 > /proc/xenomai/latency
# latency
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.200| 14.459| 74.549| 0| 0| 3.200| 74.549
RTD| 3.200| 13.274| 78.815| 0| 0| 3.200| 78.815
RTD| 3.200| 12.681| 91.615| 0| 0| 3.200| 91.615
RTD| 3.200| 12.681| 68.741| 0| 0| 3.200| 91.615
RTD| 3.200| 12.444| 75.260| 0| 0| 3.200| 91.615
RTD| 3.200| 12.563| 74.430| 0| 0| 3.200| 91.615
RTD| 3.200| 12.800| 71.230| 0| 0| 3.200| 91.615
RTD| 3.200| 12.681| 78.578| 0| 0| 3.200| 91.615
RTD| -4.267| 13.037| 77.512| 0| 0| -4.267| 91.615 <<
RTD| 3.200| 12.563| 80.593| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 68.741| 0| 0| -4.267| 91.615
RTD| 3.200| 13.511| 72.889| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 74.311| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 84.623| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 73.008| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 77.156| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 78.341| 0| 0| -4.267| 91.615
RTD| 3.200| 14.340| 63.289| 0| 0| -4.267| 91.615
RTD| 3.200| 13.866| 77.037| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 80.949| 0| 0| -4.267| 91.615
RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.200| 13.985| 79.289| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 82.489| 0| 0| -4.267| 91.615
RTD| 3.200| 14.340| 67.911| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 78.223| 0| 0| -4.267| 91.615
RTD| 3.200| 14.459| 79.289| 0| 0| -4.267| 91.615
RTD| 3.200| 14.340| 78.697| 0| 0| -4.267| 91.615
RTD| 3.200| 14.340| 77.037| 0| 0| -4.267| 91.615
RTD| 3.200| 13.866| 74.904| 0| 0| -4.267| 91.615
RTD| -4.623| 11.614| 68.385| 0| 0| -4.623| 91.615 <<
RTD| 1.422| 14.459| 73.008| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 76.563| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 64.948| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 75.734| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 80.119| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 80.119| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 80.356| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 76.800| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 82.371| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 75.378| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 81.897| 0| 0| -4.623| 91.615
RTT| 00:00:43 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.200| 14.459| 80.712| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 74.074| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 74.786| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 75.260| 0| 0| -4.623| 91.615
RTD| 3.200| 14.340| 83.675| 0| 0| -4.623| 91.615
RTD| 3.200| 14.577| 79.882| 0| 0| -4.623| 91.615
RTD| 3.200| 14.222| 75.971| 0| 0| -4.623| 91.615
RTD| 3.200| 13.866| 75.971| 0| 0| -4.623| 91.615
RTD| -4.267| 14.222| 78.104| 0| 0| -4.623| 91.615 <<
RTD| -2.845| 14.577| 82.252| 0| 0| -4.623| 91.615
RTD| 3.200| 14.459| 88.889| 0| 0| -4.623| 91.615
Je n'explique pas pourquoi on a, périodiquement, la routine de traitement qui se déclenche plutôt !?
Si on veut prendre la latence min de 3,200µs, il faut faire attention:
# echo 3200 > /proc/xenomai/latency
# cat /proc/xenomai/latency
3081
# echo 3300 > /proc/xenomai/latency
# cat /proc/xenomai/latency
3200
On arrive à faire l'ajustement que l'on voulait obtenir mais on a toujours ce problème...
# latency
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.000| 10.903| 51.793| 0| 0| 0.000| 51.793RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.000| 11.259| 77.037| 0| 0| 0.000| 77.037
RTD| 0.000| 9.481| 63.882| 0| 0| 0.000| 77.037
RTD| 0.000| 10.074| 72.652| 0| 0| 0.000| 77.037
RTD| 0.000| 9.126| 68.504| 0| 0| 0.000| 77.037
RTD| 0.000| 10.429| 75.971| 0| 0| 0.000| 77.037
RTD| -7.349| 8.651| 66.726| 0| 0| -7.349| 77.037 <<
RTD| 0.000| 9.955| 76.682| 0| 0| -7.349| 77.037
RTD| 0.000| 9.007| 66.726| 0| 0| -7.349| 77.037
RTD| 0.000| 10.548| 67.437| 0| 0| -7.349| 77.037
RTD| 0.000| 11.140| 72.889| 0| 0| -7.349| 77.037
RTD| 0.000| 11.140| 78.934| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 76.208| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 78.223| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 67.674| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 71.111| 0| 0| -7.349| 78.934
RTD| 0.000| 11.259| 75.260| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 66.134| 0| 0| -7.349| 78.934
RTD| 0.000| 11.259| 77.512| 0| 0| -7.349| 78.934
RTD| 0.000| 11.140| 82.015| 0| 0| -7.349| 82.015
RTD| 0.000| 11.259| 75.141| 0| 0| -7.349| 82.015
RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.000| 10.311| 75.023| 0| 0| -7.349| 82.015
RTD| 0.000| 11.140| 77.630| 0| 0| -7.349| 82.015
RTD| 0.000| 11.259| 69.926| 0| 0| -7.349| 82.015
RTD| 0.000| 11.140| 66.015| 0| 0| -7.349| 82.015
RTD| 0.000| 10.192| 66.252| 0| 0| -7.349| 82.015
RTD| -7.467| 11.140| 76.326| 0| 0| -7.467| 82.015 <<
RTD| 0.000| 11.140| 74.786| 0| 0| -7.467| 82.015
RTD| 0.000| 10.785| 69.215| 0| 0| -7.467| 82.015
RTD| 0.000| 11.140| 76.445| 0| 0| -7.467| 82.015
Curieusement le problème arrive plus régulièrement en réduisant la période de latency...
# latency -p500
== Sampling period: 500 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.000| 5.451| 66.845| 0| 0| -6.875| 66.845
RTD| 0.000| 5.214| 75.615| 0| 0| -6.875| 75.615
RTD| -6.638| 5.214| 67.911| 0| 0| -6.875| 75.615 <<
RTD| 0.000| 5.214| 70.400| 0| 0| -6.875| 75.615
RTD| 0.000| 4.622| 66.489| 0| 0| -6.875| 75.615
RTD| -7.112| 4.859| 72.297| 0| 0| -7.112| 75.615 <<
RTD| 0.000| 4.622| 74.193| 0| 0| -7.112| 75.615
RTD| 0.000| 5.688| 73.600| 0| 0| -7.112| 75.615
RTD| -6.638| 5.214| 59.852| 0| 0| -7.112| 75.615 <<
Jusqu'à l'avoir tout le temps...
# latency -p100
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| -7.467| 1.303| 61.274| 0| 0| -7.704| 61.274
RTD| -6.875| 1.422| 57.245| 0| 0| -7.704| 61.274
RTD| -6.993| 1.422| 62.104| 0| 0| -7.704| 62.104
RTD| -7.349| 1.422| 66.252| 0| 0| -7.704| 66.252
RTD| -7.230| 1.422| 62.815| 0| 0| -7.704| 66.252
Je vais continuer les tests pour savoir d'où viennent ces 4.623µs...
En ce qui concerne le patch sur le itimer, j'ai déterminé la valeur minimale du rechargement du timer matériel:
Valeurs testées:
100 -
110 -
115 -
120 ok
125 ok
150 ok
250 ok
500 ok
1000 ok
2000 ok
+ s3c2410_itimer.min_delay_ticks = ipipe_timer_ns2ticks(&s3c2410_itimer, 120);
Pour diminuer la latence, il faut désactiver les options de debug et de statistiques dans le kernel:
CONFIG_XENO_OPT_STATS
CONFIG_XENO_OPT_DEBUG
IPIPE_DEBUG
CONFIG_FTRACE
...
J'espère que cela vous aide,
A bientôt
Romain
Message has been deleted
AleaJactaEst
Oct 11, 2012, 3:36:00 PM10/11/12
to concours-li...@googlegroups.com
Bonjour,
Je viens de faire les tests sans les options de débogage du kernel.
Et les résultats sont mieux.
# echo 0 > /proc/xenomai/latency
# latency -p100
RTD| -2.015| 13.985| 92.919| 21| 0| -93.631| 193.068
RTD| -1.186| 13.985| 95.408| 21| 0| -93.631| 193.068
RTD| -1.541| 14.103| 111.053| 21| 0| -93.631| 193.068
RTD| -2.015| 14.222| 184.417| 22| 0| -93.631| 193.068
RTT| 00:01:04 (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| -2.134| 14.340| 175.053| 24| 0| -93.631| 193.068
RTD| 0.000| 13.866| 95.052| 24| 0| -93.631| 193.068
RTD| 0.237| 13.985| 114.608| 24| 0| -93.631| 193.068
RTD| -0.119| 14.103| 96.593| 24| 0| -93.631| 193.068
RTD| -0.593| 14.222| 182.520| 27| 0| -93.631| 193.068
RTD| -1.778| 13.985| 89.008| 27| 0| -93.631| 193.068
RTD| -1.778| 13.985| 88.534| 27| 0| -93.631| 193.068
RTD| -1.304| 13.985| 91.260| 27| 0| -93.631| 193.068
RTD| -1.423| 13.985| 89.838| 27| 0| -93.631| 193.068
RTD| -1.778| 15.170| 194.135| 34| 0| -93.631| 194.135
RTD| -1.541| 13.866| 89.601| 34| 0| -93.631| 194.135
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| -93.631| 13.155| 194.135| 34| 0| 00:01:15/00:01:15
par contre overrun augmente.
avec un autre test
# latency -p200
RTD| -2.015| 15.052| 109.630| 0| 0| -2.134| 147.201
RTD| 3.911| 15.052| 107.260| 0| 0| -2.134| 147.201
RTD| -1.541| 15.052| 115.675| 0| 0| -2.134| 147.201
RTD| 3.911| 15.052| 111.882| 0| 0| -2.134| 147.201
RTD| 3.911| 15.052| 111.408| 0| 0| -2.134| 147.201
RTD| -0.593| 15.052| 117.808| 0| 0| -2.134| 147.201
RTD| 3.911| 15.170| 118.519| 0| 0| -2.134| 147.201
RTD| -1.778| 15.052| 125.275| 0| 0| -2.134| 147.201
RTT| 00:02:07 (periodic user-mode task, 200 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.911| 15.052| 111.882| 0| 0| -2.134| 147.201
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| -2.134| 15.170| 147.201| 0| 0| 00:02:08/00:02:08
Avec un parametre "/proc/xenomai/latency" à 0, j'ai toujours un "lat best" négatif.
Les résultats que tu as envoyé sont-il aussi sur une mini2440.
(si oui avec la frequence de base 400MHz ou 500Mhz)
@+
AleaJactaEst
Je viens de faire les tests sans les options de débogage du kernel.
Et les résultats sont mieux.
# echo 0 > /proc/xenomai/latency
# latency -p100
RTD| -2.015| 13.985| 92.919| 21| 0| -93.631| 193.068
RTD| -1.186| 13.985| 95.408| 21| 0| -93.631| 193.068
RTD| -1.541| 14.103| 111.053| 21| 0| -93.631| 193.068
RTD| -2.015| 14.222| 184.417| 22| 0| -93.631| 193.068
RTT| 00:01:04 (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.000| 13.866| 95.052| 24| 0| -93.631| 193.068
RTD| 0.237| 13.985| 114.608| 24| 0| -93.631| 193.068
RTD| -0.119| 14.103| 96.593| 24| 0| -93.631| 193.068
RTD| -0.593| 14.222| 182.520| 27| 0| -93.631| 193.068
RTD| -1.778| 13.985| 89.008| 27| 0| -93.631| 193.068
RTD| -1.778| 13.985| 88.534| 27| 0| -93.631| 193.068
RTD| -1.304| 13.985| 91.260| 27| 0| -93.631| 193.068
RTD| -1.423| 13.985| 89.838| 27| 0| -93.631| 193.068
RTD| -1.778| 15.170| 194.135| 34| 0| -93.631| 194.135
RTD| -1.541| 13.866| 89.601| 34| 0| -93.631| 194.135
---|-----------|-----------|-----------|--------|------|-------------------------
par contre overrun augmente.
avec un autre test
# latency -p200
RTD| -2.015| 15.052| 109.630| 0| 0| -2.134| 147.201
RTD| 3.911| 15.052| 107.260| 0| 0| -2.134| 147.201
RTD| -1.541| 15.052| 115.675| 0| 0| -2.134| 147.201
RTD| 3.911| 15.052| 111.882| 0| 0| -2.134| 147.201
RTD| 3.911| 15.052| 111.408| 0| 0| -2.134| 147.201
RTD| -0.593| 15.052| 117.808| 0| 0| -2.134| 147.201
RTD| 3.911| 15.170| 118.519| 0| 0| -2.134| 147.201
RTD| -1.778| 15.052| 125.275| 0| 0| -2.134| 147.201
RTT| 00:02:07 (periodic user-mode task, 200 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
---|-----------|-----------|-----------|--------|------|-------------------------
Avec un parametre "/proc/xenomai/latency" à 0, j'ai toujours un "lat best" négatif.
Les résultats que tu as envoyé sont-il aussi sur une mini2440.
(si oui avec la frequence de base 400MHz ou 500Mhz)
@+
AleaJactaEst
Romain Naour
Oct 22, 2012, 5:34:20 PM10/22/12
to concours-li...@googlegroups.com
Bonjour Jean,
J'ai eu pas mal d'aide sur la liste de Xenomai.
Pour le bug de l'UART, le patch que je t'ai envoyé au début n'est pas satisfaisant.
Voici le patch avec la bonne manière de faire ;-)
A+
Romain
J'ai eu pas mal d'aide sur la liste de Xenomai.
Pour le bug de l'UART, le patch que je t'ai envoyé au début n'est pas satisfaisant.
Voici le patch avec la bonne manière de faire ;-)
A+
Romain
AleaJactaEst
Oct 24, 2012, 3:44:45 PM10/24/12
to concours-li...@googlegroups.com
Bonjour,
Merci pour ton aide.
Je vais tester ton patch.
@+
AleaJactaEst
Merci pour ton aide.
Je vais tester ton patch.
@+
AleaJactaEst
AleaJactaEst
Oct 24, 2012, 5:15:55 PM10/24/12
to concours-li...@googlegroups.com
Bonjour,
Après quelque test, je me retrouve toujours avec un plantage du kernel.
[ 472.815000] Unable to handle kernel NULL pointer dereference at virtual address 0000001c
[ 472.815000] fcse pid: 0, 0x00000000
[ 472.820000] pgd = c3bf0000
[ 472.820000] [0000001c] *pgd=33ba5831, *pte=00000000, *ppte=00000000
[ 472.830000] Internal error: Oops: 17 [#1] PREEMPT
[ 472.830000] Modules linked in: xeno_s3c2440_adc [last unloaded: xeno_s3c2440_adc]
[ 472.830000] CPU: 0 Tainted: G W (3.2.21 #25)
[ 472.830000] PC is at pick_next_task_fair+0x30/0x98
[ 472.830000] LR is at pick_next_entity+0x88/0xc8
[ 472.830000] pc : [<c001aba0>] lr : [<c001ab30>] psr: a0000013
[ 472.830000] sp : c3011ed0 ip : c3011eb0 fp : c3011eec
[ 472.830000] r10: c3877668 r9 : c0615d5c r8 : c0610030
[ 472.830000] r7 : 00000000 r6 : c0610068 r5 : c3877500 r4 : c0610030
[ 472.830000] r3 : c3877530 r2 : 00000002 r1 : 00000000 r0 : 00000000
[ 472.830000] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 472.830000] Control: c000717f Table: 33bf0000 DAC: 00000015
[ 472.830000] Process oscilloscope_al (pid: 820, stack limit = 0xc3010270)
[ 472.830000] Stack: (0xc3011ed0 to 0xc3012000)
[ 472.830000] 1ec0: c0487750 c3877500 c3010000 00000000
[ 472.830000] 1ee0: c3011f84 c3011ef0 c0483a90 c001ab80 c3011f88 00000001 0000c350 00000000
[ 472.830000] 1f00: c3011f84 c3011f10 c004b008 c04851dc 00000000 00000000 0000c350 c001ccec
[ 472.830000] 1f20: c3011f20 00000000 00000000 0000006e c3011f54 c3011f40 c004c904 c004c894
[ 472.830000] 1f40: 00000000 c0610030 c3011f74 c3877530 c0610030 c3877500 0000009e 0002e38c
[ 472.830000] 1f60: 0002d748 00000000 0000009e c0009708 c3010000 00800000 c3011f94 c3011f88
[ 472.830000] 1f80: c04841b4 c0483598 c3011fa4 c3011f98 c001f034 c048416c 00000000 c3011fa8
[ 472.830000] 1fa0: c0009480 c001efdc 0002e38c 0002d748 00000000 00000080 00000001 00000000
[ 472.830000] 1fc0: 0002e38c 0002d748 00000000 0000009e 00000009 0002d748 00000274 407d84cc
[ 472.830000] 1fe0: 0002d284 018f59f8 0000edc8 00cb19fc 80000010 00000000 00000000 00000000
[ 472.830000] [<c001aba0>] (pick_next_task_fair+0x30/0x98) from [<c0483a90>] (__schedule+0x508/0x6c4)
[ 472.830000] [<c0483a90>] (__schedule+0x508/0x6c4) from [<c04841b4>] (schedule+0x58/0x70)
[ 472.830000] [<c04841b4>] (schedule+0x58/0x70) from [<c001f034>] (sys_sched_yield+0x68/0x78)
[ 472.830000] [<c001f034>] (sys_sched_yield+0x68/0x78) from [<c0009480>] (ret_fast_syscall+0x0/0x2c)
[ 472.830000] Code: 089da8f0 e2846038 e1a00006 ebffffc1 (e590301c)
[ 472.835000] ---[ end trace 9eb6968fbbc08432 ]---
[ 472.835000] note: oscilloscope_al[820] exited with preempt_count 2
[ 472.840000] BUG: scheduling while atomic: oscilloscope_al/820/0x40000003
[ 472.845000] Modules linked in: xeno_s3c2440_adc [last unloaded: xeno_s3c2440_adc]
[ 472.850000] [<c000ea0c>] (unwind_backtrace+0x0/0xfc) from [<c0483178>] (dump_stack+0x20/0x24)
[ 472.855000] [<c0483178>] (dump_stack+0x20/0x24) from [<c001a3ac>] (__schedule_bug+0x58/0x64)
[ 472.860000] [<c001a3ac>] (__schedule_bug+0x58/0x64) from [<c0483ba4>] (__schedule+0x61c/0x6c4)
[ 472.865000] [<c0483ba4>] (__schedule+0x61c/0x6c4) from [<c001c400>] (__cond_resched+0x20/0x2c)
[ 472.870000] [<c001c400>] (__cond_resched+0x20/0x2c) from [<c0484414>] (_cond_resched+0x40/0x50)
[ 472.875000] [<c0484414>] (_cond_resched+0x40/0x50) from [<c01a0664>] (__get_user_pages+0xd8/0x354)
[ 472.880000] [<c01a0664>] (__get_user_pages+0xd8/0x354) from [<c01a0a34>] (get_user_pages+0x5c/0x64)
[ 472.885000] [<c01a0a34>] (get_user_pages+0x5c/0x64) from [<c0196ce4>] (get_user_pages_fast+0x70/0x88)
[ 472.890000] [<c0196ce4>] (get_user_pages_fast+0x70/0x88) from [<c00556c0>] (get_futex_key+0xe8/0x278)
[ 472.895000] [<c00556c0>] (get_futex_key+0xe8/0x278) from [<c0055f78>] (futex_wake+0x5c/0x158)
[ 472.900000] [<c0055f78>] (futex_wake+0x5c/0x158) from [<c0058200>] (do_futex+0x124/0x1e8)
[ 472.905000] [<c0058200>] (do_futex+0x124/0x1e8) from [<c0058354>] (sys_futex+0x90/0x190)
[ 472.910000] [<c0058354>] (sys_futex+0x90/0x190) from [<c00204a4>] (mm_release+0xa0/0xcc)
[ 472.915000] [<c00204a4>] (mm_release+0xa0/0xcc) from [<c0024578>] (exit_mm+0x28/0x13c)
[ 472.920000] [<c0024578>] (exit_mm+0x28/0x13c) from [<c0026758>] (do_exit+0xfc/0x324)
[ 472.925000] [<c0026758>] (do_exit+0xfc/0x324) from [<c000cf08>] (die+0xfc/0x13c)
[ 472.930000] [<c000cf08>] (die+0xfc/0x13c) from [<c0010ce4>] (__do_kernel_fault+0x74/0x94)
[ 472.935000] [<c0010ce4>] (__do_kernel_fault+0x74/0x94) from [<c0010e5c>] (do_page_fault+0x158/0x274)
[ 472.940000] [<c0010e5c>] (do_page_fault+0x158/0x274) from [<c0008428>] (do_DataAbort+0x50/0x108)
[ 472.945000] [<c0008428>] (do_DataAbort+0x50/0x108) from [<c0008f8c>] (__dabt_svc+0x2c/0x40)
[ 472.950000] Exception stack(0xc3011e88 to 0xc3011ed0)
[ 472.955000] 1e80: 00000000 00000000 00000002 c3877530 c0610030 c3877500
[ 472.960000] 1ea0: c0610068 00000000 c0610030 c0615d5c c3877668 c3011eec c3011eb0 c3011ed0
[ 472.965000] 1ec0: c001ab30 c001aba0 a0000013 ffffffff
[ 472.970000] [<c0008f8c>] (__dabt_svc+0x2c/0x40) from [<c001aba0>] (pick_next_task_fair+0x30/0x98)
[ 472.975000] [<c001aba0>] (pick_next_task_fair+0x30/0x98) from [<c0483a90>] (__schedule+0x508/0x6c4)
[ 472.980000] [<c0483a90>] (__schedule+0x508/0x6c4) from [<c04841b4>] (schedule+0x58/0x70)
[ 472.985000] [<c04841b4>] (schedule+0x58/0x70) from [<c001f034>] (sys_sched_yield+0x68/0x78)
[ 472.990000] [<c001f034>] (sys_sched_yield+0x68/0x78) from [<c0009480>] (ret_fast_syscall+0x0/0x2c)
Y'a t'il un moyen de générer un dump pour permettre une analyse?
@+
AleaJactaest
Après quelque test, je me retrouve toujours avec un plantage du kernel.
[ 472.815000] Unable to handle kernel NULL pointer dereference at virtual address 0000001c
[ 472.815000] fcse pid: 0, 0x00000000
[ 472.820000] pgd = c3bf0000
[ 472.820000] [0000001c] *pgd=33ba5831, *pte=00000000, *ppte=00000000
[ 472.830000] Internal error: Oops: 17 [#1] PREEMPT
[ 472.830000] Modules linked in: xeno_s3c2440_adc [last unloaded: xeno_s3c2440_adc]
[ 472.830000] CPU: 0 Tainted: G W (3.2.21 #25)
[ 472.830000] PC is at pick_next_task_fair+0x30/0x98
[ 472.830000] LR is at pick_next_entity+0x88/0xc8
[ 472.830000] pc : [<c001aba0>] lr : [<c001ab30>] psr: a0000013
[ 472.830000] sp : c3011ed0 ip : c3011eb0 fp : c3011eec
[ 472.830000] r10: c3877668 r9 : c0615d5c r8 : c0610030
[ 472.830000] r7 : 00000000 r6 : c0610068 r5 : c3877500 r4 : c0610030
[ 472.830000] r3 : c3877530 r2 : 00000002 r1 : 00000000 r0 : 00000000
[ 472.830000] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 472.830000] Control: c000717f Table: 33bf0000 DAC: 00000015
[ 472.830000] Process oscilloscope_al (pid: 820, stack limit = 0xc3010270)
[ 472.830000] Stack: (0xc3011ed0 to 0xc3012000)
[ 472.830000] 1ec0: c0487750 c3877500 c3010000 00000000
[ 472.830000] 1ee0: c3011f84 c3011ef0 c0483a90 c001ab80 c3011f88 00000001 0000c350 00000000
[ 472.830000] 1f00: c3011f84 c3011f10 c004b008 c04851dc 00000000 00000000 0000c350 c001ccec
[ 472.830000] 1f20: c3011f20 00000000 00000000 0000006e c3011f54 c3011f40 c004c904 c004c894
[ 472.830000] 1f40: 00000000 c0610030 c3011f74 c3877530 c0610030 c3877500 0000009e 0002e38c
[ 472.830000] 1f60: 0002d748 00000000 0000009e c0009708 c3010000 00800000 c3011f94 c3011f88
[ 472.830000] 1f80: c04841b4 c0483598 c3011fa4 c3011f98 c001f034 c048416c 00000000 c3011fa8
[ 472.830000] 1fa0: c0009480 c001efdc 0002e38c 0002d748 00000000 00000080 00000001 00000000
[ 472.830000] 1fc0: 0002e38c 0002d748 00000000 0000009e 00000009 0002d748 00000274 407d84cc
[ 472.830000] 1fe0: 0002d284 018f59f8 0000edc8 00cb19fc 80000010 00000000 00000000 00000000
[ 472.830000] [<c001aba0>] (pick_next_task_fair+0x30/0x98) from [<c0483a90>] (__schedule+0x508/0x6c4)
[ 472.830000] [<c0483a90>] (__schedule+0x508/0x6c4) from [<c04841b4>] (schedule+0x58/0x70)
[ 472.830000] [<c04841b4>] (schedule+0x58/0x70) from [<c001f034>] (sys_sched_yield+0x68/0x78)
[ 472.830000] [<c001f034>] (sys_sched_yield+0x68/0x78) from [<c0009480>] (ret_fast_syscall+0x0/0x2c)
[ 472.830000] Code: 089da8f0 e2846038 e1a00006 ebffffc1 (e590301c)
[ 472.835000] ---[ end trace 9eb6968fbbc08432 ]---
[ 472.835000] note: oscilloscope_al[820] exited with preempt_count 2
[ 472.840000] BUG: scheduling while atomic: oscilloscope_al/820/0x40000003
[ 472.845000] Modules linked in: xeno_s3c2440_adc [last unloaded: xeno_s3c2440_adc]
[ 472.850000] [<c000ea0c>] (unwind_backtrace+0x0/0xfc) from [<c0483178>] (dump_stack+0x20/0x24)
[ 472.855000] [<c0483178>] (dump_stack+0x20/0x24) from [<c001a3ac>] (__schedule_bug+0x58/0x64)
[ 472.860000] [<c001a3ac>] (__schedule_bug+0x58/0x64) from [<c0483ba4>] (__schedule+0x61c/0x6c4)
[ 472.865000] [<c0483ba4>] (__schedule+0x61c/0x6c4) from [<c001c400>] (__cond_resched+0x20/0x2c)
[ 472.870000] [<c001c400>] (__cond_resched+0x20/0x2c) from [<c0484414>] (_cond_resched+0x40/0x50)
[ 472.875000] [<c0484414>] (_cond_resched+0x40/0x50) from [<c01a0664>] (__get_user_pages+0xd8/0x354)
[ 472.880000] [<c01a0664>] (__get_user_pages+0xd8/0x354) from [<c01a0a34>] (get_user_pages+0x5c/0x64)
[ 472.885000] [<c01a0a34>] (get_user_pages+0x5c/0x64) from [<c0196ce4>] (get_user_pages_fast+0x70/0x88)
[ 472.890000] [<c0196ce4>] (get_user_pages_fast+0x70/0x88) from [<c00556c0>] (get_futex_key+0xe8/0x278)
[ 472.895000] [<c00556c0>] (get_futex_key+0xe8/0x278) from [<c0055f78>] (futex_wake+0x5c/0x158)
[ 472.900000] [<c0055f78>] (futex_wake+0x5c/0x158) from [<c0058200>] (do_futex+0x124/0x1e8)
[ 472.905000] [<c0058200>] (do_futex+0x124/0x1e8) from [<c0058354>] (sys_futex+0x90/0x190)
[ 472.910000] [<c0058354>] (sys_futex+0x90/0x190) from [<c00204a4>] (mm_release+0xa0/0xcc)
[ 472.915000] [<c00204a4>] (mm_release+0xa0/0xcc) from [<c0024578>] (exit_mm+0x28/0x13c)
[ 472.920000] [<c0024578>] (exit_mm+0x28/0x13c) from [<c0026758>] (do_exit+0xfc/0x324)
[ 472.925000] [<c0026758>] (do_exit+0xfc/0x324) from [<c000cf08>] (die+0xfc/0x13c)
[ 472.930000] [<c000cf08>] (die+0xfc/0x13c) from [<c0010ce4>] (__do_kernel_fault+0x74/0x94)
[ 472.935000] [<c0010ce4>] (__do_kernel_fault+0x74/0x94) from [<c0010e5c>] (do_page_fault+0x158/0x274)
[ 472.940000] [<c0010e5c>] (do_page_fault+0x158/0x274) from [<c0008428>] (do_DataAbort+0x50/0x108)
[ 472.945000] [<c0008428>] (do_DataAbort+0x50/0x108) from [<c0008f8c>] (__dabt_svc+0x2c/0x40)
[ 472.950000] Exception stack(0xc3011e88 to 0xc3011ed0)
[ 472.955000] 1e80: 00000000 00000000 00000002 c3877530 c0610030 c3877500
[ 472.960000] 1ea0: c0610068 00000000 c0610030 c0615d5c c3877668 c3011eec c3011eb0 c3011ed0
[ 472.965000] 1ec0: c001ab30 c001aba0 a0000013 ffffffff
[ 472.970000] [<c0008f8c>] (__dabt_svc+0x2c/0x40) from [<c001aba0>] (pick_next_task_fair+0x30/0x98)
[ 472.975000] [<c001aba0>] (pick_next_task_fair+0x30/0x98) from [<c0483a90>] (__schedule+0x508/0x6c4)
[ 472.980000] [<c0483a90>] (__schedule+0x508/0x6c4) from [<c04841b4>] (schedule+0x58/0x70)
[ 472.985000] [<c04841b4>] (schedule+0x58/0x70) from [<c001f034>] (sys_sched_yield+0x68/0x78)
[ 472.990000] [<c001f034>] (sys_sched_yield+0x68/0x78) from [<c0009480>] (ret_fast_syscall+0x0/0x2c)
Y'a t'il un moyen de générer un dump pour permettre une analyse?
@+
AleaJactaest
Romain Naour
Oct 24, 2012, 7:59:30 PM10/24/12
to concours-li...@googlegroups.com
Bonjour,
J'ai rapidement regardé ton module Xenomai, fait attention avec les spinlock.
Ils ne sont valable que pour le kernel Linux et tu sembles vouloir les utiliser dans ton module xenomai.
Il existe des ipipe_spinlock à utiliser que dans certains cas particulier:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#I-pipe_spinlocks
En ce qui concerne les modules "temps réel", il est préférable d'utiliser l'API RTDM.
http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__rtdm.html
Pour éviter ton problème, peut être programmer deux modules séparé ?
Avec Xenomai le débogage peut se faire avec le ipipe-tracer, mais c'est plus pour la mise au point du kernel patché Adeos/Xenomai.
Sinon essaye d'utiliser kdump:
http://www.dedoimedo.com/computers/kdump.html
http://www.dedoimedo.com/computers/crash-book.html
Bon courage
Romain
J'ai rapidement regardé ton module Xenomai, fait attention avec les spinlock.
Ils ne sont valable que pour le kernel Linux et tu sembles vouloir les utiliser dans ton module xenomai.
Il existe des ipipe_spinlock à utiliser que dans certains cas particulier:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#I-pipe_spinlocks
En ce qui concerne les modules "temps réel", il est préférable d'utiliser l'API RTDM.
http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__rtdm.html
Pour éviter ton problème, peut être programmer deux modules séparé ?
Avec Xenomai le débogage peut se faire avec le ipipe-tracer, mais c'est plus pour la mise au point du kernel patché Adeos/Xenomai.
Sinon essaye d'utiliser kdump:
http://www.dedoimedo.com/computers/kdump.html
http://www.dedoimedo.com/computers/crash-book.html
Bon courage
Romain
Cyprien Laplace
Oct 25, 2012, 12:23:29 AM10/25/12
to concours-li...@googlegroups.com
Bonjour,
Je m'�tonne de voir des spinlocks dans le tas, sachant que pour un
syst�me � un seul c�ur, un linux natif compile les spinlocks comme des
nop. Donc � moins que ce soit une particularit� de linux/xenomai, les
spinlocks ne devraient pas �tre utilis�s pour programmer sur la mini2440.
Et malheureusement pour ton crash je n'ai aucune id�e d'o� il peut venir :(
Le 25/10/12 01:59, Romain Naour a �crit :
> Bonjour,
>
> J'ai rapidement regard� ton module Xenomai, fait attention avec les
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#I-pipe_spinlocks
>
> En ce qui concerne les modules "temps r�el", il est pr�f�rable
>
> Avec Xenomai le d�bogage peut se faire avec le ipipe-tracer, mais
> c'est plus pour la mise au point du kernel patch� Adeos/Xenomai.
Je m'�tonne de voir des spinlocks dans le tas, sachant que pour un
syst�me � un seul c�ur, un linux natif compile les spinlocks comme des
nop. Donc � moins que ce soit une particularit� de linux/xenomai, les
spinlocks ne devraient pas �tre utilis�s pour programmer sur la mini2440.
Et malheureusement pour ton crash je n'ai aucune id�e d'o� il peut venir :(
Le 25/10/12 01:59, Romain Naour a �crit :
> Bonjour,
>
> J'ai rapidement regard� ton module Xenomai, fait attention avec les
> spinlock.
> Ils ne sont valable que pour le kernel Linux et tu sembles vouloir les
> utiliser dans ton module xenomai.
>
> Il existe des ipipe_spinlock � utiliser que dans certains cas particulier:
> Ils ne sont valable que pour le kernel Linux et tu sembles vouloir les
> utiliser dans ton module xenomai.
>
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#I-pipe_spinlocks
>
> En ce qui concerne les modules "temps r�el", il est pr�f�rable
> d'utiliser l'API RTDM.
> http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__rtdm.html
>
> Pour �viter ton probl�me, peut �tre programmer deux modules s�par� ?
> http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__rtdm.html
>
>
> Avec Xenomai le d�bogage peut se faire avec le ipipe-tracer, mais
> c'est plus pour la mise au point du kernel patch� Adeos/Xenomai.
AleaJactaEst
Oct 25, 2012, 3:39:00 PM10/25/12
to concours-li...@googlegroups.com
Bonjour à tous,
J'avais modifié mon code en utilisant IPIPE_DEFINE_SPINLOCK(spinlock_s3c2440_ts), mais j'ai toujours un plantage.
[je n'ai pas changé les fonctions - faut-il changer de fonction pour utiliser le SPINLOCK de IPIPE ?]
J'ai aussi fais des tests avec les rt_mutex.
mais j'obtiens une erreur de droit dans la commande rt_mutex_acquire [Operation not permitted.] quand je lit le device "/dev/xenomai_ts".
Je suppose que la lecture de device s'effectue dans le domaine Linux (problème comment utiliser un mutex fonctionnant dans deux mode [xenomai/Linux])
@+
AleaJactaEst
J'avais modifié mon code en utilisant IPIPE_DEFINE_SPINLOCK(spinlock_s3c2440_ts), mais j'ai toujours un plantage.
[je n'ai pas changé les fonctions - faut-il changer de fonction pour utiliser le SPINLOCK de IPIPE ?]
J'ai aussi fais des tests avec les rt_mutex.
mais j'obtiens une erreur de droit dans la commande rt_mutex_acquire [Operation not permitted.] quand je lit le device "/dev/xenomai_ts".
Je suppose que la lecture de device s'effectue dans le domaine Linux (problème comment utiliser un mutex fonctionnant dans deux mode [xenomai/Linux])
@+
AleaJactaEst
AleaJactaEst
Oct 25, 2012, 6:24:29 PM10/25/12
to concours-li...@googlegroups.com
Bonjour,
J'ai transformé mon module en utilisant une interruption non temps réel [Xenomai - Non-Real-Time Signalling Services]
Cela me permet de déporter la gestion du spinlock dans la partie non temps réel.
Les tests sont en cours.
Cela semble fonctionnement correctement.
@+
AleaJactaEst
J'ai transformé mon module en utilisant une interruption non temps réel [Xenomai - Non-Real-Time Signalling Services]
Cela me permet de déporter la gestion du spinlock dans la partie non temps réel.
Les tests sont en cours.
Cela semble fonctionnement correctement.
@+
AleaJactaEst
Reply all
Reply to author
Forward
0 new messages