[Xenomai-core] Pierre QUELIN/VAL/POSTAL est absent(e).
Je serai absent(e) à partir du 05/07/2010 de retour le 19/07/2010. Je répondrai à votre message dès mon retour.___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Mayday support
On Mon, 2010-06-28 at 16:06 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2010-06-24 at 14:05 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
I've toyed a bit to find a generic approach for the nucleus to regain
complete control over a userland application running in a syscall-less
loop.
The original issue was about recovering gracefully from a runaway
situation detected by the nucleus watchdog, where a thread would spin in
primary mode without issuing any syscall, but this would also apply for
real-time signals pending for such a thread. Currently, Xenomai rt
signals cannot preempt syscall-less code running in primary mode either.
The major difference between the previous approaches we discussed about
and this one, is the fact that we now force the runaway thread to run a
piece of valid code that calls into the nucleus. We do not force the
thread to run faulty code or at a faulty address anymore. Therefore, we
can reuse this feature to improve the rt signal management, without
having to forge yet-another signal stack frame for this.
The code introduced only fixes the watchdog related issue, but also does
some groundwork for enhancing the rt signal support later. The
implementation details can be found here:
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=4cf21a2ae58354819da6475ae869b96c2defda0c
The current mayday support is only available for powerpc and x86 for
now, more will come in the next days. To have it enabled, you have to
upgrade your I-pipe patch to 2.6.32.15-2.7-00 or 2.6.34-2.7-00 for x86,
2.6.33.5-2.10-01 or 2.6.34-2.10-00 for powerpc. That feature relies on a
new interface available from those latest patches.
The current implementation does not break the 2.5.x ABI on purpose, so
we could merge it into the stable branch.
We definitely need user feedback on this. Typically, does arming the
nucleus watchdog with that patch support in, properly recovers from your
favorite get me out of here situation? TIA,
You can pull this stuff from
git://git.xenomai.org/xenomai-rpm.git, queue/mayday branch.
I've retested the feature as it's now in master, and it has one
remaining problem: If you run the cpu hog under gdb control and try to
break out of the while(1) loop, this doesn't work before the watchdog
expired - of course. But if you send the break before the expiry (or hit
a breakpoint), something goes wrong. The Xenomai task continues to spin,
and there is no chance to kill its process (only gdb).
I can't reproduce this easily here; it happened only once on a lite52xx,
and then disappeared; no way to reproduce this once on a dual core atom
in 64bit mode, or on a x86_32 single core platform either. But I still
saw it once on a powerpc target, so this looks like a generic
time-dependent issue.
Do you have the same behavior on a single core config,
You cannot reproduce it on a single core as the CPU hog will occupy that
core and gdb cannot be operated.
and/or without
WARNSW enabled?
Just tried and disabled WARNSW in the test below: no difference.
Also, could you post your hog test code? maybe there is a difference
with the way I'm testing.
#include signal.h
#include native/task.h
#include sys/mman.h
#include stdlib.h
void sighandler(int sig, siginfo_t *si, void *context)
{
printf(SIGDEBUG: reason=%d\n, si-si_value.sival_int);
exit(1);
}
void loop(void *arg)
{
RT_TASK_INFO info;
while (1)
if (!arg)
rt_task_inquire(NULL, info);
}
int main(int argc, const char *argv[])
{
struct sigaction sa;
RT_TASK task;
sigemptyset(sa.sa_mask);
sa.sa_sigaction = sighandler;
sa.sa_flags = SA_SIGINFO;
sigaction(SIGDEBUG, sa, NULL);
mlockall(MCL_CURRENT|MCL_FUTURE);
rt_task_spawn(task, cpu-hog, 0, 99, T_JOINABLE|T_WARNSW, loop,
(void *)(long)((argc 1) strcmp(argv[1], --lethal) == 0));
rt_task_join(task);
return 0;
}
I can't reproduce this issue, leaving the watchdog threshold to the
default value (4s).
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=60
60s seems way too long to have a chance of recovering from a runaway
loop to a reasonably sane state. Do you still see the issue with shorter
timeouts?
CONFIG_XENO_OPT_SHIRQ=y
CONFIG_XENO_OPT_SELECT=y
#
# Timing
#
CONFIG_XENO_OPT_TIMING_PERIODIC=y
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
CONFIG_XENO_OPT_SCALABLE_SCHED=y
# CONFIG_XENO_OPT_TIMER_LIST is not set
CONFIG_XENO_OPT_TIMER_HEAP=y
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
CONFIG_XENO_OPT_TIMER_HEAP_CAPACITY=256
...
Maybe this has some influence as well. The 'RR' correlates with starting
the hog, with or without gdb.
Jan
--
Philippe.
___
Xenomai-core
Re: [Xenomai-core] [PATCH] Mayday support
Philippe Gerum wrote:
On Mon, 2010-06-28 at 16:06 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2010-06-24 at 14:05 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
I've toyed a bit to find a generic approach for the nucleus to regain
complete control over a userland application running in a syscall-less
loop.
The original issue was about recovering gracefully from a runaway
situation detected by the nucleus watchdog, where a thread would spin in
primary mode without issuing any syscall, but this would also apply for
real-time signals pending for such a thread. Currently, Xenomai rt
signals cannot preempt syscall-less code running in primary mode either.
The major difference between the previous approaches we discussed about
and this one, is the fact that we now force the runaway thread to run a
piece of valid code that calls into the nucleus. We do not force the
thread to run faulty code or at a faulty address anymore. Therefore, we
can reuse this feature to improve the rt signal management, without
having to forge yet-another signal stack frame for this.
The code introduced only fixes the watchdog related issue, but also does
some groundwork for enhancing the rt signal support later. The
implementation details can be found here:
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=4cf21a2ae58354819da6475ae869b96c2defda0c
The current mayday support is only available for powerpc and x86 for
now, more will come in the next days. To have it enabled, you have to
upgrade your I-pipe patch to 2.6.32.15-2.7-00 or 2.6.34-2.7-00 for x86,
2.6.33.5-2.10-01 or 2.6.34-2.10-00 for powerpc. That feature relies on a
new interface available from those latest patches.
The current implementation does not break the 2.5.x ABI on purpose, so
we could merge it into the stable branch.
We definitely need user feedback on this. Typically, does arming the
nucleus watchdog with that patch support in, properly recovers from your
favorite get me out of here situation? TIA,
You can pull this stuff from
git://git.xenomai.org/xenomai-rpm.git, queue/mayday branch.
I've retested the feature as it's now in master, and it has one
remaining problem: If you run the cpu hog under gdb control and try to
break out of the while(1) loop, this doesn't work before the watchdog
expired - of course. But if you send the break before the expiry (or hit
a breakpoint), something goes wrong. The Xenomai task continues to spin,
and there is no chance to kill its process (only gdb).
I can't reproduce this easily here; it happened only once on a lite52xx,
and then disappeared; no way to reproduce this once on a dual core atom
in 64bit mode, or on a x86_32 single core platform either. But I still
saw it once on a powerpc target, so this looks like a generic
time-dependent issue.
Do you have the same behavior on a single core config,
You cannot reproduce it on a single core as the CPU hog will occupy that
core and gdb cannot be operated.
and/or without
WARNSW enabled?
Just tried and disabled WARNSW in the test below: no difference.
Also, could you post your hog test code? maybe there is a difference
with the way I'm testing.
#include signal.h
#include native/task.h
#include sys/mman.h
#include stdlib.h
void sighandler(int sig, siginfo_t *si, void *context)
{
printf(SIGDEBUG: reason=%d\n, si-si_value.sival_int);
exit(1);
}
void loop(void *arg)
{
RT_TASK_INFO info;
while (1)
if (!arg)
rt_task_inquire(NULL, info);
}
int main(int argc, const char *argv[])
{
struct sigaction sa;
RT_TASK task;
sigemptyset(sa.sa_mask);
sa.sa_sigaction = sighandler;
sa.sa_flags = SA_SIGINFO;
sigaction(SIGDEBUG, sa, NULL);
mlockall(MCL_CURRENT|MCL_FUTURE);
rt_task_spawn(task, cpu-hog, 0, 99, T_JOINABLE|T_WARNSW, loop,
(void *)(long)((argc 1) strcmp(argv[1], --lethal) == 0));
rt_task_join(task);
return 0;
}
I can't reproduce this issue, leaving the watchdog threshold to the
default value (4s).
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=60
60s seems way too long to have a chance of recovering from a runaway
loop to a reasonably sane state.
That's required for debugging the kernel.
Do you still see the issue with shorter
timeouts?
Yes, I usually lower the timeout before triggering the issue.
OK, I will try to find some time to look closer at this.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Mayday support
On Tue, 2010-07-06 at 17:54 +0200, Jan Kiszka wrote: CONFIG_XENO_OPT_WATCHDOG=y CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=60 60s seems way too long to have a chance of recovering from a runaway loop to a reasonably sane state. That's required for debugging the kernel. I don't understand this requirement. Any insight? Do you still see the issue with shorter timeouts? Yes, I usually lower the timeout before triggering the issue. OK, I will try to find some time to look closer at this. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Mayday support
Philippe Gerum wrote: On Tue, 2010-07-06 at 17:54 +0200, Jan Kiszka wrote: CONFIG_XENO_OPT_WATCHDOG=y CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=60 60s seems way too long to have a chance of recovering from a runaway loop to a reasonably sane state. That's required for debugging the kernel. I don't understand this requirement. Any insight? While you step though a Xenomai task context, timers continue to tick. So the period spent in that context gets huge, and soon the task will be shot by the watchdog. Likely a limitation of kvm (interrupts should be blockable in singlestep mode). Haven't looked at all details yet, just picked the lazy workaround. Of course, we don't use this value on real HW. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi Alexis,
I conceptually understand what you are telling us, but I am bit confused how
to implement your advice:
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
The data structures in question are:
/* The command to send by default */
a4l_cmd_t cmd = {
.idx_subd = -1,
.flags = 0,
.start_src = TRIG_INT,
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = 0, /* in ns */
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 4,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 4,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = -1,
.data_size = 0,
};
Thus, I assume you mean that
scan_begin_src = TRIG_EXT
should be modified to one of the enum items below? Are all these timers
automatically running, or do they need to be configured, too? Sorry, I am a bit
at a loss how to proceed.
Best wishes,
-Stefan
On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not
sure that there is anything special to be configured. I will check again.
Feel free to log into our machine with the pwd I indicated to you some time
ago. The computer is not used productively.
Sorry for answering late, I was unavailable.
My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ?
As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.
I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.
I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in:
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)
So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the CDO_Mode register values and the sample clock source),
do not hesitate to help us.
Argh, I found it. I did not see an item in the url displayed above.
Here is an enum found in:
ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
// Field Accessors (Compile-time selectable)
typedef enum {
kCDO_Update_Source_SelectGround= 0,
kCDO_Update_Source_SelectPFI0 = 1,
kCDO_Update_Source_SelectPFI1 = 2,
kCDO_Update_Source_SelectPFI2 = 3,
kCDO_Update_Source_SelectPFI3 = 4,
kCDO_Update_Source_SelectPFI4 = 5,
kCDO_Update_Source_SelectPFI5 = 6,
kCDO_Update_Source_SelectPFI6 = 7,
kCDO_Update_Source_SelectPFI7 = 8,
kCDO_Update_Source_SelectPFI8 = 9,
kCDO_Update_Source_SelectPFI9 = 10,
kCDO_Update_Source_SelectRTSI0 = 11,
kCDO_Update_Source_SelectRTSI1 = 12,
kCDO_Update_Source_SelectRTSI2 = 13,
kCDO_Update_Source_SelectRTSI3 = 14,
kCDO_Update_Source_SelectRTSI4 = 15,
kCDO_Update_Source_SelectRTSI5 = 16,
kCDO_Update_Source_SelectRTSI6 = 17,
kCDO_Update_Source_SelectAI_Start = 18,
kCDO_Update_Source_SelectAI_Convert= 19,
kCDO_Update_Source_SelectPXI_Star_Trigger = 20,
kCDO_Update_Source_SelectPFI10 = 21,
kCDO_Update_Source_SelectPFI11 = 22,
kCDO_Update_Source_SelectPFI12 = 23,
kCDO_Update_Source_SelectPFI13 = 24,
