Re: [Xenomai-core] hanging in Xenomai 2.5.5

[Gilles Chanteperdrix]

Stefan Schaal wrote:
 Hi Philippe,
 
 thanks a lot for the hint. I configured my kernel from scratch, and
 got rid of the linux compile problems. I could thus verify that the
 commit you mentioned below DOES NOT have the problem I described,
 i.e., semaphores used by multiple processes which are running on
 different cores DID NOT hang anymore.
 
 Then, I thought I try to bisect the problem with git, and I pulled
 the latest version of the 2.5 repository. Interestingly, with the
 very latest commits, my problem has gone away. I confirmed this by
 switching back to Alexis' analogy branch, which I need for my
 development. This branch is not quite as up-to-date as the 2.5
 branch, and the hanging problem still exists. I merged the analogy
 branch with the latest 2.5 branch, and now nothing hangs anymore.
 
 I guess, I stop investigating at this point, unless the problem
 re-apprears.

2.5.6 should be out soon, which should allow you to avoid doing this.

But in the mean-time, you can probably merge the two branches, they
should be fairly orthogonal.

-- 
Gilles.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] CMD based acquisition with Analogy

[Stefan Schaal]

Hi Alexis,

  here is an observation with CMD-based acquisition that puzzles me. Just to 
recall, we use an NI6259 board, using your latest analogy branch of xenomai on 
a 2.6.29.5 kernel in Ubuntu 9.10. Our computer is a 32bit Dell Precision with 8 
core Xeon processors.

 A normal CMD based acquisition with internal trigger has the core elements as 
listed below. What puzzles me that it appears from my tests that the triggering 
of the acquisition with a4l_snd_insn(desc, insn) seems to take about 
200-300 us to complete. This is a very long time for us, as we need to start 
and stop a CMD based acquisition multiple times in our code.

Thus, my question is simply whether this long latency is normal from your 
experience? I used other a4l_snd_insn commands for INSN based data acquisition 
before (and I believe your sync data acquisition uses INSN, too), but always 
had 3-5us duration for these commands.

Best wishes,

-Stefan

//

// fill out data structures
  a4l_cmd_t cmd = {
.idx_subd = ID_SUBDEV_DIGITAL,
.flags = 0,
.start_src = TRIG_INT,// internal trigger
.start_arg = 0,
.scan_begin_src = TRIG_EXT,   
.scan_begin_arg = NI_CDIO_SCAN_BEGIN_SRC_G0_OUT, // channel used to trigger 
the scans
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 32,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 32,
.chan_descs = chans,
  };

  a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = ID_SUBDEV_DIGITAL,
.data_size = 0,
  };

// send command
 rc = a4l_snd_command(desc, cmd);
if (rc  0) 
printf(ni_test: a4l_snd_command failed (ret=%d)\n, rc);
 }

// add some date to FIFO buffer 


// trigger acquisition
rc = a4l_snd_insn(desc, insn);
if (rc  0)
printf(ni_test: triggering failed (rc=%d)\n,rc);

//
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core