[Xenomai-core] libvxworks not built
Hi I am at revision 464 of the xenomai trunk and wanted to build UVM for vxworks. The following libraries built fine: libuvm.a libpsos.a libuitron.a libvrtx.a libnucleus.a but the library I am most intrested in is missing? Does anybody has any clue? The XENO-parts of my .config are: CONFIG_XENOMAI=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y CONFIG_XENO_OPT_PIPE=y CONFIG_XENO_OPT_PIPE_NRDEV=32 CONFIG_XENO_OPT_SYS_HEAPSZ=128 # CONFIG_XENO_OPT_ISHIELD is not set CONFIG_XENO_OPT_STATS=y # CONFIG_XENO_OPT_DEBUG is not set CONFIG_XENO_OPT_WATCHDOG=y # CONFIG_XENO_OPT_SCALABLE_SCHED is not set # CONFIG_XENO_HW_FPU is not set CONFIG_XENO_HW_PERIODIC_TIMER=y CONFIG_XENO_HW_TIMER_LATENCY=0 CONFIG_XENO_HW_SCHED_LATENCY=0 CONFIG_XENO_SKIN_NATIVE=y CONFIG_XENO_OPT_NATIVE_REGISTRY=y CONFIG_XENO_OPT_NATIVE_REGISTRY_NRSLOTS=512 CONFIG_XENO_OPT_NATIVE_PIPE=y CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096 CONFIG_XENO_OPT_NATIVE_SEM=y CONFIG_XENO_OPT_NATIVE_EVENT=y CONFIG_XENO_OPT_NATIVE_MUTEX=y CONFIG_XENO_OPT_NATIVE_COND=y CONFIG_XENO_OPT_NATIVE_QUEUE=y CONFIG_XENO_OPT_NATIVE_HEAP=y CONFIG_XENO_OPT_NATIVE_ALARM=y CONFIG_XENO_OPT_NATIVE_MPS=y CONFIG_XENO_OPT_NATIVE_INTR=y # CONFIG_XENO_SKIN_POSIX is not set # CONFIG_XENO_SKIN_PSOS is not set # CONFIG_XENO_SKIN_UITRON is not set # CONFIG_XENO_SKIN_VRTX is not set # CONFIG_XENO_SKIN_VXWORKS is not set # CONFIG_XENO_SKIN_RTAI is not set CONFIG_XENO_SKIN_RTDM=y CONFIG_XENO_SKIN_UVM=y # CONFIG_XENO_DRIVERS_16550A is not set # CONFIG_XENO_DRIVERS_TIMERBENCH is not set The I configured xenomai like this /mnt/data.ng/hcu/kernel/xenomai/configure --prefix=/usr --enable-uvm --build=powerpc --host=powerpc-405-linux-gnu CFLAGS=-g PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/mnt/data.ng/hcu/tools/gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu/bin and let it build with DESTDIR=/mnt/data.ng/hcu/rootfs -k install PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/mnt/data.ng/hcu/tools/gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu/bin install Best regards -- Niklaus Giger
Re: [Xenomai-core] libvxworks not built
Niklaus Giger wrote: Hi I am at revision 464 of the xenomai trunk and wanted to build UVM for vxworks. The following libraries built fine: libuvm.a libpsos.a libuitron.a libvrtx.a libnucleus.a but the library I am most intrested in is missing? This should be fixed in revision 465. Thanks for reporting. -- Gilles Chanteperdrix.
Re: [Xenomai-core] [PATCH] shared irqs v.3
Hi Dmitry, Dmitry Adamushko wrote: Hi, here goes another implementation of shared irqs on the nucleus layer. I have conducted a few tests and it seems to work. The test example is attached. There were 2 main issues concerning synchronization: 1) xnintr_attach() vs. xnintr_detach() (and each of them vs. itself) The problem is that we can't use the nklock (nor any other lock + irq off) as Gilles pointed out. A possible solution: o something lick xnlock_get/put() There is no irqsave/restore -less interface of xnlock_get/put available. For pure locking scheme (without touching the irqs) the concept of _preemption_ (to prevent a thread from being preempted while in a locked section) must be introduced and, at the first glance, that would be quite difficult since it must be consistent across all domains (if only for the primary - that's easy). o rthal_critical_enter/exit() This one is used currently. 2) xnintr_attach/detach() vs. xnintr_irq_handler() The problem here is how to be sure that 1) the xnintr_shirq_t object is valid (when dynamically allocated) and 2) to be safe while iterating through the handlers list. Currently, 1) is allowed by the static xnintr_shirq_t xnshirqs[IPIPE_NR_IRQS]. Ok, it can be done lighter when a one-way-list is used instead of xnqueue_t. As lighter may mean that reducing the structure size also reduces the number of used cache lines, it might be a good idea. The additional complexity for entry removal is negligible. Beleive it or not, I have considered different ways to guarantee that a passed cookie param is valid (xnintr_detach() has not deleted it) and remains to be so while the xnintr_irq_handler() is running. And there are some obstacles there... I'll post them later if someone is interested since I'm short of time now :) ... I'm interested... There are a few ugly things in code, namely __IPIPE_NR_IRQS and definitions of rthal_critical_enter/exit(). I do understand the first issue but not what you mean with the second one. That code is compiled for the user-mode code also and the originals are not available. So consider it a temp solution for test purposes, I guess it's easily fixable. test/shirq.c - is a test module. SHIRQ_VECTOR must be the one used by Linux, e.g. I have used 12 that's used by the trackball device. I haven't tried your code yet, but in the preparation of a real scenario I stumbled over a problem in my serial driver regarding IRQ sharing: In case you want to use xeno_16550A for ISA devices with shared IRQs, an iteration over the list of registered handlers would be required /until/ no device reported that it handled something. This is required so that the IRQ line gets released for a while and system obtains a chance to detect a new /edge/ triggered IRQ - ISA oddity. That's the way most serial drivers work, but they do it internally. So the question arose for me if this edge-specific handling shouldn't be moved to the nucleus as well (so that I don't have to fix my 16550A ;)). Another optimisation idea, which I once also realised in my own shared IRQ wrapper, is to use specialised trampolines at the nucleus level, i.e. to not apply the full sharing logic with its locking and list iterations for non-shared IRQs. What do you think? Worth it? Might be when the ISA/edge handling adds further otherwise unneeded overhead. Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] rt_heap in userspace, heapsize
Hi, I made a small test with rt_heap_ in userspace, i think I understood the actual limitations of the userspace support. I used 1 as heapsize. Xenomai 2.1-RC2/x86. This should alloc the entire heap, according to the API documentation: rt_heap_create( ..., ..., 1, ... ) rt_heap_alloc( ..., 1, ..., ) - This call fails, but it should work Using heapsize 0 it works: rt_heap_create( ..., ..., 1, ... ) rt_heap_alloc( ..., 0, ..., ) rt_heap_inquire shows a heapsize of 12228 (IIRC). So, this would probably work (untested): rt_heap_create( ..., ..., 1, ... ) rt_heap_alloc( ..., 12228, ..., ) The 2228 bytes difference seems to be the space needed for the heap control structures. I think the following should be fixed: 1) rt_create_alloc should alter the heapsize the same as rt_heap_create does 2) rt_heap_inquire should return the _real_ heapsize thx kisda signature.asc Description: OpenPGP digital signature
[Xenomai-core] Re: [Xenomai-help] Scheduling while atomic
Jeroen Van den Keybus wrote: Gilles, Jan, The offending program is quite complex (several .c files and a considerable .h file tree) and involves 2 computers. However, I think I can narrow down the problem to concurrent access (from 2 Xenomai threads in 2nd domain) to the same Linux file descriptor for a TCP/IP connection. In order to rule this out, I have put RT_MUTEXes around the send() and recv() calls.However, I still received 'scheduling while atomic'. Further investigation, however, has shown that the mutexes seem to fail: rt_mutex_enquire() returns 0 or even -1 after acquisition of the lock. With this program, I didn't (yet) receive the 'scheduling...' error, but by increasing the task repetition rate, it should be a matter of (a long) time (both tasks arriving at a blocking write). I have compiled a program that represents the structure of the original program. Could you have a look and see if I'm not making a mistake here ? For proper following up, I've also attached the dmesg log asked for earlier by Jan. Looking at the message log, it seems xnshadow_harden is called at a point where irqs are disabled. But is there no other error before these scheduling while atomic messages ? If not, could you try and enable the nucleus debugging ? In case there is no error before the error messages, even with nucleus debugging activated, I attached a patch which breaks nklock and activates interrupts on xnshadow_harden entry and restore the caller state on xnshadow_harden exit. Could you test it and report if you still see the scheduling while atomic messages ? -- Gilles Chanteperdrix. Index: ksrc/nucleus/shadow.c === --- ksrc/nucleus/shadow.c (revision 464) +++ ksrc/nucleus/shadow.c (working copy) @@ -439,13 +439,17 @@ preemption. */ struct __gatekeeper *gk = gatekeeper[task_cpu(this_task)]; xnthread_t *thread = xnshadow_thread(this_task); +spl_t s; if (!thread) return -EPERM; +xnlock_get_irqsave(nklock, s); +xnlock_clear_irqon(nklock); + if (signal_pending(this_task) || down_interruptible(gk-sync)) /* Grab the request token. */ - return -ERESTARTSYS; +goto out_interrupted; xnltt_log_event(xeno_ev_primarysw,this_task-comm); @@ -495,6 +499,8 @@ thread-name, xnthread_user_pid(thread)); #endif /* CONFIG_XENO_OPT_DEBUG */ +out_interrupted: +xnlock_put_irqrestore(nklock, s); return -ERESTARTSYS; } } @@ -510,7 +516,7 @@ if (xnthread_signaled_p(thread)) xnpod_dispatch_signals(); -xnlock_clear_irqon(nklock); +xnlock_put_irqrestore(nklock, s); xnltt_log_event(xeno_ev_primary,thread-name);
[Xenomai-core] --enable-linux-build
Hi Gilles, I just tested your new build option. Maybe I'm using it the wrong way, but I stumbled over two quirks: o make install-nodev fails as it tries to install the kernel without being root. Actually, I only wanted to install the user space part, how can I do this separately? Or is this rather a use-case for the standard build? o On every make, the prepare-kernel script is executed - intentionally? Maybe it would be better to provide a dedicated make target to trigger the update. Thanks, Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] Re: --enable-linux-build
Jan Kiszka wrote: Hi Gilles, I just tested your new build option. Maybe I'm using it the wrong way, but I stumbled over two quirks: o make install-nodev fails as it tries to install the kernel without being root. Actually, I only wanted to install the user space part, how can I do this separately? Or is this rather a use-case for the standard build? I did not think about this case. Any idea of what would be better ? Not installing kernel when running make install-nodev ? Creating install-nokernel and install-nokernel-nodev targets ? o On every make, the prepare-kernel script is executed - intentionally? Maybe it would be better to provide a dedicated make target to trigger the update. prepare-kernel should be executed whenever any file or directory is added in the ksrc and include dirs. On my own machine, prepare-kernel is much shorter than the kernel build. So, I did not see this as an issue, but I am ready to accept any better solution. Maybe it could depend on maintainer mode ? Since the user-space will work automatically when adding a file or directory only if maintainer mode is enabled. -- Gilles Chanteperdrix.
Re: [Xenomai-core] rt_heap in userspace, heapsize [patch]
Hi again,
I looked at the sources now...
Am Tuesday 17 January 2006 14:57 schrieb Stefan Kisdaroczi:
Hi,
I made a small test with rt_heap_ in userspace,
i think I understood the actual limitations of the userspace support.
I used 1 as heapsize. Xenomai 2.1-RC2/x86.
This should alloc the entire heap, according to the API documentation:
rt_heap_create( ..., ..., 1, ... )
rt_heap_alloc( ..., 1, ..., ) - This call fails, but it should
work
API documentation: If the heap is shared, this value can be either zero, or
the same value given to rt_heap_create().
Looking at the code, calculating the right value can be tricky and would
depend on xeno-internals. rt_heap_inquire would be another way to get it.
Only accepting 0 would be less confusing. See (untested) patch as as
suggestion.
Using heapsize 0 it works:
rt_heap_create( ..., ..., 1, ... )
rt_heap_alloc( ..., 0, ..., )
rt_heap_inquire shows a heapsize of 12228 (IIRC).
So, this would probably work (untested):
rt_heap_create( ..., ..., 1, ... )
rt_heap_alloc( ..., 12228, ..., )
The 2228 bytes difference seems to be the space needed for the heap control
structures.
I think the following should be fixed:
1) rt_create_alloc should alter the heapsize the same as rt_heap_create
does
Makes no sense, after looking at the code.
2) rt_heap_inquire should return the _real_ heapsize
The real heap space can be bigger than the requested, so this can happen.
thx again
kisda
Index: include/native/heap.h
===
--- include/native/heap.h (Revision 465)
+++ include/native/heap.h (Arbeitskopie)
@@ -32,6 +32,9 @@
#define H_DMA0x100 /* Use memory suitable for DMA. */
#define H_SHARED 0x200 /* Use mappable shared memory. */
+/* Operation flags. */
+#define H_ALL0x0 /* Entire heap space. */
+
typedef struct rt_heap_info {
int nwaiters; /* ! Number of pending tasks. */
Index: ksrc/skins/native/heap.c
===
--- ksrc/skins/native/heap.c (Revision 465)
+++ ksrc/skins/native/heap.c (Arbeitskopie)
@@ -410,10 +410,9 @@
* from.
*
* @param size The requested size in bytes of the block. If the heap
- * is shared, this value can be either zero, or the same value given
- * to rt_heap_create(). In any case, the same block covering the
- * entire heap space will always be returned to all callers of this
- * service.
+ * is shared, H_ALL should be passed, as always the same block
+ * covering the entire heap space will be returned to all callers of
+ * this service.
*
* @param timeout The number of clock ticks to wait for a block of
* sufficient size to be available from a local heap (see
@@ -432,8 +431,7 @@
* @return 0 is returned upon success. Otherwise:
*
* - -EINVAL is returned if @a heap is not a heap descriptor, or @a
- * heap is shared (i.e. H_SHARED mode) and @a size is non-zero but
- * does not match the actual heap size passed to rt_heap_create().
+ * heap is shared (i.e. H_SHARED mode) and @a size is not H_ALL.
*
* - -EIDRM is returned if @a heap is a deleted heap descriptor.
*
@@ -503,12 +501,7 @@
if (!block)
{
- /* It's ok to pass zero for size here, since the requested
- size is implicitely the whole heap space; but if
- non-zero is given, it must match the actual heap
- size. */
-
- if (size 0 size != xnheap_size(heap-heap_base))
+ if (size != H_ALL)
{
err = -EINVAL;
goto unlock_and_exit;
pgplgPWGQzm4P.pgp
Description: PGP signature
