Hi, I've noted recently that my message has disappeared from the list. Is this
a bug, or it was
removed due the message size. If so, I'm sorry for the attachments, but I would
like to be
notified so that I could send another message without the attachments.
I would also be thankful If someone
Dmitry Adamushko escreveu:
Hi,
I think moderators may comment on your question. I just take an
opportunity to make a minor comment on the papers' content (a part of
it).
Thank you for that.
I read briefly only the part of your thesis regarding the Xenomai and
RTAI parts (page 4).
Frankly
.
Em Domingo 02 Julho 2006 10:29, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
I began to experience a problem since 2.6.17 when shutting down my PC.
I noticed the problem just after I recompiled my kernel to enable the SMI
workaround. I, then rebooted
Just informing... (in the hope of downloading a new adeos patch soon ;) )
Regards,
Rodrigo.
___
Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e
anti-spam realmente eficaz.
:
Rodrigo Rosenfeld Rosas wrote:
Just informing... (in the hope of downloading a new adeos patch soon ;) )
Go ahead and give it a try: my port for x86 to 2.6.16 was about fixing
4 failing hunks in the 2.6.15-patch (+ some minor namespace collision in
the posix skin).
Jan
Em Segunda 17 Abril 2006 13:26, Jim Cromie escreveu:
Q: How do I adequately stress-test ?
+
+A: xeno-test has a very basic workload generator, whose main virtue is
+that its nearly universally available.
+
+ dd if=/dev/zero if=/dev/null
You probably meant
dd if=/dev/zero of=/dev/null
don't
BTW, please, could someone confirm the rt_task_delete(NULL) bug in SVN?
Regards,
Rodrigo.
Index: ksrc/skins/native/queue.c
===
--- ksrc/skins/native/queue.c (revisão 923)
+++ ksrc/skins/native/queue.c (cópia de trabalho)
@@ -885,7
Hi Philippe,
I'm not sure of the exact SVN revision the problem arised, but my program used
to work 2 weeks ago, I guess, that was the last time I have tested it...
Since some revision not before 2 weeks ago, rt_task_delete(NULL) was causing
my program to crash.
Please, could you see what is
Hi Philippe,
I think I've found another bug on SVN. When trying to run the sigxcpu snippet
provided with Xenomai I received only the following lines:
Switched to secondary mode
Switched to secondary mode
Switched to secondary mode
...
The backtrace was not shown. Actually warn_upon_switch
Hi, I'm having huge delays in sending messages to these lists lately.
Does anybody know what could cause such behaviour?
BTW, about the message I sent yesterday (and that didn't arrive yet) about
manual sti/cli doesn't
need to be answered since I've already got the answer in the adeos.pdf
Em Domingo 26 Março 2006 06:49, Jan Kiszka escreveu:
...
Maybe derived a subset from the full V4L2 API is the way to go. But
let's wait if you discover other interface designs.
Actually, my priorities changed again... I'll need to finish (start actually)
an application using the camera in a
Em Segunda 20 Março 2006 21:24, Jan Kiszka escreveu:
...
Does your time allow to list the minimal generic services a RTDM video
capturing driver has to provide in a similar fashion like the serial or
the CAN profile? If it's mostly about copying existing Linux API specs,
feel free to just
Philippe Gerum wrote:
...
Given the description above, just that some skin might return either
nucleus ticks or corrected timestamps to the applications, which would
in turn do some arithmetics for converting values they got from the skin
between both scales internally, and mistakenly use the
Em Segunda 20 Março 2006 12:23, Philippe Gerum escreveu:
...
It's not a matter of dealing with users always doing The Right Thing,
but preferably preventing people from doing the wrong one.
But we then have two problems and there are tradeoffs here. In one hand we
want to avoid users from
Em Segunda 20 Março 2006 13:51, Philippe Gerum escreveu:
...
I think that you should try convincing Jan that rtdm_clock_tsc() might
be a good idea to provide, instead of tweaking rtdm_clock_read() in a
way which changes its underlying logic. ;o)
Yes, that is exactly what I want! :)
I don't see
Hi Jan and others interested.
I've finally got my driver in a usable condition. It lacks a lot of
functionalities yet, but it aplies to my needs.
I would like to propose a real-time video interface for using with RTDM.
For making it simple to port Linux applications to Xenomai, I tried to make
Em Segunda 20 Março 2006 21:24, Jan Kiszka escreveu:
...
You may want to have a look at this thread regarding poll/select and RT:
http://www.mail-archive.com/rtnet-users%40lists.sourceforge.net/msg00968.htm
I tried to. Not found. But I didn't give up so quicky. It was missing the
final 'l':
Jan Kiszka escreveu:
We discussed a lot about how to prevent the user shooting him/herself in
the knee with inter-tick timestamps, but I still think that
rtdm_clock_read_tsc() would even be worse in this regard.
What do you think abou this documentation:
This function is meant to be used in
Hi Jan, I liked your idea.
I'm finhishing a first version (very limited while conforming to V4L2)
framegrabber driver using RTDM and could write about it, but since I cannot
show the Data Translation specific code, I could not publish the driver
source code in any site. But I can still write
Em Terça 14 Março 2006 03:44, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu:
...
We would definitely need a good name for it,
rtdm_clock_read_ex(clock-id), rtdm_clock_read_tsc(),
rtdm_clock_read_monotonic()? I'm not going to break
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be independent
of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take
Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be independent
of the user's timer choice IMO.
And this is something
Em Terça 14 Março 2006 16:00, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution
I really tried to not answer this message and finish the endless thread you
mentioned, but I couldn't resist. ;) Maybe this will be the last post from my
own on this thread and will begin writing in the new thread. See below,
please.
Em Segunda 13 Março 2006 08:48, você escreveu:
...
Do you mean that rtdm_clock_read will always read a multiple of tickval
value? If so, I think it would be good to make it clear on its
documentation. Get system time isn't enough for getting this
information, IMHO.
Please have a look at the
.
Em Segunda 13 Março 2006 14:15, Rodrigo Rosenfeld Rosas escreveu:
Em Segunda 13 Março 2006 11:54, Rodrigo Rosenfeld Rosas escreveu:
I liked the note, but I would include another one:
When
Actually, I noted a minor typo error in the documentation:
of the this service should be of this service
Best Regards,
Rodrigo.
Em Segunda 13 Março 2006 14:58, Rodrigo Rosenfeld Rosas escreveu:
Sorry Jan, I was looking
Em Segunda 13 Março 2006 15:24, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Sorry Jan, I was looking at a different documentation. Now I read the
right one. It is good. But I didn't understand why didn't you keep the
latter note: The nucleus timer has to be started to obtain valid
Em Segunda 13 Março 2006 15:33, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Segunda 13 Março 2006 14:25, Gilles Chanteperdrix escreveu:
Jan Kiszka wrote:
Sometimes the result is Should be near 84000: 10, that is kind of
correct, since the tickval is 10, although I think
Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu:
...
We would definitely need a good name for it,
rtdm_clock_read_ex(clock-id), rtdm_clock_read_tsc(),
rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by
adding an argument (otherwise, I would have to fix too many
Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Hi Jan,
I'm still concerned about the future of RTDM and timer functions. I think
there should be some function for starting the timer manually, since the
automatic feature don't work great for RTDM drivers
Em Sexta 10 Março 2006 15:32, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Hi Jan,
I'm still concerned about the future of RTDM and timer functions. I
think there should be some function for starting
. That is the best list support I've ever seen.
Best Regards,
Rodrigo.
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Hi Philippe,
I disabled the kernel .config support, recompiled the kernel with latest ipipe
patch and rebooted my system (Xenomai configured as a module).
Then I
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Hi Jan,
Is there a way of knowing what was the src_addr or pptr data passed to
rtdm_mmap_to_user without using the vm_private_data struct? I mean, can I
obtain those information directly in the vma struct passed to the close
handler
Hi Jan,
Is there a way of knowing what was the src_addr or pptr data passed to
rtdm_mmap_to_user without using the vm_private_data struct? I mean, can I
obtain those information directly in the vma struct passed to the close
handler? If so, I could pass a more generic struct to vm_private and
Em Quarta 15 Fevereiro 2006 12:53, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
...
You cannot mmap before you know precisely for which user this should
take place.
Do you mean that if I use the 'current' and current-mm struct of the
driver, when
Em Terça 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
...
You cannot mmap before you know precisely for which user this should
take place.
Do you mean that if I use the 'current' and current-mm struct of the
driver, when mmaping, the user won't be able to use the returned pointer?
To mmap
Em Terça 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
...
You cannot mmap before you know precisely for which user this should
take place.
Do you mean that if I use the 'current' and current-mm struct of the
driver, when mmaping, the user won't be able to use the returned pointer?
To mmap
Em Terça 14 Fevereiro 2006 05:55, você escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above
Em Terça 14 Fevereiro 2006 05:55, você escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above.
Actually, all you need is some callback when the mapped memory block
...
I understand your concernings but I really don't think they are
relevant... This checks will be much faster then the procedure itself
and it would conform to normal munmap behaviour. From man page:
The address start must be a multiple of the page size. All pages
containing a part of the
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Hi Jan, it just happened once and I couldn't reproduce (I didn't want to
reproduce it too since I would need to restart my computer because the driver
wouldn't unload)...
When it happened I forgot to start the timer running the latency
...
I understand your concernings but I really don't think they are
relevant... This checks will be much faster then the procedure itself
and it would conform to normal munmap behaviour. From man page:
The address start must be a multiple of the page size. All pages
containing a part of the
Hi Jan, I started the tests and had problems on unloading the module.
I am probably doing something wrong but I think the driver shouldn't crash.
Probably it is missing some sanity checks on rtdm_munmap like
if (! (user_info user_info-mm))
return -EXXX;
I'll investigate the
45 matches
Mail list logo
