[Xenomai-core] Analogy a4l_ioctl_bufinfo() bug?
Hello. As reported in the xenomai-help mailing list I'm investigating why a4l_mmap() is not supported for the ni pcimio driver. Hacking on the driver I discovered that, apparently, the only problem in supporting mmap of the device buffer is in the a4l_ioctl_bufinfo() function. In my interpretation, this function does more than what it promises. >From the documentation it looks like it just has to return the current buffer size. However, if my understanding is correct, it also copies data to/from the hardware FIFO to the device buffer. It is unclear to me why this is necessary. In doing so it uses the __munge() function, around line 630 in buffer.h. This function in turns uses the driver specific munge function. In the case of the ni pcimio driver this function is ni_ai_munge16() in mio_common.c. This function expects to be called when a valid command has been sent to the subdevice, because it unconditionally deferences cmd->nb_chan, around line 1385. However, when the a4l_ioctl_bufinfo() function is called, there is no check that a valid command has been sent to the device, and generally it hasn't. This causes a kernel OOPS for trying to deference a NULL pointer. My hacky solution has been to introduce a check, with an early return, for a NULL cmd. I'm sure this is not the right solution. However, to solve the problem properly, I need to understand why a4l_ioctl_bufinfo() has to mess with the buffer data, when it is only interested into the buffer dimensions. Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Analogy a4l_fill_desc() bug
Hello. I found a bug in a4l_fill_desc(). If I call it on a descriptor obtained for an unattached device, the memory allocated for the sbdata descriptor field is corrupted in a bad way. When, after the failing a4l_fill_desc() call, I free() it, glibc complains about an "invalid next size" for the memory chunk. I'm on x86 architecture using kernel 2.6.30.10 with xenomai 2.5.1. Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] Experimenting with Analogy. Bugs found?
Hello, > 1. I setup an asynchronous acquisition. I then use a loop to > a4l_sys_read() the acquired data. When the acquisition command is over, > as configured with the .stop_src and .stop_arg in the command data > structure, the a4l_sys_read() returns an ENOENT error. The comedi way of > signaling the acquisition command end is to return 0, as is done for > files to signal the end of file. I think this is an API deficiency but I > haven't looked at how much work is to fix it. Looks like this has already been solved in the Alex's git tree. Thanks Simon for the suggestion of looking there for fixes. > 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. This is still a problem. Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
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] Analogy a4l_ioctl_bufinfo() bug?
Daniele Nicolodi wrote:
> Hello. As reported in the xenomai-help mailing list I'm investigating
> why a4l_mmap() is not supported for the ni pcimio driver. Hacking on the
> driver I discovered that, apparently, the only problem in supporting
> mmap of the device buffer is in the a4l_ioctl_bufinfo() function.
The atached patch solves the problem. My solution is to avoid to mess
with the subdevice buffer if a transmission is not occouring. This makes
ni pcimio driver work as expected. The second patch enables mmapping for
the ni pcimio driver.
Cheers,
--
Daniele
commit d0bbc69a106012a2152ff8ff8fe4897ae0c34bcd
Author: Daniele Nicolodi
Date: Wed Mar 17 15:24:22 2010 +0100
Fix a4i_ioctl_bufinfo to do not try to copy data from the subdevice buffer if a transfer is not occuring.
diff --git a/ksrc/drivers/analogy/buffer.c b/ksrc/drivers/analogy/buffer.c
index 0c66b4a..1a8acf7 100644
--- a/ksrc/drivers/analogy/buffer.c
+++ b/ksrc/drivers/analogy/buffer.c
@@ -560,6 +560,14 @@ int a4l_ioctl_bufinfo(a4l_cxt_t * cxt, void *arg)
buf = dev->transfer.bufs[info.idx_subd];
+ /* If a transfer is not occuring, simply return buffer
+ informations, otherwise make the transfer progress */
+ if (! test_bit(A4L_TSF_BUSY,
+ &(dev->transfer.status[info.idx_subd]))) {
+ info.rw_count = 0;
+ goto a4l_ioctl_bufinfo_out;
+ }
+
ret = __handle_event(buf);
if (info.idx_subd == dev->transfer.idx_read_subd) {
@@ -621,6 +629,8 @@ int a4l_ioctl_bufinfo(a4l_cxt_t * cxt, void *arg)
buf->mng_count += tmp_cnt;
}
+a4l_ioctl_bufinfo_out:
+
/* Sets the buffer size */
info.buf_size = buf->size;
commit 230e1c7da63e2324e25ae9bf959f5c10d3d8c3ec
Author: Daniele Nicolodi
Date: Wed Mar 17 15:26:26 2010 +0100
Enable subdevice buffer mmapping for ni pcimio driver.
diff --git a/ksrc/drivers/analogy/national_instruments/mio_common.c b/ksrc/drivers/analogy/national_instruments/mio_common.c
index 1a39206..a51a3cd 100644
--- a/ksrc/drivers/analogy/national_instruments/mio_common.c
+++ b/ksrc/drivers/analogy/national_instruments/mio_common.c
@@ -4913,7 +4913,7 @@ int ni_E_init(a4l_dev_t *dev)
a4l_dbg(1, drv_dbg, dev,
"mio_common: AI: %d channels\n", boardtype.n_adchan);
- subd->flags = A4L_SUBD_AI | A4L_SUBD_CMD;
+ subd->flags = A4L_SUBD_AI | A4L_SUBD_CMD | A4L_SUBD_MMAP;
subd->rng_desc = ni_range_lkup[boardtype.gainlkup];
subd->chan_desc = kmalloc(sizeof(a4l_chdesc_t) +
@@ -4981,7 +4981,7 @@ int ni_E_init(a4l_dev_t *dev)
if (boardtype.ao_fifo_depth) {
- subd->flags |= A4L_SUBD_CMD;
+ subd->flags |= A4L_SUBD_CMD | A4L_SUBD_MMAP;
subd->do_cmd = &ni_ao_cmd;
subd->cmd_mask = &mio_ao_cmd_mask;
subd->do_cmdtest = &ni_ao_cmdtest;
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Analogy: cancel ongoing commands when a device is closed
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. 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: > 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
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 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... Now I just have to find where the carpenters broke the cable that brings internet connection to my lab and fix it... :-( 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] Bug in a4l_get_chan
Alexis Berlemont wrote: > Daniele Nicolodi wrote: >> 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). > However, with your accurate description, I think this patch should > solve the problem: Thanks Alexis. Your patch has the same effect as the one I cracked up myself after some head scratching. It is more readable than mine, however my solution avoids the iteration and the multiple checks for A4L_CHAN_GLOBAL_CHANDESC and can be a little more efficient, but i think compiler optimizations should make it a non noticeable difference. Cheers, PS: Looks like free.fr does not like my university SMTP server. I have difficulties in sending mails to your account there. -- 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
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
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 t
[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] Analogy a4l_fill_desc() bug
On 11/03/10 18:12, Daniele Nicolodi wrote: > Hello. > > I found a bug in a4l_fill_desc(). If I call it on a descriptor obtained > for an unattached device, the memory allocated for the sbdata descriptor > field is corrupted in a bad way. When, after the failing a4l_fill_desc() > call, I free() it, glibc complains about an "invalid next size" for the > memory chunk. > > I'm on x86 architecture using kernel 2.6.30.10 with xenomai 2.5.1. This bug is still biting me... 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
[Xenomai-core] Analogy regressions in xenomai 2.5.5.1
Hello, I just installed xenomai 2.5.5 on a 2.6.35.7 kernel and I'm noticing serious regressions on analogy basic features: 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". 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. 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... 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
#include
#include
#include
#include
#include
#include
#include
/* 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
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
-/* 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
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:07, Gilles Chanteperdrix wrote: > On 08/11/2011 12:59 PM, Roland Stigge wrote: >> Hi, >> >> I remember the recent gcc 4.6 issue on this list, but unfortunately, >> didn't have much time for attention. Now, it found its way to the Debian >> package: http://bugs.debian.org/637425 >> >> I wonder if it is a compiler bug or Xenomai's. > > It looks like a xenomai bug due to the pseudo-signals implemented in > this branch. I have asked two persons which have this compiler to test > xenomai-head where these signals have been removed to confirm this > hypothesis, but received no answer as of today. Hello. 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. 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 : 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 4ffb: e8 98 d5 ff ff call 2598 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 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 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 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 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 5061: 8b 45 90mov-0x70(%ebp),%eax 5064: 39 f8 cmp%edi,%eax 5066: 73 02 jae506a 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 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 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 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 07 je 50c3 50bc: 8b 4d 90mov-0x70(%ebp),%ecx 50bf: 85 c9 test %ecx,%ecx 50c1: 75 4d jne5110 50c3: 83 c4 7cadd$0x7c
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
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 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 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 #include - +#include #include #include #include -- 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 >> --- >> 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 >> #include >> #include >> +#include >> #include >> >> #include > > 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
