Re: [Xenomai-core] [Xenomai-help] Experimenting with Analogy. Bugs found?
Daniele Nicolodi wrote:
2. Looks like it is not possible to setup an endless acquisition. If I
set .stop_src = TRIG_NONE and .stop_arg = 0, the command submission goes
fine, but I obtain an ENOENT error at the first a4l_sys_read(). I have
no idea on where to look to track down this issue.
The attached patch (against Alex git three) fixes the problem, in the
case of analog input. I haven't test the same condition for analog output.
Cheers,
--
Daniele
diff --git a/include/analogy/buffer.h b/include/analogy/buffer.h
index 0e8f279..e7b2416 100644
--- a/include/analogy/buffer.h
+++ b/include/analogy/buffer.h
@@ -253,7 +253,8 @@ static inline int __abs_put(a4l_buf_t * buf, unsigned long count)
if ((old / buf-size) != (count / buf-size))
set_bit(A4L_BUF_EOBUF_NR, buf-evt_flags);
- if (count = buf-end_count)
+ /* In the case of continuos acquisition end_count is zero */
+ if ((buf-end_count != 0) (count = buf-end_count))
set_bit(A4L_BUF_EOA_NR, buf-evt_flags);
return 0;
@@ -303,10 +304,15 @@ static inline unsigned long __count_to_get(a4l_buf_t * buf)
{
unsigned long ret;
- if (buf-end_count != 0 (buf-end_count buf-prd_count))
+ /* In the case of continuos acquisition end_count is zero */
+ if (buf-end_count != 0) {
+ if (buf-end_count buf-prd_count)
+ ret = buf-prd_count;
+ else
+ ret = buf-end_count;
+ } else {
ret = buf-prd_count;
- else
- ret = buf-end_count;
+ }
if (ret buf-cns_count)
ret -= buf-cns_count;
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL REQUEST] analogy: bug fixes
Alexis Berlemont wrote: The following changes since commit 8cfc1103fe1cf9e700698e8230baf562ffb5cf06: Gilles Chanteperdrix (1): x86 syscalls: make __xn_get_eip a macro are available in the git repository at: git://git.xenomai.org/xenomai-abe.git analogy Hello. Looking at your pull request, I see that my patch for correct buffer handling when using .stop_src = TRIG_NONE is not included. Does the patch need some more work? Or it simply get lost on the way? Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL REQUEST] analogy: bug fixes
Alexis Berlemont wrote: Daniele Nicolodi wrote: Alexis Berlemont wrote: The following changes since commit 8cfc1103fe1cf9e700698e8230baf562ffb5cf06: Gilles Chanteperdrix (1): x86 syscalls: make __xn_get_eip a macro are available in the git repository at: git://git.xenomai.org/xenomai-abe.git analogy Hello. Looking at your pull request, I see that my patch for correct buffer handling when using .stop_src = TRIG_NONE is not included. Does the patch need some more work? Or it simply get lost on the way? I have not forgotten it. I did not include it for two reasons: - I have not found time to (fully) test it - I wanted to properly modify the test program cmd_read so as to allow continuous acquisisitions Hi Alexis. Sorry for the late response. That's fine, I just wanted to be sure that the patch was not dropped by mistake. I'll test continuous output today and let you know if any other bugfix is necessary. I can also look into providing a patch for cmd_read and cmd_write. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL REQUEST] analogy: bug fixes
Daniele Nicolodi wrote: Alexis Berlemont wrote: If you want to test infinite acquisitions right now, you can clone my git repository. I just pushed the modifications on it. I have not made a pull request yet because I want to be sure there is no regression. Thanks! I'll test it as soon as possible. I'm testing it now. I think I just stumbled into the ring buffer bug you fixed in your repository :-) It took me a while to understand if the problem was in the hardware, in my code, or somewhere else in the stack... Unfortunately my ring buffer problem is not fixed by you patch. What I'm experiencing is exposed by this (pseudo) code: a4l_open(dsc, device) a4l_mmap(dsc, subdevice, bufsize, map) a4l_snd_command(dsc, cmd) /* preload buffer */ written = write_to_buffer(map, bufsize) /* send internal trigger */ a4l_snd_insn(dsc, cnt = 0; while (1) a4l_mark_bufrw(dsc, subdevice, written, towrite); cnt += written; /* 1 */ written = write_buffer(map + (cnt % bufsize), towrite) The problem is that at the place marked with (1) the total extension of the buffer region that gets written exceeds the ring buffer allocated memory. That is ((cnt % bufsize) + towrite) bufsize ! I do not know if this should be handled in my code, or in the driver. This situation is not handled in the cmd_write example code (where a simple memcpy() is done). What do you think? Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Bug in a4l_get_chan
Hello Alexis, I found that a4l_get_chan() in buffer.c does not work for subdevices that use a global channels description struct (mode = A4L_CHAN_GLOBAL_CHANDESC in the a4l_chdesc_t structure). The problem is that a4l_get_chan() iterates (twice) on the chan_desc array looking for channel descriptions at indexes higher than 0, also in the case where those are not populated because the subdevice uses a single channel description structure for all channels. This bug is quite bas, as it triggers a kernel oops for a integer division by zero when an a4l_cmd_t command is issued with a channels description array that does not have the channel id 0 as first acquired channel. You can easily reproduce the bug using the ni_pcimio driver, using cmd_read with the parameter -c 1. I'm looking into providing a patch, but I have some difficulties in understanding the rational of this part of analogy code... Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL REQUEST] analogy: bug fixes
Alexis Berlemont wrote: There is a bug in cmd_write and cmd_read. I have should have taken into account the buffers edges. I will fix it. The function a4l_mark_bufrw() is not designed to handle boundaries, that is why its arguments represent data size not addresses. That makes sense. I can provide a patch for cmd_read and cmd_write, as i got the same kind of code working in my own test programs, but I'm quite busy right now... Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed
Alexis Berlemont wrote: Daniele Nicolodi wrote: After fixing analogy to permit continuous acquisition, I discovered that ongoing commands are not canceled when a device is closed (I obtain a DMA buffer owerwrite warning in the kernel log when I abruptly terminate my acquisition program). I think this is quite a surprising behavior. I would expect that the commands are canceled when there isn't a data consumer any more. Would it be possible to cancel any ongoing command on device close? If there is agreement on this, I can look into providing a patch. The close should indeed stop any occurring acquisition. I implemented this behaviour. It is in my git repository. Hi Alexis. I have been working with analogy from your git three and I should say that the new behavior, in my use case, is worst than the previous. Now, when a device is closed, all accurring acquisition are terminated, also the ones that haven't been started by the current process. While it is possible to use at the same time two different subdevices, from two different processes, now it is not possible to terminate one process and leave the other one running. I think that the correct behavior would be to terminate just the acquisitions started by the current process. However, I have no idea on how difficult this would be. This bring me also to the fact that there isn't currently a way to prevent two concurrent processes to access the same subdevice, interfering each other. Would it possible to have a lock() method, as comedi has? Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Analogy: improve a4l_find_range()
Hello Alexis, I wrote a small patch to improve a4l_find_range().
As many every other functions expect to have the range specified as its
idx into the struct describing the subdevice it is useful have it
returned from a4l_find_range(). I also made returning a pointer to the
range struncture optional.
I also attache a simple patch to clean up trailing whitespaces in the
range.c file.
Cheers,
--
Daniele
commit ec80d59f5ecfdc74b45d9da7edfdb54f6cab555a
Author: Daniele Nicolodi nicol...@science.unitn.it
Date: Mon Mar 29 22:11:44 2010 +0200
Make a4l_find_range() more useful by returning the idx of the most suitable range too.
diff --git a/src/drvlib/analogy/range.c b/src/drvlib/analogy/range.c
index 934c52a..fc4e302 100644
--- a/src/drvlib/analogy/range.c
+++ b/src/drvlib/analogy/range.c
@@ -154,8 +154,9 @@ int a4l_sizeof_subd(a4l_sbinfo_t *subd)
* @param[in] max Maximal limit value
* @param[out] rng Found range
*
- * @return 0 on success. Otherwise:
+ * @return The index of the most suitable range on success. Otherwise:
*
+ * - -ENOENT is returned if a suitable range is not found.
* - -EINVAL is returned if some argument is missing or wrong;
*idx_subd, idx_chan and the dsc pointer should be checked; check
*also the kernel log (dmesg); WARNING: a4l_fill_desc() should
@@ -171,10 +172,14 @@ int a4l_find_range(a4l_desc_t * dsc,
int i, ret;
long lmin, lmax;
a4l_chinfo_t *chinfo;
- a4l_rnginfo_t *rnginfo;
+ a4l_rnginfo_t *rnginfo, *tmp = NULL;
+ unsigned int idx_rng = -ENOENT;
+
+ if (rng != NULL)
+ *rng = NULL;
/* Basic checkings */
- if (dsc == NULL || rng == NULL)
+ if (dsc == NULL)
return -EINVAL;
/* a4l_fill_desc() must have been called on this descriptor */
@@ -184,38 +189,39 @@ int a4l_find_range(a4l_desc_t * dsc,
/* Retrieves the ranges count */
ret = a4l_get_chinfo(dsc, idx_subd, idx_chan, chinfo);
if (ret 0)
- goto out_get_range;
+ return ret;
/* Initializes variables */
lmin = (long)(min * A4L_RNG_FACTOR);
lmax = (long)(max * A4L_RNG_FACTOR);
- *rng = NULL;
/* Performs the research */
for (i = 0; i chinfo-nb_rng; i++) {
ret = a4l_get_rnginfo(dsc, idx_subd, idx_chan, i, rnginfo);
if (ret 0)
- goto out_get_range;
+ return ret;
if (A4L_RNG_UNIT(rnginfo-flags) == unit
rnginfo-min = lmin rnginfo-max = lmax) {
- if (*rng != NULL) {
-if (rnginfo-min = (*rng)-min
-rnginfo-max = (*rng)-max)
- *rng = rnginfo;
- } else
-*rng = rnginfo;
+ if (tmp != NULL) {
+if (rnginfo-min = tmp-min
+rnginfo-max = tmp-max) {
+ idx_rng = i;
+ tmp = rnginfo;
+}
+ } else {
+idx_rng = i;
+tmp = rnginfo;
+ }
}
}
-out_get_range:
-
- if (ret 0)
- *rng = NULL;
+ if (rng != NULL)
+ *rng = tmp;
- return ret;
+ return idx_rng;
}
/**
commit 10dca3a6ae97cff6b2ebf9cf595283ffac94af44
Author: Daniele Nicolodi nicol...@science.unitn.it
Date: Mon Mar 29 22:13:03 2010 +0200
Remove trailing white spaces.
diff --git a/src/drvlib/analogy/range.c b/src/drvlib/analogy/range.c
index fc4e302..51b0405 100644
--- a/src/drvlib/analogy/range.c
+++ b/src/drvlib/analogy/range.c
@@ -130,7 +130,7 @@ int a4l_sizeof_subd(a4l_sbinfo_t *subd)
channels are acquired in one shot); for other kind of
subdevice, the user must use a4l_sizeof_chan() so as to
find out the size of the channel he wants to use */
- if ((subd-flags A4L_SUBD_TYPES) != A4L_SUBD_DIO
+ if ((subd-flags A4L_SUBD_TYPES) != A4L_SUBD_DIO
(subd-flags A4L_SUBD_TYPES) != A4L_SUBD_DI
(subd-flags A4L_SUBD_TYPES) != A4L_SUBD_DO)
return -EINVAL;
@@ -233,7 +233,7 @@ int a4l_find_range(a4l_desc_t * dsc,
*
* @param[in] chan Channel descriptor
* @param[in] rng Range descriptor
- * @param[out] dst Ouput buffer
+ * @param[out] dst Ouput buffer
* @param[in] src Input buffer
* @param[in] cnt Count of transfer to copy
*
@@ -257,7 +257,7 @@ int a4l_rawtoul(a4l_chinfo_t * chan, unsigned long *dst, void *src, int cnt)
if (chan == NULL)
return -EINVAL;
- /* Find out the size in memory */
+ /* Find out the size in memory */
size = a4l_sizeof_chan(chan);
/* Get the suitable accessor */
@@ -285,7 +285,7 @@ int a4l_rawtoul(a4l_chinfo_t * chan, unsigned long *dst, void *src, int cnt)
j++;
}
- return j;
+ return j;
}
/**
@@ -293,7 +293,7 @@ int a4l_rawtoul(a4l_chinfo_t * chan, unsigned long *dst, void *src, int cnt)
*
* @param[in] chan Channel descriptor
* @param[in] rng Range descriptor
- * @param[out] dst Ouput buffer
+ * @param[out] dst Ouput buffer
* @param[in] src Input buffer
* @param[in] cnt Count of conversion to perform
*
@@ -322,7 +322,7 @@ int a4l_rawtof(a4l_chinfo_t * chan,
if (rng == NULL || chan == NULL)
return -EINVAL;
- /* Find out the size in memory */
+ /* Find out the size in memory */
size = a4l_sizeof_chan(chan);
/* Get the suitable accessor */
@@ -366,7 +366,7 @@ int a4l_rawtof(a4l_chinfo_t * chan,
*
* @param[in] chan
[Xenomai-core] Analogy: A4L_CHAN_AREF_* and AREF_* and other macros
Hello Alexis, I have noticed that in Analogy headers there are two sets of macros to define channels references, one with prefix A4L_CHAN_AREF_ and the other with prefix AREF_. I think keeping both is confusing and dangerous, because similar symbols are defined with different numerical values! The later form is the one used in comedi API and drivers, but i think it is better to prefix all exported symbols and constants with a namespace like string. I would be for keeping only the former form. If you agree, I can provide a patch for you to review. Similarly, I would rename TRIG_ constants to something like A4L_TRIG_, and while at it I think TRIG_WAKE_EOS should become A4L_CMD_WAKE_EOS, as it is a command flag and not a trigger source. Similarly, it would be nice also to rename other macros defined in command.h, adding at least a common A4L_ prefix. While at it I think that, maybe after a rename to make their purpose more clear, CR_* macros should be exposed to user space too. If you think API breakage should be avoided, even in a so early stage of development and diffusion, we can keep the old definitions for a while, issuing deprecation warning (in this case those symbols would have to be exposed as constant variables where to apply the __deprecated__ gcc attribute). Let me know what you think about this proposal. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
On 19/05/10 07:49, Gilles Chanteperdrix wrote: Jan Kiszka wrote: Just like it seems to be the case for Steve (unless I misunderstood his reply), it is very useful for us being able to time-stamp events in RT context that need to be correlated with events stamped in non-RT (including non-Xenomai) parts or even on other systems: (offline) data fusion, logging, tracing. I even bet that this is currently the major use case for synchronized clocks, only a smaller part already has the need to synchronize timed activities on a common clock source. But there is huge potential in the second part once we can provide a stable infrastructure. I already had such issues, and I did not solve them by modifying Xenomai core. I'm using Xenomai for scientific data acquisition, so I'm quite interested to the issue. Can I ask you to detail how you solved the issue? Maybe it's not much related, but there is any possibility to synchronize either linux or xenomay clocks to an external clock source, let say the GPS timing signal from a GPS receiver? Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [git pull] Patch queue for 2.5.x
On 02/10/10 08:40, Jan Kiszka wrote: The following changes since commit 5e7cfa5c25672e4478a721eadbd6f6c5b4f88a2f: nucleus/sched: fix rescheduling bit test macros (2010-09-30 02:34:27 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-jki.git for-2.5.x Jan Kiszka (8): RTDM: Protect xnshadow_ppd_get via nklock Fix symbolic status ouput of root threads Create watchdog as non-blockable timer native: Improve documentation of rt_task_join and rt_task_delete x86: Add PCI ID of Series 5/3400 Intel chipset to SMI workaround x86: Add PCI ID of 631xESB/632xESB/3100 Intel chipset to SMI workaround x86: Add PCI ID of Intel ICH9M-E chipset to SMI workaround This patch reads: +#ifdef PCI_DEVICE_ID_INTEL_ICH9_1 +#define PCI_DEVICE_ID_INTEL_ICH9_1 0x2917 +#endif shouldn't it be #ifndef ... #define ... #endif instead? x86: Add PCI ID of Intel ICH9M chipset to SMI workaround Same for this one. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy regressions in xenomai 2.5.5.1
On 12/10/10 10:56, Philippe Gerum wrote: When I proposed some easy changes to the analogy API, to make it much less confusing with trivial changes, Alexis expressed concerns about API stability. What about functional stability? I think the reported ones are major problems easily catch with simple pre-release tests... Do not hesitate to provide them. I'll try to write something later today. There is a testing infrastructure where those test should fit? I haven't found one in xenomai source code. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy regressions in xenomai 2.5.5.1
On 13/10/10 08:31, Alexis Berlemont wrote:
1. Buffer management is badly broken. It is not possible to run any
acquisition command that wraps around in the ring buffer. That can be
simply reproduced with:
cmd_read -v d analogy0 -s 0 -S 0
after a while it will fail with: cmd_read: a4l_read failed (ret=-32).
In dmesg the driver reports: Analogy: MITE: DME overwrite of free area.
OK. Maybe, it is not Analogy's buffer management; it may be specific
to the NI driver. Did you try to reproduce the bug with another driver
(analogy_fake for example)? It may be due to some fix I made this
summer (which is surprising, I thought I tested the change quite
exhaustively... Sorry for that).
The problem is probably in the NI driver. I'm unable to reproduce the
bug with the analogy_fake driver. See attached test script.
2. Buffer is kept memory mapped after the mapping process dies. If a
process mapping a device buffer dies before un-mapping the buffer, it is
not possible to reconfigure the bnuffer. a4l_set_bufsize fails with
error code 32 and dmesg read Analogy: a4l_ioctl_bufcfg: please unmap
before configuring buffer. Sinche the mapping process died I do not
know how to do this.
With a 2.4.x release, did you manage to reproduce the bug?
I'm unable to reproduce the bug with xenomai 2.5.3. See attached test.
It depends on a patch to make the --read-buffer-size and
--write-buffer-size options to analogy_config to effectively work. Also
attached. I do not have a 2.5.4 version handy.
Cheers,
--
Daniele
test_buffer_bug.sh
Description: Bourne shell script
test_mmap_bug.sh
Description: Bourne shell script
/**
* analogy for linux - input command test program
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/mman.h
#include errno.h
#include getopt.h
#include string.h
#include analogy/analogy.h
/* default device name */
#define DEVICE analogy0
#define DEBUG(frmt, args...) fprintf(stderr, frmt\n, ##args)
#define ERROR(frmt, args...) fprintf(stderr, frmt\n, ##args)
int main(int argc, char **argv)
{
int rv = 0;
unsigned long bufsize;
void *map = NULL;
a4l_desc_t dsc;
char *filename = argv[1];
/* open the device */
rv = a4l_open(dsc, filename);
if (rv 0) {
ERROR(analogy open);
return rv;
}
/* cancel any command which might be in progress */
a4l_snd_cancel(dsc, dsc.idx_read_subd);
/* get buffer size to map */
rv = a4l_get_bufsize(dsc, dsc.idx_read_subd, bufsize);
if (rv 0) {
ERROR(analogy get bufsize);
return rv;
}
/* map read subdevice buffer */
rv = a4l_mmap(dsc, dsc.idx_read_subd, bufsize, map);
if (rv 0) {
ERROR(analogy mmap);
return rv;
}
if (argc 2) {
DEBUG(BUG!);
} else {
/* unmap subdevice buffer */
munmap(map, bufsize);
}
/* close file descriptor */
a4l_close(dsc);
exit(0);
}
commit e7ac38f3f45e439a8d383f3b4adafbb97bf543fe
Author: Daniele Nicolodi nicol...@science.unitn.it
Date: Wed Oct 13 16:03:30 2010 +0200
Make the --read-buffer-size and --write-buffer-size otpions effective.
diff --git a/src/utils/analogy/analogy_config.c b/src/utils/analogy/analogy_config.c
index 1482322..2ce3ddd 100644
--- a/src/utils/analogy/analogy_config.c
+++ b/src/utils/analogy/analogy_config.c
@@ -31,28 +31,25 @@
#include analogy/analogy.h
-/* Declare precompilation constants */
-#define __NBMIN_ARG 2
-#define __NBMAX_ARG 3
-#define __OPTS_DELIMITER ,
+enum action {
+ ATTACH_DRIVER,
+ DETACH_DRIVER,
+ CONFIGURE_BUFFER_SIZE,
+};
-/* Declare prog variables */
-int vlevel = 1;
-int unatt_act = 0;
-struct option a4l_conf_opts[] = {
- {help, no_argument, NULL, 'h'},
- {verbose, no_argument, NULL, 'v'},
- {quiet, no_argument, NULL, 'q'},
- {version, no_argument, NULL, 'V'},
- {remove, no_argument, NULL, 'r'},
- {read-buffer-size, required_argument, NULL, 'R'},
- {write-buffer-size, required_argument, NULL, 'W'},
- {0},
+enum subdevice {
+ READ_SUBDEVICE,
+ WRITE_SUBDEVICE,
};
+/* Verbosity level */
+int vlevel = 1;
+
+/* Driver specific Options delimiter */
+#define DELIMITER ,
+
int compute_opts(char *opts, unsigned int *nb, unsigned long *res)
{
-
int ret = 0, len, ofs;
/* Check arg and inits it */
@@ -67,7 +64,7 @@ int compute_opts(char *opts, unsigned int *nb, unsigned long *res)
do {
(*nb)++;
len = strlen(opts);
- ofs = strcspn(opts, __OPTS_DELIMITER);
+ ofs = strcspn(opts, DELIMITER);
if (res != NULL) {
res[(*nb) - 1] = strtoul(opts, NULL, 0);
if (errno != 0) {
@@ -104,79 +101,57 @@ void do_print_usage(void)
\t\t -W, --write-buffer-size: write buffer size in kB\n);
}
-int main(int argc, char *argv[])
+int detach_driver(const char *devfile)
{
- int c;
- char *devfile;
- a4l_lnkdesc_t lnkdsc;
- int chk_nb, ret = 0, fd = -1;
-
- /* Init the descriptor structure
Re: [Xenomai-core] Analogy regressions in xenomai 2.5.5.1
Hi Alexis, do you have the possibility to look at those bugs soonish? Otherwise I can try to fix them, but I would need some hints on where I should look in the code. Thank you. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy regressions in xenomai 2.5.5.1
On 15/10/10 12:15, Alexis Berlemont wrote: Hi, Do not worry. I have not forgotten. Sorry, I didn't want to imply that you forgot about the issues. It was just to let you know that I'm willing to work on the issues, but I do not know the code well enough to be able to isolate the issue without spending quite a lot of time. If you give me an hint I'll be happy to help, in a way compatible to my PhD thesis writing... :-) I think analogy is a nice project, and I think that with xenomai 3.0 where the RTDM layer would not depend anymore on ipipe I think it has the potential to overtake comedi, and I would like to invest more time on it. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems with gcc 4.6.0 (rt_task_shadow fails with ENOSYS)
On 07/07/11 22:47, Anders Blomdell wrote: When compiling kernel 2.6.37.3 and xenomai 2.5.6 with gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC), programs fail with -ENOSYS in rt_task_shadow. If compiled with gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) everything works as expected. I just want to note that I encountered the same problem on Debian testing. Unfortunately I can not provide more details right now (I'm at the Amaldi9 conference in Cardiff, any Xenomai dev or user around?) Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems with gcc 4.6.0 (rt_task_shadow fails with ENOSYS)
On 11/07/11 20:43, Gilles Chanteperdrix wrote: On 07/07/2011 11:47 PM, Anders Blomdell wrote: When compiling kernel 2.6.37.3 and xenomai 2.5.6 with gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC), programs fail with -ENOSYS in rt_task_shadow. If compiled with gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) everything works as expected. I think it is due to the modifications of syscall.h I made to implement pseudo-signals handling, which implementation was never finished, and removed in xenomai-head. Could you try xenomai-head to see if you get the failure? I tried backporting it, but the code evolved too much in both repositories, the backport needs to spend some time on it, so, I would like to know whether it is really needed. Has this issue been investigated further? I may have the occasion to try again to compile a Xenomai kernel with gcc 4.6 this week and I would like to know where to start to debug and solve this issue. Thank you. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems with gcc 4.6.0 (rt_task_shadow fails with ENOSYS)
On 27/07/11 20:55, Gilles Chanteperdrix wrote: The issue has been investigated, as explained in the mail you are quoting, it seems to be due to the implementation of pseudo-signals which as in xenomai 2.5 code and no longer is in xenomai-head code. In order to get confirmation, I am still waiting for someone to test xenomai-head with gcc 4.6. Thank you Gilles. I was checking if any confirmation of the cause of the bug was given, just to not waste the limited time I have to test this performing a test with known results. I'll compile xenomai-head with gcc 4.6 and report my results. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] xenomai-head compile failure
Hello, I'm compiling xenomai-head on i386 debian/testing. I found that the file src/skins/posix/wrappers.c is missing an include of signal.h for the definition of pthread_kill(). Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
On 11/08/11 13:43, Daniele Nicolodi wrote: I submitted the debian bug, beside what is the cause of the problem, binaries compiled with gcc-4.6 are not usable, but binaries compiled with gcc-4.4 are. I'm compiling xenomai-head right now (this requires compiling both user space and kernel space, so testing requires some more time). I'll let you know ASAP. Hello, I compiled linux 2.6.38.8 and xenomai-head with gcc-4.6. The obtained kernel boots fine but xenomai services do not: latency hangs right after the sched_setscheduler system call. With the same kernel I compiled user space with gcc-4.4 and xenomia services work just fine. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
On 11/08/11 19:22, Gilles Chanteperdrix wrote: Please try and find the point in the latency test where the hang happens (it probably happens when calling a xenomai service, so, not sched_setscheduler), and then post the two disassemblies of this service implementation in libnative.so, the one compiled with 4.4, the other with 4.6. The latency test hangs in rt_task_create() attached the function disassemblies obtained with gcc-4.4 and gcc-4.6. Hope that this helps, those are Aramaic to me. Cheers, -- Daniele 4f90 rt_task_create: 4f90: 55 push %ebp 4f91: 31 c0 xor%eax,%eax 4f93: 89 e5 mov%esp,%ebp 4f95: 57 push %edi 4f96: 56 push %esi 4f97: 53 push %ebx 4f98: 83 ec 7csub$0x7c,%esp 4f9b: e8 17 d8 ff ff call 27b7 __i686.get_pc_thunk.bx 4fa0: 81 c3 24 17 00 00 add$0x1724,%ebx 4fa6: 53 push %ebx 4fa7: 89 c3 mov%eax,%ebx 4fa9: b8 2b 02 00 02 mov$0x200022b,%eax 4fae: cd 80 int$0x80 4fb0: 5b pop%ebx 4fb1: 8b 45 08mov0x8(%ebp),%eax 4fb4: 8d 75 a0lea-0x60(%ebp),%esi 4fb7: 8b 7d 18mov0x18(%ebp),%edi -- 4ff9: 75 11 jne500c rt_task_create+0x7c 4ffb: e8 98 d5 ff ff call 2598 getpagesize@plt 5000: 8d b8 00 40 00 00 lea0x4000(%eax),%edi 5006: 89 bb cc 00 00 00 mov%edi,0xcc(%ebx) 500c: 8b 55 10mov0x10(%ebp),%edx 500f: 85 d2 test %edx,%edx 5011: 75 07 jne501a rt_task_create+0x8a 5013: c7 45 90 00 80 00 00movl $0x8000,-0x70(%ebp) 501a: c7 44 24 04 01 00 00movl $0x1,0x4(%esp) 5021: 00 5022: 89 34 24mov%esi,(%esp) 5025: e8 ce d4 ff ff call 24f8 pthread_attr_setinheritsched@plt 502a: 8b 45 14mov0x14(%ebp),%eax 502d: c7 45 e4 00 00 00 00movl $0x0,-0x1c(%ebp) 5034: 85 c0 test %eax,%eax 5036: 0f 8e bc 00 00 00 jle50f8 rt_task_create+0x168 503c: c7 44 24 04 01 00 00movl $0x1,0x4(%esp) 5043: 00 5044: 89 34 24mov%esi,(%esp) 5047: e8 9c d4 ff ff call 24e8 pthread_attr_setschedpolicy@plt 504c: 8b 45 14mov0x14(%ebp),%eax 504f: 89 45 e4mov%eax,-0x1c(%ebp) 5052: 8d 45 e4lea-0x1c(%ebp),%eax 5055: 89 44 24 04 mov%eax,0x4(%esp) 5059: 89 34 24mov%esi,(%esp) 505c: e8 07 d5 ff ff call 2568 pthread_attr_setschedparam@plt 5061: 8b 45 90mov-0x70(%ebp),%eax 5064: 39 f8 cmp%edi,%eax 5066: 73 02 jae506a rt_task_create+0xda 5068: 89 f8 mov%edi,%eax 506a: 89 44 24 04 mov%eax,0x4(%esp) 506e: 89 34 24mov%esi,(%esp) 5071: e8 82 d5 ff ff call 25f8 pthread_attr_setstacksize@plt 5076: 8b 7d 18mov0x18(%ebp),%edi 5079: 81 e7 00 04 00 00 and$0x400,%edi 507f: 89 7d 90mov%edi,-0x70(%ebp) 5082: 74 5c je 50e0 rt_task_create+0x150 5084: 8d 45 c4lea-0x3c(%ebp),%eax 5087: 89 44 24 0c mov%eax,0xc(%esp) 508b: 8d 83 cc e7 ff ff lea-0x1834(%ebx),%eax 5091: 89 44 24 08 mov%eax,0x8(%esp) 5095: 8d 45 e0lea-0x20(%ebp),%eax 5098: 89 74 24 04 mov%esi,0x4(%esp) 509c: 89 04 24mov%eax,(%esp) 509f: e8 e4 d5 ff ff call 2688 __real_pthread_create@plt 50a4: 85 c0 test %eax,%eax 50a6: 75 28 jne50d0 rt_task_create+0x140 50a8: 8b 7d 94mov-0x6c(%ebp),%edi 50ab: 53 push %ebx 50ac: 89 fb mov%edi,%ebx 50ae: b8 2b 02 00 01 mov$0x100022b,%eax 50b3: cd 80 int$0x80 50b5: 5b pop%ebx 50b6: 85 c0 test %eax,%eax 50b8: 89 c6 mov%eax,%esi 50ba: 74
Re: [Xenomai-core] gcc-4.6 issue
On 12/08/11 01:18, Gilles Chanteperdrix wrote: The following patch seems to do the trick. It makes the assumption that when compiling with -fomit-frame-pointer, we have one more register, so the R constraint will always be able to avoid choosing eax, and eax will be free for the muxcode, so that the compiler will not choose the m alternative. It works, indeed. Thank you Gilles. May this patch be backported to the stable branch? Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] gcc-4.6 issue
On 12/08/11 10:18, Daniele Nicolodi wrote: On 12/08/11 01:18, Gilles Chanteperdrix wrote: The following patch seems to do the trick. It makes the assumption that when compiling with -fomit-frame-pointer, we have one more register, so the R constraint will always be able to avoid choosing eax, and eax will be free for the muxcode, so that the compiler will not choose the m alternative. It works, indeed. Thank you Gilles. I've spoken to early. The patch does not work for the posix skin. Posix skin services return function not implemented errors when xenomai user space is compiled with the patch and gcc-4.6, they work just fine when compiled with gcc-4.4 (without the patch). Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Analogy: idx_write_subd field in a4l_desc_t
Hello, I'm using xenomai-head on a 2.6.38.8 kernel on x86 with a NI-6251 DAQ board. In this configuration the idx_write_subd field of the a4l_desc_t structure filled by a4l_open() is not set to the proper value but is set to NULL. In previous xanomai/analogy releases this was working properly. Has some initialization code been removed in the latest analogy drivers refactoring? Thank you. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy: idx_write_subd field in a4l_desc_t
On 01/10/11 00:03, Alexis Berlemont wrote:
I'm using xenomai-head on a 2.6.38.8 kernel on x86 with a NI-6251 DAQ
board. In this configuration the idx_write_subd field of the a4l_desc_t
structure filled by a4l_open() is not set to the proper value but is set
to NULL.
In previous xanomai/analogy releases this was working properly. Has some
initialization code been removed in the latest analogy drivers refactoring?
Yes. Formerly, on both sides (kernel and user), we used some
description fields (idx_read_subd and idx_write_subd) so as to quickly
identify default asynchronous input and output subdevices and to link
them with buffers (into which, input / output data are copied).
...
For API / ABI compatibility reasons, I waited a major release before
removing the fields idx_{read, write}_subd. I should have thought
twice before removing their initializations. I will fix that soon,
sorry.
Hello Alexis,
the rational of the change is clear, however having the field in the
structure, but with the wrong value is confusing, especially so because
the documentation does not mention that this field is deprecated and its
value should not be trusted.
I would remove the field altogether, or put back the initialization and
mention the deprecation in the documentation.
I implemented this change more than one year ago (here is on of the
many related commits 58ebd5b7efe0cc0ac1e82991d12125ce34dfeee3). That
was already present in 2.5. Which version were you formerly using?
I thought I was using Xenomai 2.5.6.
Cheers,
--
Daniele
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy: idx_write_subd field in a4l_desc_t
On 01/10/11 20:07, Gilles Chanteperdrix wrote:
For API / ABI compatibility reasons, I waited a major release before
removing the fields idx_{read, write}_subd. I should have thought
twice before removing their initializations. I will fix that soon,
sorry.
2.6 is a new major release, and not out yet, so, if you want to remove
something, it is still time.
If we are open to some partially backward incompatible changes I propose
to also change the meaning of the a4l_desc_t board_name field, to really
be the board name, instead of the driver name. I find this information
more useful when enumerating devices in my setup.
I would also like to propose a patch to demote some messages, logged at
each interrupt, in the ni_pcimio driver from the info to the debug
level. I run continuous acquisitions and those kernel messages pollute
my syslog with not much added value and fill my disc with redundant
information.
Cheers,
--
Daniele
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy: idx_write_subd field in a4l_desc_t
On 04/10/11 13:17, Gilles Chanteperdrix wrote:
If you want things merged, send the patches, they will reach
xenomai-head repository through Alex.
Of course. Here is my simple patch.
Thank you. Cheers,
--
Daniele
From 6944fe7465e1eb614cf9db3eccceb93d77bf95f1 Mon Sep 17 00:00:00 2001
From: Daniele Nicolodi nicol...@science.unitn.it
Date: Tue, 4 Oct 2011 14:49:27 +0200
Subject: [PATCH 1/3] analogy: demote some messages logged in mio_common
driver code to debug level
---
.../analogy/national_instruments/mio_common.c | 24 ++--
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/ksrc/drivers/analogy/national_instruments/mio_common.c b/ksrc/drivers/analogy/national_instruments/mio_common.c
index a68cf2c..4303934 100644
--- a/ksrc/drivers/analogy/national_instruments/mio_common.c
+++ b/ksrc/drivers/analogy/national_instruments/mio_common.c
@@ -835,8 +835,8 @@ static void handle_a_interrupt(a4l_dev_t *dev,
if((subd-flags A4L_SUBD_TYPES) == A4L_SUBD_UNUSED)
return;
- a4l_info(dev, ni_mio_common: interrupt:
- a_status=%04x ai_mite_status=%08x\n,status, ai_mite_status);
+ a4l_dbg(1, drv_dbg, dev, ni_mio_common: interrupt:
+ a_status=%04x ai_mite_status=%08x\n,status, ai_mite_status);
ni_mio_print_status_a(status);
#if (defined(CONFIG_XENO_DRIVERS_ANALOGY_NI_MITE) || \
@@ -847,9 +847,9 @@ static void handle_a_interrupt(a4l_dev_t *dev,
if (ai_mite_status ~(CHSR_INT | CHSR_LINKC | CHSR_DONE | CHSR_MRDY |
CHSR_DRDY | CHSR_DRQ1 | CHSR_DRQ0 | CHSR_ERROR |
CHSR_SABORT | CHSR_XFERR | CHSR_LxERR_mask)) {
- a4l_info(dev, ni_mio_common: interrupt:
- unknown mite interrupt, ack! (ai_mite_status=%08x)\n,
- ai_mite_status);
+ a4l_dbg(1, drv_dbg, dev, ni_mio_common: interrupt:
+ unknown mite interrupt, ack! (ai_mite_status=%08x)\n,
+ ai_mite_status);
a4l_buf_evt(subd, A4L_BUF_ERROR);
}
#endif /* CONFIG_XENO_DRIVERS_ANALOGY_NI_MITE */
@@ -858,8 +858,8 @@ static void handle_a_interrupt(a4l_dev_t *dev,
if (status (AI_Overrun_St | AI_Overflow_St | AI_SC_TC_Error_St |
AI_SC_TC_St | AI_START1_St)) {
if (status == 0x) {
- a4l_info(dev, ni_mio_common: interrupt:
- a_status=0x. Card removed?\n);
+ a4l_dbg(1, drv_dbg, dev, ni_mio_common: interrupt:
+a_status=0x. Card removed?\n);
/* TODO: we probably aren't even running a command now,
so it's a good idea to be careful.
we should check the transfer status */
@@ -869,8 +869,8 @@ static void handle_a_interrupt(a4l_dev_t *dev,
}
if (status (AI_Overrun_St | AI_Overflow_St |
AI_SC_TC_Error_St)) {
- a4l_info(dev, ni_mio_common: interrupt:
- ai error a_status=%04x\n, status);
+ a4l_dbg(1, drv_dbg, dev, ni_mio_common: interrupt:
+ai error a_status=%04x\n, status);
ni_mio_print_status_a(status);
shutdown_ai_command(subd);
@@ -881,7 +881,7 @@ static void handle_a_interrupt(a4l_dev_t *dev,
return;
}
if (status AI_SC_TC_St) {
- a4l_info(dev, ni_mio_common: SC_TC interrupt\n);
+ a4l_dbg(1, drv_dbg, dev, ni_mio_common: SC_TC interrupt\n);
if (!devpriv-ai_continuous) {
shutdown_ai_command(subd);
}
@@ -914,8 +914,8 @@ static void handle_a_interrupt(a4l_dev_t *dev,
status = devpriv-stc_readw(dev, AI_Status_1_Register);
if (status Interrupt_A_St)
- a4l_info(dev, ni_mio_common: interrupt:
- didn't clear interrupt? status=0x%x\n, status);
+ a4l_dbg(1, drv_dbg, dev, ni_mio_common: interrupt:
+ didn't clear interrupt? status=0x%x\n, status);
}
static void ack_b_interrupt(a4l_dev_t *dev, unsigned short b_status)
--
1.7.6.3
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] patch: build: restore building of xeno-config man page
Hello, here is a simple patch to the build system to restore the building of xeno-config man page. It got lost some time ago. I noticed that it was missing because debian packages failed to build. Cheers, -- Daniele From 958e522ea5aad32e9cd227e572be4ffbaff73ef9 Mon Sep 17 00:00:00 2001 From: Daniele Nicolodi nicol...@science.unitn.it Date: Tue, 4 Oct 2011 14:59:49 +0200 Subject: build: restore building of xeno-config man page --- doc/man/Makefile.am |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/man/Makefile.am b/doc/man/Makefile.am index c2f753a..18f2bd1 100644 --- a/doc/man/Makefile.am +++ b/doc/man/Makefile.am @@ -1,4 +1,4 @@ -man1_MANS = clocktest.man cyclictest.man irqbench.man irqloop.man \ - klatency.man latency.man rtcanconfig.man \ - rtcanrecv.man rtcansend.man switchbench.man \ +man1_MANS = xeno-config.man clocktest.man cyclictest.man irqbench.man \ + irqloop.man klatency.man latency.man rtcanconfig.man \ + rtcanrecv.man rtcansend.man switchbench.man \ switchtest.man xeno.man -- 1.7.6.3 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] patch: testsuite: add missing include
Hello, the posix/leks regression test in the test suite failed to build on debian testing due to a missing include. The attached patch fixes the problem. Cheers, -- Daniele From 795a866c1080987ec772492fec223db8d1a2a4a8 Mon Sep 17 00:00:00 2001 From: Daniele Nicolodi nicol...@science.unitn.it Date: Tue, 4 Oct 2011 15:14:44 +0200 Subject: testsuite: add missing include --- src/testsuite/regression/posix/leaks.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/testsuite/regression/posix/leaks.c b/src/testsuite/regression/posix/leaks.c index 7326572..6c8cee9 100644 --- a/src/testsuite/regression/posix/leaks.c +++ b/src/testsuite/regression/posix/leaks.c @@ -1,6 +1,6 @@ #include stdio.h #include stdlib.h - +#include signal.h #include unistd.h #include pthread.h #include fcntl.h -- 1.7.6.3 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH xenomai-head] testsuite: fix compiler error 'SIGALRM, undeclared'
On 12/10/11 12:59, Gilles Chanteperdrix wrote: On 10/12/2011 11:44 AM, Wolfgang Grandegger wrote: Signed-off-by: Wolfgang Grandegger w...@denx.de --- src/testsuite/regression/posix/leaks.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/testsuite/regression/posix/leaks.c b/src/testsuite/regression/posix/leaks.c index 7326572..f9dd34d 100644 --- a/src/testsuite/regression/posix/leaks.c +++ b/src/testsuite/regression/posix/leaks.c @@ -6,6 +6,7 @@ #include fcntl.h #include sys/mman.h #include semaphore.h +#include signal.h #include mqueue.h #include nucleus/heap.h Applied, thanks. Wans't that the same error fixed by commit aa44db3d5ee270c3b92a1017f7c136ffa1e2cc4d? Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
