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
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
m
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
> signalin
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
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
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 exp
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
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
>>&g
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
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.
>
&
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 descript
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
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
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 termina
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
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!
Th
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 n
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()
>
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
>
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
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 w
ERROR("analogy mmap");
return rv;
}
if (argc > 2) {
DEBUG("BUG!");
} else {
/* unmap subdevice buffer */
munmap(map, bufsize);
}
/* close file descriptor */
a4l_close(&dsc);
exi
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
htt
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
with
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 ex
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 20
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 stil
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
ht
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
>>
>>
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
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
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
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" constrai
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. Ha
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 xa
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
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
rom: 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/
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
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/posi
40 matches
Mail list logo
