[Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[roderik.wildenburg]

Sorry for asking again, but my question form June 7. wasn´t answered and I am not able to work it out by my own:
When I use a PPC-Kernel 2.4.25 with Xenomai 2.5.6 I get the message 
"Xenomai: mmap local sem heap: No such device or address" when I start the latency test (and other programs).

But the rtheap-Device exists (see below). Can anybody give me a short hint in which direction to search.
Is Xenomai 2.5.6 intend to work with Kernel 2.4. ?

Thank you in advance
Roderik 

-----------------------------------------
mrconfig:/fat/sbin # ll /dev/rtheap
crw-rw-rw-    1 root     root      10, 254 May 19 14:16 /dev/rtheap

mrconfig:/fat/sbin # strace ./latency
execve("./latency", ["./latency"], [/* 37 vars */]) = 0
uname({sys="Linux", node="mrconfig", ...}) = 0
:
:
:
access("/dev/rtheap", F_OK)             = 0
rt_sigaction(SIGILL, {0xff23cb8, [ILL], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGILL, {SIG_DFL}, {0xff23cb8, [ILL], SA_RESTART}, 8) = 0
open("/dev/rtheap", O_RDWR)             = 3
ioctl(3, 0, 0xc7dd9210)                 = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = -1 ENXIO (No such device or address)
close(3)                                = 0
dup(2)                                  = 3
fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 64), ...}) = 0
ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30016000
_llseek(3, 0, 0x7fffeac8, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
write(3, "Xenomai: mmap local sem heap: No"..., 56Xenomai: mmap local sem heap: No such device or address
) = 56
close(3)                                = 0
munmap(0x30016000, 4096)                = 0
exit(1)

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Tue, 2011-06-14 at 10:52 +0200, roderik.wildenburg@domain.hid
wrote:
> Sorry for asking again, but my question form June 7. wasn´t answered and I am not able to work it out by my own:
> When I use a PPC-Kernel 2.4.25 with Xenomai 2.5.6 I get the message 
> "Xenomai: mmap local sem heap: No such device or address" when I start the latency test (and other programs).
> 
> But the rtheap-Device exists (see below). Can anybody give me a short hint in which direction to search.
> Is Xenomai 2.5.6 intend to work with Kernel 2.4. ?
> 

Yes. I don't have the bandwidth avail to have a look at this ATM. I'll
try to this week.

> Thank you in advance
> Roderik 
> 
> -----------------------------------------
> mrconfig:/fat/sbin # ll /dev/rtheap
> crw-rw-rw-    1 root     root      10, 254 May 19 14:16 /dev/rtheap
> 
> mrconfig:/fat/sbin # strace ./latency
> execve("./latency", ["./latency"], [/* 37 vars */]) = 0
> uname({sys="Linux", node="mrconfig", ...}) = 0
> :
> :
> :
> access("/dev/rtheap", F_OK)             = 0
> rt_sigaction(SIGILL, {0xff23cb8, [ILL], SA_RESTART}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGILL, {SIG_DFL}, {0xff23cb8, [ILL], SA_RESTART}, 8) = 0
> open("/dev/rtheap", O_RDWR)             = 3
> ioctl(3, 0, 0xc7dd9210)                 = 0
> mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = -1 ENXIO (No such device or address)
> close(3)                                = 0
> dup(2)                                  = 3
> fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
> fstat64(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 64), ...}) = 0
> ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30016000
> _llseek(3, 0, 0x7fffeac8, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
> write(3, "Xenomai: mmap local sem heap: No"..., 56Xenomai: mmap local sem heap: No such device or address
> ) = 56
> close(3)                                = 0
> munmap(0x30016000, 4096)                = 0
> exit(1)
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[roderik.wildenburg]

[-- Attachment #1: Type: text/plain, Size: 4644 bytes --]

Perhaps this may help:
I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with printf and printk (see appended files) and this is the output:

1:mrconfig:~ # latency
2:xeno_init_private_heap
3:map_sem_heap syscall 0
4:xeno_map_heap open 3
5:xnheap_ioctl private data: 00000000
6:xeno_map_heap ioctl 0 handle 0xc7dd9210
7:xnheap_mmap 00000000 00000000
8:xeno_map_heap 0xffffffff
9:Xenomai: mmap local sem heap: No such device or address
10:mrconfig:~ #


It looks like (if I figured it out correctly) as if in function sem_heap.c->xeno_map_heap()  (which is called from xeno_init_privat_heap() via function map_sem_heap())  the ioctl-Call fails. 
xeno_map_heap() passes correctly an argument unequal NULL as third parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3. parameter arrives as NULL(line 5). This sets file->private_data to NULL which in turn lets xnheap_mmap() fail, as this function expects file->private_data != NULL (line7).
Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which outputs the error message " Xenomai: mmap local sem heap: No such device or address".
The one million dollar question is, why the 3. parameter of ioctl() mutates to NULL. Any idea?

If I can do anything else, let me know.

Roderik


> -----Ursprüngliche Nachricht-----
> Von: Philippe Gerum [mailto:rpm@xenomai.org]
> Gesendet: Dienstag, 14. Juni 2011 11:40
> An: Wildenburg, Roderik RAEK1 MRA
> Cc: xenomai@xenomai.org
> Betreff: Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> 
> On Tue, 2011-06-14 at 10:52 +0200, roderik.wildenburg@domain.hid
> wrote:
> > Sorry for asking again, but my question form June 7. wasn´t answered and I am
> not able to work it out by my own:
> > When I use a PPC-Kernel 2.4.25 with Xenomai 2.5.6 I get the message
> > "Xenomai: mmap local sem heap: No such device or address" when I start the
> latency test (and other programs).
> >
> > But the rtheap-Device exists (see below). Can anybody give me a short hint in
> which direction to search.
> > Is Xenomai 2.5.6 intend to work with Kernel 2.4. ?
> >
> 
> Yes. I don't have the bandwidth avail to have a look at this ATM. I'll
> try to this week.
> 
> > Thank you in advance
> > Roderik
> >
> > -----------------------------------------
> > mrconfig:/fat/sbin # ll /dev/rtheap
> > crw-rw-rw-    1 root     root      10, 254 May 19 14:16 /dev/rtheap
> >
> > mrconfig:/fat/sbin # strace ./latency
> > execve("./latency", ["./latency"], [/* 37 vars */]) = 0
> > uname({sys="Linux", node="mrconfig", ...}) = 0
> > :
> > :
> > :
> > access("/dev/rtheap", F_OK)             = 0
> > rt_sigaction(SIGILL, {0xff23cb8, [ILL], SA_RESTART}, {SIG_DFL}, 8) = 0
> > rt_sigaction(SIGILL, {SIG_DFL}, {0xff23cb8, [ILL], SA_RESTART}, 8) = 0
> > open("/dev/rtheap", O_RDWR)             = 3
> > ioctl(3, 0, 0xc7dd9210)                 = 0
> > mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = -1
> ENXIO (No such device or address)
> > close(3)                                = 0
> > dup(2)                                  = 3
> > fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
> > fstat64(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 64), ...}) = 0
> > ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> > mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30016000
> > _llseek(3, 0, 0x7fffeac8, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
> > write(3, "Xenomai: mmap local sem heap: No"..., 56Xenomai: mmap local sem
> heap: No such device or address
> > ) = 56
> > close(3)                                = 0
> > munmap(0x30016000, 4096)                = 0
> > exit(1)
> >
> > --------------------------------------------------------
> > manroland AG
> > Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> > Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul
> Steidle
> > Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht
> Offenbach HRB-Nr. 42592
> > USt-Ident-Nr. DE 250200933
> >
> >
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> 
> --
> Philippe.
> 
>

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

[-- Attachment #2: sem_heap.c --]
[-- Type: application/octet-stream, Size: 3817 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <unistd.h>
#include <pthread.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/mman.h>

#include <nucleus/vdso.h>
#include <nucleus/heap.h>
#include <asm/xenomai/syscall.h>
#include <asm-generic/bits/current.h>
#include "sem_heap.h"

#define PRIVATE 0
#define SHARED 1

struct xnvdso *nkvdso;

unsigned long xeno_sem_heap[2] = { 0, 0 };

static pthread_once_t init_private_heap = PTHREAD_ONCE_INIT;
static struct xnheap_desc private_hdesc;

void *xeno_map_heap(struct xnheap_desc *hd)
{
	unsigned long area;
	int fd, ret;
	void *addr;

	fd = open(XNHEAP_DEV_NAME, O_RDWR, 0);
printf("xeno_map_heap open %d\n",fd);
	if (fd < 0) {
		perror("Xenomai: open");
		return MAP_FAILED;
	}

	ret = ioctl(fd, 0, hd->handle);
printf("xeno_map_heap ioctl %d handle %p\n",ret,hd->handle);
	if (ret) {
		perror("Xenomai: ioctl");
		return MAP_FAILED;
	}

#ifdef CONFIG_MMU
	/* XXX: 2.5.x ABI preserved for MMU-enabled only. */
	area = 0;
#else
	area = hd->area;
#endif
	addr = mmap(NULL, hd->size, PROT_READ|PROT_WRITE,
		    MAP_SHARED, fd, area);
printf("xeno_map_heap %p\n",addr);
	close(fd);

	return addr;
}

static void *map_sem_heap(unsigned int shared)
{
	struct xnheap_desc global_hdesc, *hdesc;
	int ret;

	hdesc = shared ? &global_hdesc : &private_hdesc;
	ret = XENOMAI_SYSCALL2(__xn_sys_sem_heap, hdesc, shared);
printf("map_sem_heap syscall %d\n",ret);

	if (ret < 0) {
		errno = -ret;
		perror("Xenomai: sys_sem_heap");
		return MAP_FAILED;
	}

	return xeno_map_heap(hdesc);
}

static void unmap_on_fork(void)
{
	/*
	   Remapping the private heap must be done after the process has been
	   bound again, in order for it to have a new private heap,
	   Otherwise the global heap would be used instead, which
	   leads to unwanted effects.

	   On machines without an MMU, there is no such thing as fork.

	   As a protection against access to the heaps by the fastsync
	   code, we set up an inaccessible mapping where the heap was, so
	   that access to these addresses will cause a segmentation
	   fault.
	*/
#if defined(CONFIG_XENO_FASTSYNCH)
	void *addr = mmap((void *)xeno_sem_heap[PRIVATE],
			  private_hdesc.size, PROT_NONE,
			  MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
	if (addr != (void *)xeno_sem_heap[PRIVATE])
#endif /* CONFIG_XENO_FASTSYNCH */
		munmap((void *)xeno_sem_heap[PRIVATE], private_hdesc.size);
	xeno_sem_heap[PRIVATE] = 0UL;
	init_private_heap = PTHREAD_ONCE_INIT;
}

static void xeno_init_vdso(void)
{
	xnsysinfo_t sysinfo;
	int err;

	err = XENOMAI_SYSCALL2(__xn_sys_info, 0, &sysinfo);
	if (err < 0) {
		errno = -err;
		perror("Xenomai: sys_info failed");
		exit(EXIT_FAILURE);
	}

	nkvdso = (struct xnvdso *)(xeno_sem_heap[SHARED] + sysinfo.vdso);
	if (!xnvdso_test_feature(XNVDSO_FEAT_DROP_U_MODE))
		xeno_current_warn_old();
}

/* Will be called once at library loading time, and when re-binding
   after a fork */
static void xeno_init_private_heap(void)
{
  printf("xeno_init_private_heap \n");
	xeno_sem_heap[PRIVATE] = (unsigned long)map_sem_heap(PRIVATE);
	if (xeno_sem_heap[PRIVATE] == (unsigned long)MAP_FAILED) {
		perror("Xenomai: mmap local sem heap");
		exit(EXIT_FAILURE);
	}
}

/* Will be called only once, at library loading time. */
static void xeno_init_rest_once(void)
{
	pthread_atfork(NULL, NULL, unmap_on_fork);

	xeno_sem_heap[SHARED] = (unsigned long)map_sem_heap(SHARED);
	if (xeno_sem_heap[SHARED] == (unsigned long)MAP_FAILED) {
		perror("Xenomai: mmap global sem heap");
		exit(EXIT_FAILURE);
	}

	xeno_init_vdso();
}

void xeno_init_sem_heaps(void)
{
	static pthread_once_t init_rest_once = PTHREAD_ONCE_INIT;

	pthread_once(&init_private_heap, &xeno_init_private_heap);
	pthread_once(&init_rest_once, &xeno_init_rest_once);
}

[-- Attachment #3: heap.c --]
[-- Type: application/octet-stream, Size: 40318 bytes --]

/*!\file
 * \brief Dynamic memory allocation services.
 * \author Philippe Gerum
 *
 * Copyright (C) 2001,2002,2003 Philippe Gerum <rpm@xenomai.org>.
 *
 * Xenomai is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published
 * by the Free Software Foundation; either version 2 of the License,
 * or (at your option) any later version.
 *
 * Xenomai is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with Xenomai; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
 * 02111-1307, USA.
 *
 * \ingroup heap
 */

/*!
 * \ingroup nucleus
 * \defgroup heap Dynamic memory allocation services.
 *
 * Dynamic memory allocation services.
 *
 * The implementation of the memory allocator follows the algorithm
 * described in a USENIX 1988 paper called "Design of a General
 * Purpose Memory Allocator for the 4.3BSD Unix Kernel" by Marshall
 * K. McKusick and Michael J. Karels. You can find it at various
 * locations on the net, including
 * http://docs.FreeBSD.org/44doc/papers/kernmalloc.pdf.  A minor
 * variation allows this implementation to have 'extendable' heaps
 * when needed, with multiple memory extents providing autonomous page
 * address spaces.
 *
 * The data structures hierarchy is as follows:
 *
 * <tt> @verbatim
HEAP {
     block_buckets[]
     extent_queue -------+
}                        |
			 V
		      EXTENT #1 {
			     {static header}
			     page_map[npages]
			     page_array[npages][pagesize]
		      } -+
			 |
			 |
			 V
		      EXTENT #n {
			     {static header}
			     page_map[npages]
			     page_array[npages][pagesize]
		      }
@endverbatim </tt>
 *
 *@{*/

#include <stdarg.h>
#include <nucleus/pod.h>
#include <nucleus/thread.h>
#include <nucleus/heap.h>
#include <nucleus/assert.h>
#include <asm/xenomai/bits/heap.h>

xnheap_t kheap;		/* System heap */
EXPORT_SYMBOL_GPL(kheap);

#if CONFIG_XENO_OPT_SYS_STACKPOOLSZ > 0
xnheap_t kstacks;	/* Private stack pool */
#endif

static DEFINE_XNQUEUE(heapq);	/* Heap list for /proc reporting */
static unsigned long heapq_rev;

static void init_extent(xnheap_t *heap, xnextent_t *extent)
{
	caddr_t freepage;
	int n, lastpgnum;

	inith(&extent->link);

	/* The page area starts right after the (aligned) header. */
	extent->membase = (caddr_t) extent + heap->hdrsize;
	lastpgnum = heap->npages - 1;

	/* Mark each page as free in the page map. */
	for (n = 0, freepage = extent->membase;
	     n < lastpgnum; n++, freepage += heap->pagesize) {
		*((caddr_t *) freepage) = freepage + heap->pagesize;
		extent->pagemap[n].type = XNHEAP_PFREE;
		extent->pagemap[n].bcount = 0;
	}

	*((caddr_t *) freepage) = NULL;
	extent->pagemap[lastpgnum].type = XNHEAP_PFREE;
	extent->pagemap[lastpgnum].bcount = 0;
	extent->memlim = freepage + heap->pagesize;

	/* The first page starts the free list of a new extent. */
	extent->freelist = extent->membase;
}

/*
 */

/*!
 * \fn xnheap_init(xnheap_t *heap,void *heapaddr,u_long heapsize,u_long pagesize)
 * \brief Initialize a memory heap.
 *
 * Initializes a memory heap suitable for time-bounded allocation
 * requests of dynamic memory.
 *
 * @param heap The address of a heap descriptor which will be used to
 * store the allocation data.  This descriptor must always be valid
 * while the heap is active therefore it must be allocated in
 * permanent memory.
 *
 * @param heapaddr The address of the heap storage area. All
 * allocations will be made from the given area in time-bounded
 * mode. Since additional extents can be added to a heap, this
 * parameter is also known as the "initial extent".
 *
 * @param heapsize The size in bytes of the initial extent pointed at
 * by @a heapaddr. @a heapsize must be a multiple of pagesize and
 * lower than 16 Mbytes. @a heapsize must be large enough to contain a
 * dynamically-sized internal header. The following formula gives the
 * size of this header:\n
 *
 * H = heapsize, P=pagesize, M=sizeof(struct pagemap), E=sizeof(xnextent_t)\n
 * hdrsize = ((H - E) * M) / (M + 1)\n
 *
 * This value is then aligned on the next 16-byte boundary. The
 * routine xnheap_overhead() computes the corrected heap size
 * according to the previous formula.
 *
 * @param pagesize The size in bytes of the fundamental memory page
 * which will be used to subdivide the heap internally. Choosing the
 * right page size is important regarding performance and memory
 * fragmentation issues, so it might be a good idea to take a look at
 * http://docs.FreeBSD.org/44doc/papers/kernmalloc.pdf to pick the
 * best one for your needs. In the current implementation, pagesize
 * must be a power of two in the range [ 8 .. 32768 ] inclusive.
 *
 * @return 0 is returned upon success, or one of the following error
 * codes:
 *
 * - -EINVAL is returned whenever a parameter is invalid.
 *
 * Environments:
 *
 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Kernel-based task
 * - User-space task
 *
 * Rescheduling: never.
 */

int xnheap_init(xnheap_t *heap,
		void *heapaddr, u_long heapsize, u_long pagesize)
{
	unsigned cpu, nr_cpus = xnarch_num_online_cpus();
	u_long hdrsize, shiftsize, pageshift;
	xnextent_t *extent;
	spl_t s;

	/*
	 * Perform some parametrical checks first.
	 * Constraints are:
	 * PAGESIZE must be >= 2 ** MINLOG2.
	 * PAGESIZE must be <= 2 ** MAXLOG2.
	 * PAGESIZE must be a power of 2.
	 * HEAPSIZE must be large enough to contain the static part of an
	 * extent header.
	 * HEAPSIZE must be a multiple of PAGESIZE.
	 * HEAPSIZE must be lower than XNHEAP_MAXEXTSZ.
	 */

	if ((pagesize < (1 << XNHEAP_MINLOG2)) ||
	    (pagesize > (1 << XNHEAP_MAXLOG2)) ||
	    (pagesize & (pagesize - 1)) != 0 ||
	    heapsize <= sizeof(xnextent_t) ||
	    heapsize > XNHEAP_MAXEXTSZ || (heapsize & (pagesize - 1)) != 0)
		return -EINVAL;

	/*
	 * Determine the page map overhead inside the given extent
	 * size. We need to reserve 4 bytes in a page map for each
	 * page which is addressable into this extent. The page map is
	 * itself stored in the extent space, right after the static
	 * part of its header, and before the first allocatable page.
	 * pmapsize = (heapsize - sizeof(xnextent_t)) / pagesize *
	 * sizeof(struct xnpagemap). The overall header size is:
	 * static_part + pmapsize rounded to the minimum alignment
	 * size.
	*/
	hdrsize = xnheap_internal_overhead(heapsize, pagesize);

	/* Compute the page shiftmask from the page size (i.e. log2 value). */
	for (pageshift = 0, shiftsize = pagesize;
	     shiftsize > 1; shiftsize >>= 1, pageshift++)
		;	/* Loop */

	heap->pagesize = pagesize;
	heap->pageshift = pageshift;
	heap->extentsize = heapsize;
	heap->hdrsize = hdrsize;
	heap->npages = (heapsize - hdrsize) >> pageshift;

	/*
	 * An extent must contain at least two addressable pages to cope
	 * with allocation sizes between pagesize and 2 * pagesize.
	 */
	if (heap->npages < 2)
		return -EINVAL;

	heap->ubytes = 0;
	heap->maxcont = heap->npages * pagesize;
	for (cpu = 0; cpu < nr_cpus; cpu++)
		heap->idleq[cpu] = NULL;
	inith(&heap->link);
	inith(&heap->stat_link);
	initq(&heap->extents);
	xnlock_init(&heap->lock);
	xnarch_init_heapcb(&heap->archdep);
	memset(heap->buckets, 0, sizeof(heap->buckets));
	extent = (xnextent_t *)heapaddr;
	init_extent(heap, extent);

	appendq(&heap->extents, &extent->link);

	snprintf(heap->label, sizeof(heap->label), "unlabeled @0x%p", heap);

	xnlock_get_irqsave(&nklock, s);
	appendq(&heapq, &heap->stat_link);
	heapq_rev++;
	xnlock_put_irqrestore(&nklock, s);

	xnarch_init_display_context(heap);

	return 0;
}
EXPORT_SYMBOL_GPL(xnheap_init);

/*!
 * \fn xnheap_set_label(xnheap_t *heap,const char *label,...)
 * \brief Set the heap's label string.
 *
 * Set the heap label that will be used in statistic outputs.
 *
 * @param heap The address of a heap descriptor.
 *
 * @param label Label string displayed in statistic outputs. This parameter
 * can be a format string, in which case succeeding parameters will be used
 * to resolve the final label.
 *
 * Environments:
 *
 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Kernel-based task
 * - User-space task
 *
 * Rescheduling: never.
 */

void xnheap_set_label(xnheap_t *heap, const char *label, ...)
{
	va_list args;
	spl_t s;

	va_start(args, label);

	xnlock_get_irqsave(&nklock, s);
	vsnprintf(heap->label, sizeof(heap->label), label, args);
	xnlock_put_irqrestore(&nklock, s);

	va_end(args);
}
EXPORT_SYMBOL_GPL(xnheap_set_label);

/*!
 * \fn void xnheap_destroy(xnheap_t *heap, void (*flushfn)(xnheap_t *heap, void *extaddr, u_long extsize, void *cookie), void *cookie)
 * \brief Destroys a memory heap.
 *
 * Destroys a memory heap.
 *
 * @param heap The descriptor address of the destroyed heap.
 *
 * @param flushfn If non-NULL, the address of a flush routine which
 * will be called for each extent attached to the heap. This routine
 * can be used by the calling code to further release the heap memory.
 *
 * @param cookie If @a flushfn is non-NULL, @a cookie is an opaque
 * pointer which will be passed unmodified to @a flushfn.
 *
 * Environments:
 *
 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Kernel-based task
 * - User-space task
 *
 * Rescheduling: never.
 */

void xnheap_destroy(xnheap_t *heap,
		    void (*flushfn)(xnheap_t *heap,
				    void *extaddr,
				    u_long extsize, void *cookie),
		    void *cookie)
{
	xnholder_t *holder;
	spl_t s;

	xnlock_get_irqsave(&nklock, s);
	removeq(&heapq, &heap->stat_link);
	heapq_rev++;
	xnlock_put_irqrestore(&nklock, s);

	if (!flushfn)
		return;

	xnlock_get_irqsave(&heap->lock, s);

	while ((holder = getq(&heap->extents)) != NULL) {
		xnlock_put_irqrestore(&heap->lock, s);
		flushfn(heap, link2extent(holder), heap->extentsize, cookie);
		xnlock_get_irqsave(&heap->lock, s);
	}

	xnlock_put_irqrestore(&heap->lock, s);
}
EXPORT_SYMBOL_GPL(xnheap_destroy);

/*
 * get_free_range() -- Obtain a range of contiguous free pages to
 * fulfill an allocation of 2 ** log2size.  The caller must have
 * acquired the heap lock.
 */

static caddr_t get_free_range(xnheap_t *heap, u_long bsize, int log2size)
{
	caddr_t block, eblock, freepage, lastpage, headpage, freehead = NULL;
	u_long pagenum, pagecont, freecont;
	xnholder_t *holder;
	xnextent_t *extent;

	holder = getheadq(&heap->extents);

	while (holder != NULL) {
		extent = link2extent(holder);
		freepage = extent->freelist;

		while (freepage != NULL) {
			headpage = freepage;
			freecont = 0;

			/*
			 * Search for a range of contiguous pages in
			 * the free page list of the current
			 * extent. The range must be 'bsize' long.
			 */
			do {
				lastpage = freepage;
				freepage = *((caddr_t *) freepage);
				freecont += heap->pagesize;
			}
			while (freepage == lastpage + heap->pagesize
			       && freecont < bsize);

			if (freecont >= bsize) {
				/*
				 * Ok, got it. Just update the free
				 * page list, then proceed to the next
				 * step.
				 */
				if (headpage == extent->freelist)
					extent->freelist =
					    *((caddr_t *) lastpage);
				else
					*((caddr_t *) freehead) =
					    *((caddr_t *) lastpage);

				goto splitpage;
			}

			freehead = lastpage;
		}
		holder = nextq(&heap->extents, holder);
	}

	return NULL;

      splitpage:

	/* At this point, headpage is valid and points to the first page
	   of a range of contiguous free pages larger or equal than
	   'bsize'. */

	if (bsize < heap->pagesize) {
		/* If the allocation size is smaller than the standard page
		   size, split the page in smaller blocks of this size,
		   building a free list of free blocks. */

		for (block = headpage, eblock =
		     headpage + heap->pagesize - bsize; block < eblock;
		     block += bsize)
			*((caddr_t *) block) = block + bsize;

		*((caddr_t *) eblock) = NULL;
	} else
		*((caddr_t *) headpage) = NULL;

	pagenum = (headpage - extent->membase) >> heap->pageshift;

	/*
	 * Update the page map.  If log2size is non-zero (i.e. bsize
	 * <= 2 * pagesize), store it in the first page's slot to
	 * record the exact block size (which is a power of
	 * two). Otherwise, store the special marker XNHEAP_PLIST,
	 * indicating the start of a block whose size is a multiple of
	 * the standard page size, but not necessarily a power of two.
	 * In any case, the following pages slots are marked as
	 * 'continued' (PCONT).
	 */

	extent->pagemap[pagenum].type = log2size ? : XNHEAP_PLIST;
	extent->pagemap[pagenum].bcount = 1;

	for (pagecont = bsize >> heap->pageshift; pagecont > 1; pagecont--) {
		extent->pagemap[pagenum + pagecont - 1].type = XNHEAP_PCONT;
		extent->pagemap[pagenum + pagecont - 1].bcount = 0;
	}

	return headpage;
}

/*!
 * \fn void *xnheap_alloc(xnheap_t *heap, u_long size)
 * \brief Allocate a memory block from a memory heap.
 *
 * Allocates a contiguous region of memory from an active memory heap.
 * Such allocation is guaranteed to be time-bounded.
 *
 * @param heap The descriptor address of the heap to get memory from.
 *
 * @param size The size in bytes of the requested block. Sizes lower
 * or equal to the page size are rounded either to the minimum
 * allocation size if lower than this value, or to the minimum
 * alignment size if greater or equal to this value. In the current
 * implementation, with MINALLOC = 8 and MINALIGN = 16, a 7 bytes
 * request will be rounded to 8 bytes, and a 17 bytes request will be
 * rounded to 32.
 *
 * @return The address of the allocated region upon success, or NULL
 * if no memory is available from the specified heap.
 *
 * Environments:
 *
 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Interrupt service routine
 * - Kernel-based task
 * - User-space task
 *
 * Rescheduling: never.
 */

void *xnheap_alloc(xnheap_t *heap, u_long size)
{
	xnholder_t *holder;
	xnextent_t *extent;
	int log2size, ilog;
	u_long pagenum;
	caddr_t block;
	u_long bsize;
	spl_t s;

	if (size == 0)
		return NULL;

	if (size <= heap->pagesize)
		/* Sizes lower or equal to the page size are rounded either to
		   the minimum allocation size if lower than this value, or to
		   the minimum alignment size if greater or equal to this
		   value. In other words, with MINALLOC = 8 and MINALIGN = 16,
		   a 7 bytes request will be rounded to 8 bytes, and a 17
		   bytes request will be rounded to 32. */
	{
		if (size <= XNHEAP_MINALIGNSZ)
			size =
			    (size + XNHEAP_MINALLOCSZ -
			     1) & ~(XNHEAP_MINALLOCSZ - 1);
		else
			size =
			    (size + XNHEAP_MINALIGNSZ -
			     1) & ~(XNHEAP_MINALIGNSZ - 1);
	} else
		/* Sizes greater than the page size are rounded to a multiple
		   of the page size. */
		size = (size + heap->pagesize - 1) & ~(heap->pagesize - 1);

	/* It becomes more space efficient to directly allocate pages from
	   the free page list whenever the requested size is greater than
	   2 times the page size. Otherwise, use the bucketed memory
	   blocks. */

	if (likely(size <= heap->pagesize * 2)) {
		/* Find the first power of two greater or equal to the rounded
		   size. The log2 value of this size is also computed. */

		for (bsize = (1 << XNHEAP_MINLOG2), log2size = XNHEAP_MINLOG2;
		     bsize < size; bsize <<= 1, log2size++)
			;	/* Loop */

		ilog = log2size - XNHEAP_MINLOG2;

		xnlock_get_irqsave(&heap->lock, s);

		block = heap->buckets[ilog].freelist;

		if (block == NULL) {
			block = get_free_range(heap, bsize, log2size);
			if (block == NULL)
				goto release_and_exit;
			if (bsize <= heap->pagesize)
				heap->buckets[ilog].fcount += (heap->pagesize >> log2size) - 1;
		} else {
			if (bsize <= heap->pagesize)
				--heap->buckets[ilog].fcount;

			for (holder = getheadq(&heap->extents), extent = NULL;
			     holder != NULL; holder = nextq(&heap->extents, holder)) {
				extent = link2extent(holder);
				if ((caddr_t) block >= extent->membase &&
				    (caddr_t) block < extent->memlim)
					break;
			}
			XENO_ASSERT(NUCLEUS, extent != NULL,
				    xnpod_fatal("Cannot determine source extent for block %p (heap %p)?!",
						block, heap);
				);
			pagenum = ((caddr_t) block - extent->membase) >> heap->pageshift;
			++extent->pagemap[pagenum].bcount;
		}

		heap->buckets[ilog].freelist = *((caddr_t *) block);
		heap->ubytes += bsize;
	} else {
		if (size > heap->maxcont)
			return NULL;

		xnlock_get_irqsave(&heap->lock, s);

		/* Directly request a free page range. */
		block = get_free_range(heap, size, 0);

		if (block)
			heap->ubytes += size;
	}

      release_and_exit:

	xnlock_put_irqrestore(&heap->lock, s);

	return block;
}
EXPORT_SYMBOL_GPL(xnheap_alloc);

/*!
 * \fn int xnheap_test_and_free(xnheap_t *heap,void *block,int (*ckfn)(void *block))
 * \brief Test and release a memory block to a memory heap.
 *
 * Releases a memory region to the memory heap it was previously
 * allocated from. Before the actual release is performed, an optional
 * user-defined can be invoked to check for additional criteria with
 * respect to the request consistency.
 *
 * @param heap The descriptor address of the heap to release memory
 * to.
 *
 * @param block The address of the region to be returned to the heap.
 *
 * @param ckfn The address of a user-supplied verification routine
 * which is to be called after the memory address specified by @a
 * block has been checked for validity. The routine is expected to
 * proceed to further consistency checks, and either return zero upon
 * success, or non-zero upon error. In the latter case, the release
 * process is aborted, and @a ckfn's return value is passed back to
 * the caller of this service as its error return code. @a ckfn must
 * not trigger the rescheduling procedure either directly or
 * indirectly.
 *
 * @return 0 is returned upon success, or -EINVAL is returned whenever
 * the block is not a valid region of the specified heap. Additional
 * return codes can also be defined locally by the @a ckfn routine.
 *
 * Environments:
 *
 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Interrupt service routine
 * - Kernel-based task
 * - User-space task
 *
 * Rescheduling: never.
 */

int xnheap_test_and_free(xnheap_t *heap, void *block, int (*ckfn) (void *block))
{
	caddr_t freepage, lastpage, nextpage, tailpage, freeptr, *tailptr;
	int log2size, npages, err, nblocks, xpage, ilog;
	u_long pagenum, pagecont, boffset, bsize;
	xnextent_t *extent = NULL;
	xnholder_t *holder;
	spl_t s;

	xnlock_get_irqsave(&heap->lock, s);

	/* Find the extent from which the returned block is
	   originating. */

	for (holder = getheadq(&heap->extents);
	     holder != NULL; holder = nextq(&heap->extents, holder)) {
		extent = link2extent(holder);
		if ((caddr_t) block >= extent->membase &&
		    (caddr_t) block < extent->memlim)
			break;
	}

	if (!holder) {
		err = -EFAULT;
		goto unlock_and_fail;
	}

	/* Compute the heading page number in the page map. */
	pagenum = ((caddr_t) block - extent->membase) >> heap->pageshift;
	boffset =
	    ((caddr_t) block -
	     (extent->membase + (pagenum << heap->pageshift)));

	switch (extent->pagemap[pagenum].type) {
	case XNHEAP_PFREE:	/* Unallocated page? */
	case XNHEAP_PCONT:	/* Not a range heading page? */

	      bad_block:
		err = -EINVAL;

	      unlock_and_fail:

		xnlock_put_irqrestore(&heap->lock, s);
		return err;

	case XNHEAP_PLIST:

		if (ckfn && (err = ckfn(block)) != 0)
			goto unlock_and_fail;

		npages = 1;

		while (npages < heap->npages &&
		       extent->pagemap[pagenum + npages].type == XNHEAP_PCONT)
			npages++;

		bsize = npages * heap->pagesize;

	free_page_list:

		/* Link all freed pages in a single sub-list. */

		for (freepage = (caddr_t) block,
		     tailpage = (caddr_t) block + bsize - heap->pagesize;
		     freepage < tailpage; freepage += heap->pagesize)
			*((caddr_t *) freepage) = freepage + heap->pagesize;

	free_pages:

		/* Mark the released pages as free in the extent's page map. */

		for (pagecont = 0; pagecont < npages; pagecont++)
			extent->pagemap[pagenum + pagecont].type = XNHEAP_PFREE;

		/* Return the sub-list to the free page list, keeping
		   an increasing address order to favor coalescence. */

		for (nextpage = extent->freelist, lastpage = NULL;
		     nextpage != NULL && nextpage < (caddr_t) block;
		     lastpage = nextpage, nextpage = *((caddr_t *) nextpage))
		  ;	/* Loop */

		*((caddr_t *) tailpage) = nextpage;

		if (lastpage)
			*((caddr_t *) lastpage) = (caddr_t) block;
		else
			extent->freelist = (caddr_t) block;
		break;

	default:

		log2size = extent->pagemap[pagenum].type;
		bsize = (1 << log2size);

		if ((boffset & (bsize - 1)) != 0)	/* Not a block start? */
			goto bad_block;

		if (ckfn && (err = ckfn(block)) != 0)
			goto unlock_and_fail;

		/*
		 * Return the page to the free list if we've just
		 * freed its last busy block. Pages from multi-page
		 * blocks are always pushed to the free list (bcount
		 * value for the heading page is always 1).
		 */

		ilog = log2size - XNHEAP_MINLOG2;

		if (likely(--extent->pagemap[pagenum].bcount > 0)) {
			/* Return the block to the bucketed memory space. */
			*((caddr_t *) block) = heap->buckets[ilog].freelist;
			heap->buckets[ilog].freelist = block;
			++heap->buckets[ilog].fcount;
			break;
		}

		npages = bsize >> heap->pageshift;

		if (unlikely(npages > 1))
			/*
			 * The simplest case: we only have a single
			 * block to deal with, which spans multiple
			 * pages. We just need to release it as a list
			 * of pages, without caring about the
			 * consistency of the bucket.
			 */
			goto free_page_list;

		freepage = extent->membase + (pagenum << heap->pageshift);
		block = freepage;
		tailpage = freepage;
		nextpage = freepage + heap->pagesize;
		nblocks = heap->pagesize >> log2size;
		heap->buckets[ilog].fcount -= (nblocks - 1);

		XENO_ASSERT(NUCLEUS, heap->buckets[ilog].fcount >= 0,
			    xnpod_fatal("free block count became negative (heap %p, log2=%d, fcount=%d)?!",
					heap, log2size, heap->buckets[ilog].fcount);
			);
		/*
		 * Easy case: all free blocks are laid on a single
		 * page we are now releasing. Just clear the bucket
		 * and bail out.
		 */

		if (likely(heap->buckets[ilog].fcount == 0)) {
			heap->buckets[ilog].freelist = NULL;
			goto free_pages;
		}

		/*
		 * Worst case: multiple pages are traversed by the
		 * bucket list. Scan the list to remove all blocks
		 * belonging to the freed page. We are done whenever
		 * all possible blocks from the freed page have been
		 * traversed, or we hit the end of list, whichever
		 * comes first.
		 */

		for (tailptr = &heap->buckets[ilog].freelist, freeptr = *tailptr, xpage = 1;
		     freeptr != NULL && nblocks > 0; freeptr = *((caddr_t *) freeptr)) {
			if (unlikely(freeptr < freepage || freeptr >= nextpage)) {
				if (unlikely(xpage)) { /* Limit random writes */
					*tailptr = freeptr;
					xpage = 0;
				}
				tailptr = (caddr_t *)freeptr;
			} else {
				--nblocks;
				xpage = 1;
			}
		}

		*tailptr = freeptr;
		goto free_pages;
	}

	heap->ubytes -= bsize;

	xnlock_put_irqrestore(&heap->lock, s);

	return 0;
}
EXPORT_SYMBOL_GPL(xnheap_test_and_free);

/*!
 * \fn int xnheap_free(xnheap_t *heap, void *block)
 * \brief Release a memory block to a memory heap.
 *
 * Releases a memory region to the memory heap it was previously
 * allocated from.
 *
 * @param heap The descriptor address of the heap to release memory
 * to.
 *
 * @param block The address of the region to be returned to the heap.
 *
 * @return 0 is returned upon success, or one of the following error
 * codes:
 *
 * - -EFAULT is returned whenever the memory address is outside the
 * heap address space.
 *
 * - -EINVAL is returned whenever the memory address does not
 * represent a valid block.
 *
 * Environments:
 *
 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Interrupt service routine
 * - Kernel-based task
 * - User-space task
 *
 * Rescheduling: never.
 */

int xnheap_free(xnheap_t *heap, void *block)
{
	return xnheap_test_and_free(heap, block, NULL);
}
EXPORT_SYMBOL_GPL(xnheap_free);

/*!
 * \fn int xnheap_extend(xnheap_t *heap, void *extaddr, u_long extsize)
 * \brief Extend a memory heap.
 *
 * Add a new extent to an existing memory heap.
 *
 * @param heap The descriptor address of the heap to add an extent to.
 *
 * @param extaddr The address of the extent memory.
 *
 * @param extsize The size of the extent memory (in bytes). In the
 * current implementation, this size must match the one of the initial
 * extent passed to xnheap_init().
 *
 * @return 0 is returned upon success, or -EINVAL is returned if
 * @a extsize differs from the initial extent's size.
 *
 * Environments:
 *
 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Interrupt service routine
 * - Kernel-based task
 * - User-space task
 *
 * Rescheduling: never.
 */

int xnheap_extend(xnheap_t *heap, void *extaddr, u_long extsize)
{
	xnextent_t *extent = (xnextent_t *)extaddr;
	spl_t s;

	if (extsize != heap->extentsize)
		return -EINVAL;

	init_extent(heap, extent);
	xnlock_get_irqsave(&heap->lock, s);
	appendq(&heap->extents, &extent->link);
	xnlock_put_irqrestore(&heap->lock, s);

	return 0;
}
EXPORT_SYMBOL_GPL(xnheap_extend);

/*!
 * \fn int xnheap_schedule_free(xnheap_t *heap, void *block, xnholder_t *link)
 * \brief Schedule a memory block for release.
 *
 * This routine records a block for later release by
 * xnheap_finalize_free(). This service is useful to lazily free
 * blocks of heap memory when immediate release is not an option,
 * e.g. when active references are still pending on the object for a
 * short time after the call. xnheap_finalize_free() is expected to be
 * eventually called by the client code at some point in the future
 * when actually freeing the idle objects is deemed safe.
 *
 * @param heap The descriptor address of the heap to release memory
 * to.
 *
 * @param block The address of the region to be returned to the heap.
 *
 * @param link The address of a link member, likely but not
 * necessarily within the released object, which will be used by the
 * heap manager to hold the block in the queue of idle objects.
 *
 * Environments:
 *
 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Interrupt service routine
 * - Kernel-based task
 * - User-space task
 *
 * Rescheduling: never.
 */

void xnheap_schedule_free(xnheap_t *heap, void *block, xnholder_t *link)
{
	unsigned cpu;
	spl_t s;

	xnlock_get_irqsave(&heap->lock, s);
	/* Hack: we only need a one-way linked list for remembering the
	   idle objects through the 'next' field, so the 'last' field of
	   the link is used to point at the beginning of the freed
	   memory. */
	cpu = xnarch_current_cpu();
	link->last = (xnholder_t *)block;
	link->next = heap->idleq[cpu];
	heap->idleq[cpu] = link;
	xnlock_put_irqrestore(&heap->lock, s);
}
EXPORT_SYMBOL_GPL(xnheap_schedule_free);

void xnheap_finalize_free_inner(xnheap_t *heap, int cpu)
{
	xnholder_t *holder;

	while ((holder = heap->idleq[cpu]) != NULL) {
		heap->idleq[cpu] = holder->next;
		xnheap_free(heap, holder->last);
	}
}
EXPORT_SYMBOL_GPL(xnheap_finalize_free_inner);

int xnheap_check_block(xnheap_t *heap, void *block)
{
	xnextent_t *extent = NULL;
	u_long pagenum, boffset;
	xnholder_t *holder;
	int ptype, err = 0;
	spl_t s;

	xnlock_get_irqsave(&heap->lock, s);

	/* Find the extent from which the checked block is
	   originating. */

	for (holder = getheadq(&heap->extents);
	     holder != NULL; holder = nextq(&heap->extents, holder)) {
		extent = link2extent(holder);
		if ((caddr_t) block >= extent->membase &&
		    (caddr_t) block < extent->memlim)
			break;
	}

	if (!holder)
		goto bad_block;

	/* Compute the heading page number in the page map. */
	pagenum = ((caddr_t) block - extent->membase) >> heap->pageshift;
	boffset =
	    ((caddr_t) block -
	     (extent->membase + (pagenum << heap->pageshift)));
	ptype = extent->pagemap[pagenum].type;

	if (ptype == XNHEAP_PFREE ||	/* Unallocated page? */
	    ptype == XNHEAP_PCONT)	/* Not a range heading page? */
  bad_block:
		err = -EINVAL;

	xnlock_put_irqrestore(&heap->lock, s);

	return err;
}
EXPORT_SYMBOL_GPL(xnheap_check_block);

#ifdef CONFIG_XENO_OPT_PERVASIVE

#include <asm/io.h>
#include <linux/miscdevice.h>
#include <linux/device.h>
#include <linux/vmalloc.h>
#include <linux/mm.h>
#include <linux/fs.h>
#include <linux/spinlock.h>

static DEFINE_XNQUEUE(kheapq);	/* Shared heap queue. */
static DEFINE_SPINLOCK(kheapq_lock);

static inline void *__alloc_and_reserve_heap(size_t size, int kmflags)
{
	unsigned long vaddr, vabase;
	void *ptr;

	/* Size must be page-aligned. */

	if ((kmflags & ~XNHEAP_GFP_NONCACHED) == 0) {
		if (kmflags == 0)
			ptr = vmalloc(size);
		else
			ptr = __vmalloc(size,
					GFP_KERNEL | __GFP_HIGHMEM,
					pgprot_noncached(PAGE_KERNEL));
		if (ptr == NULL)
			return NULL;

		vabase = (unsigned long)ptr;
		for (vaddr = vabase; vaddr < vabase + size; vaddr += PAGE_SIZE)
			SetPageReserved(vmalloc_to_page((void *)vaddr));
	} else {
		/*
		 * Otherwise, we have been asked for some kmalloc()
		 * space. Assume that we can wait to get the required memory.
		 */
		if (size <= KMALLOC_MAX_SIZE)
			ptr = kmalloc(size, kmflags | GFP_KERNEL);
		else
			ptr = (void *)__get_free_pages(kmflags | GFP_KERNEL,
						       get_order(size));
		if (ptr == NULL)
			return NULL;

		vabase = (unsigned long)ptr;
		for (vaddr = vabase; vaddr < vabase + size; vaddr += PAGE_SIZE)
			SetPageReserved(virt_to_page(vaddr));
	}

	return ptr;
}

static void __unreserve_and_free_heap(void *ptr, size_t size, int kmflags)
{
	unsigned long vaddr, vabase;

	/* Size must be page-aligned. */

	vabase = (unsigned long)ptr;

	if ((kmflags & ~XNHEAP_GFP_NONCACHED) == 0) {
		for (vaddr = vabase; vaddr < vabase + size; vaddr += PAGE_SIZE)
			ClearPageReserved(vmalloc_to_page((void *)vaddr));

		vfree(ptr);
	} else {
		for (vaddr = vabase; vaddr < vabase + size; vaddr += PAGE_SIZE)
			ClearPageReserved(virt_to_page(vaddr));

		if (size <= KMALLOC_MAX_SIZE)
			kfree(ptr);
		else
			free_pages((unsigned long)ptr, get_order(size));
	}
}

static void xnheap_vmopen(struct vm_area_struct *vma)
{
	xnheap_t *heap = vma->vm_private_data;

	spin_lock(&kheapq_lock);
	heap->archdep.numaps++;
	spin_unlock(&kheapq_lock);
}

static void xnheap_vmclose(struct vm_area_struct *vma)
{
	xnheap_t *heap = vma->vm_private_data;

	spin_lock(&kheapq_lock);

	if (--heap->archdep.numaps == 0 && heap->archdep.release) {
		removeq(&kheapq, &heap->link);
		spin_unlock(&kheapq_lock);
		__unreserve_and_free_heap(heap->archdep.heapbase,
					  xnheap_extentsize(heap),
					  heap->archdep.kmflags);
		heap->archdep.release(heap);
		return;
	}

	spin_unlock(&kheapq_lock);
}

static struct vm_operations_struct xnheap_vmops = {
	.open = &xnheap_vmopen,
	.close = &xnheap_vmclose
};

static int xnheap_open(struct inode *inode, struct file *file)
{
	file->private_data = NULL;
	return 0;
}

static inline struct xnheap *__validate_heap_addr(void *addr)
{
	struct xnheap *heap;
	struct xnholder *h;

	for (h = getheadq(&kheapq); h; h = nextq(&kheapq, h)) {
		heap = link2heap(h);
		if (heap == addr && heap->archdep.release == NULL)
			return heap;
	}

	return NULL;
}

static long xnheap_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
	file->private_data = (void *)arg;
	printk("xnheap_ioctl private data: %p\n", arg);
	return 0;
}

static int xnheap_mmap(struct file *file, struct vm_area_struct *vma)
{
	unsigned long offset, size, vaddr;
	struct xnheap *heap;
	int ret;
printk("xnheap_mmap %p %p\n",vma->vm_ops,file->private_data);
	if (vma->vm_ops != NULL || file->private_data == NULL)
		/* Caller should mmap() once for a given file instance, after
		   the ioctl() binding has been issued. */
		return -ENXIO;

	if ((vma->vm_flags & VM_WRITE) && !(vma->vm_flags & VM_SHARED))
		return -EINVAL;	/* COW unsupported. */

	spin_lock(&kheapq_lock);

	heap = __validate_heap_addr(file->private_data);
	if (heap == NULL) {
		spin_unlock(&kheapq_lock);
		return -EINVAL;
	}

	heap->archdep.numaps++;

	spin_unlock(&kheapq_lock);

	vma->vm_private_data = file->private_data;
	vma->vm_ops = &xnheap_vmops;
	size = vma->vm_end - vma->vm_start;
	ret = -ENXIO;

	if (countq(&heap->extents) > 1)
		/* Cannot map multi-extent heaps, we need the memory
		   area we map from to be contiguous. */
		goto deref_out;

	offset = vma->vm_pgoff << PAGE_SHIFT;
	vaddr = (unsigned long)xnheap_base_memory(heap);

#ifdef CONFIG_MMU
	/*
	 * offset is actually an offset from the start of the heap
	 * memory.
	 */
	if (offset + size > xnheap_extentsize(heap))
		goto deref_out;

	vaddr += offset;
	ret = -EAGAIN;
	if ((heap->archdep.kmflags & ~XNHEAP_GFP_NONCACHED) == 0) {
		unsigned long maddr = vma->vm_start;

		if (heap->archdep.kmflags == XNHEAP_GFP_NONCACHED)
			vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

		while (size > 0) {
			if (xnarch_remap_vm_page(vma, maddr, vaddr))
				goto deref_out;

			maddr += PAGE_SIZE;
			vaddr += PAGE_SIZE;
			size -= PAGE_SIZE;
		}
	} else if (xnarch_remap_io_page_range(file,vma,
					      vma->vm_start,
					      virt_to_phys((void *)vaddr),
					      size, vma->vm_page_prot))
		goto deref_out;

	xnarch_fault_range(vma);
#else /* !CONFIG_MMU */
	/*
	 * Despite the kernel sees a single backing device with direct
	 * mapping capabilities (/dev/rtheap), we do map different
	 * heaps through it, so we want a brand new mapping region for
	 * each of them. To this end, we must request mappings on
	 * non-overlapping areas. To make sure of this in the nommu
	 * case, we request mappings from offsets representing the
	 * start RAM address of the heap memory.
	 */
	if (offset + size > vaddr + xnheap_extentsize(heap))
		goto deref_out;

	if ((heap->archdep.kmflags & ~XNHEAP_GFP_NONCACHED) != 0 ||
	    heap->archdep.kmflags == XNHEAP_GFP_NONCACHED)
		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
#endif /* !CONFIG_MMU */

	return 0;

deref_out:
	xnheap_vmclose(vma);

	return ret;
}

#ifndef CONFIG_MMU
static unsigned long xnheap_get_unmapped_area(struct file *file,
					      unsigned long addr,
					      unsigned long len,
					      unsigned long pgoff,
					      unsigned long flags)
{
	unsigned long area, offset;
	struct xnheap *heap;
	int ret;

	spin_lock(&kheapq_lock);

	ret = -EINVAL;
	heap = __validate_heap_addr(file->private_data);
	if (heap == NULL)
		goto fail;

	area = (unsigned long)xnheap_base_memory(heap);
	offset = pgoff << PAGE_SHIFT;
	if (offset < area ||
	    offset + len > area + xnheap_extentsize(heap))
		goto fail;

	spin_unlock(&kheapq_lock);

	return offset;
fail:
	spin_unlock(&kheapq_lock);

	return (unsigned long)ret;
}
#else /* CONFIG_MMU */
#define xnheap_get_unmapped_area  NULL
#endif /* CONFIG_MMU */

int xnheap_init_mapped(xnheap_t *heap, u_long heapsize, int memflags)
{
	void *heapbase;
	int err;

	/* Caller must have accounted for internal overhead. */
	heapsize = xnheap_align(heapsize, PAGE_SIZE);

	if ((memflags & XNHEAP_GFP_NONCACHED)
	    && memflags != XNHEAP_GFP_NONCACHED)
		return -EINVAL;

	heapbase = __alloc_and_reserve_heap(heapsize, memflags);
	if (heapbase == NULL)
		return -ENOMEM;

	err = xnheap_init(heap, heapbase, heapsize, PAGE_SIZE);
	if (err) {
		__unreserve_and_free_heap(heapbase, heapsize, memflags);
		return err;
	}

	heap->archdep.kmflags = memflags;
	heap->archdep.heapbase = heapbase;
	heap->archdep.release = NULL;

	spin_lock(&kheapq_lock);
	appendq(&kheapq, &heap->link);
	spin_unlock(&kheapq_lock);

	return 0;
}

void xnheap_destroy_mapped(xnheap_t *heap,
			   void (*release)(struct xnheap *heap),
			   void __user *mapaddr)
{
	unsigned long len;
	spl_t s;

	/*
	 * Trying to unmap user memory without providing a release
	 * handler for deferred cleanup is a bug.
	 */
	XENO_ASSERT(NUCLEUS, mapaddr == NULL || release, /* nop */);

	xnlock_get_irqsave(&nklock, s);
	removeq(&heapq, &heap->stat_link);
	heapq_rev++;
	xnlock_put_irqrestore(&nklock, s);

	len = xnheap_extentsize(heap);

	/*
	 * If the caller has an active mapping on that heap, remove it
	 * now. Note that we don't want to run the release handler
	 * indirectly on top of vmclose() by calling do_munmap(); we
	 * just clear it so that we may fall down to the common
	 * epilogue in case no more mapping exists.
	 */
	if (mapaddr) {
		down_write(&current->mm->mmap_sem);
		heap->archdep.release = NULL;
		do_munmap(current->mm, (unsigned long)mapaddr, len);
		up_write(&current->mm->mmap_sem);
	}

	/*
	 * At that point, the caller dropped its mapping. Return if
	 * some mapping still remains on the same heap, arming the
	 * deferred release handler to clean it up via vmclose().
	 */
	spin_lock(&kheapq_lock);

	if (heap->archdep.numaps > 0) {
		/* The release handler is supposed to clean up the rest. */
		heap->archdep.release = release;
		spin_unlock(&kheapq_lock);
		XENO_ASSERT(NUCLEUS, release != NULL, /* nop */);
		return;
	}

	/*
	 * No more mapping, remove the heap from the global queue,
	 * unreserve its memory and release its descriptor if a
	 * cleanup handler is available. Note that we may allow the
	 * heap to linger in the global queue until all mappings have
	 * been removed, because __validate_heap_addr() will deny
	 * access to heaps pending a release.
	 */
	removeq(&kheapq, &heap->link);

	spin_unlock(&kheapq_lock);

	__unreserve_and_free_heap(heap->archdep.heapbase, len,
				  heap->archdep.kmflags);
	if (release)
		release(heap);
}

static struct file_operations xnheap_fops = {
	.owner = THIS_MODULE,
	.open = xnheap_open,
	.unlocked_ioctl = xnheap_ioctl,
	.mmap = xnheap_mmap,
	.get_unmapped_area = xnheap_get_unmapped_area
};

static struct miscdevice xnheap_dev = {
	XNHEAP_DEV_MINOR, "rtheap", &xnheap_fops
};

int xnheap_mount(void)
{
	return misc_register(&xnheap_dev);
}

void xnheap_umount(void)
{
	misc_deregister(&xnheap_dev);
}

#elif !defined(__XENO_SIM__) /* !CONFIG_XENO_OPT_PERVASIVE */
static void xnheap_free_extent(xnheap_t *heap,
			       void *extent, u_long size, void *cookie)
{
	xnarch_free_host_mem(extent, size);
}

int xnheap_init_mapped(xnheap_t *heap, u_long heapsize, int memflags)
{
	void *heapaddr;
	int ret;

	if ((memflags & XNHEAP_GFP_NONCACHED)
	    && memflags != XNHEAP_GFP_NONCACHED)
		return -EINVAL;

	heapaddr = xnarch_alloc_host_mem(heapsize);
	if (heapaddr) {
		ret = xnheap_init(heap, heapaddr, heapsize, XNHEAP_PAGE_SIZE);
		if (ret)
			xnarch_free_host_mem(heapaddr, heapsize);

		return ret;
	}

	return -ENOMEM;
}

void xnheap_destroy_mapped(xnheap_t *heap,
			   void (*release)(struct xnheap *heap),
			   void __user *mapaddr)
{
	xnheap_destroy(heap, &xnheap_free_extent, NULL);
}
#endif /* !CONFIG_XENO_OPT_PERVASIVE */

#ifdef CONFIG_PROC_FS

#include <linux/proc_fs.h>

static int heap_read_proc(char *page,
			  char **start,
			  off_t off, int count, int *eof, void *data)
{
	unsigned long rev;
	xnholder_t *entry;
	xnheap_t *heap;
	int len;
	spl_t s;

	if (!xnpod_active_p())
		return -ESRCH;

	xnlock_get_irqsave(&nklock, s);

restart:
	len = 0;

	entry = getheadq(&heapq);
	while (entry) {
		heap = container_of(entry, xnheap_t, stat_link);
		len += sprintf(page + len,
			       "size=%lu:used=%lu:pagesz=%lu  (%s)\n",
			       xnheap_usable_mem(heap),
			       xnheap_used_mem(heap),
			       xnheap_page_size(heap),
			       heap->label);

		rev = heapq_rev;

		xnlock_sync_irq(&nklock, s);

		if (heapq_rev != rev)
			goto restart;

		entry = nextq(&heapq, entry);
	}

	xnlock_put_irqrestore(&nklock, s);

	len -= off;
	if (len <= off + count)
		*eof = 1;
	*start = page + off;
	if (len > count)
		len = count;
	if (len < 0)
		len = 0;

	return len;
}

void xnheap_init_proc(void)
{
	rthal_add_proc_leaf("heap", &heap_read_proc, NULL, NULL,
			    rthal_proc_root);
}

void xnheap_cleanup_proc(void)
{
	remove_proc_entry("heap", rthal_proc_root);
}

#endif /* CONFIG_PROC_FS */

EXPORT_SYMBOL_GPL(xnheap_init_mapped);
EXPORT_SYMBOL_GPL(xnheap_destroy_mapped);

/*@}*/

[-- Attachment #4: mmaplocalsemheapfail.txt --]
[-- Type: text/plain, Size: 339 bytes --]

src/common/sem_heap.c                     ksrc/nucleus/heap.c
xeno_init_private_heap()
map_sem_heap(PRIVATE)
xeno_map_heap(private_hdesc)
  ioctl(,,hd->handle!=NULL)          -->    xnheap_ioctl(,,NULL) ==> file->private_data == NULL
  addr=mmap()                        -->    xnheap_mmap(,file->private_data==NULL)  -->  return(-ENIXIO)

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Tue, 2011-06-14 at 14:47 +0200, roderik.wildenburg@domain.hid
wrote:
> Perhaps this may help:
> I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with printf and printk (see appended files) and this is the output:
> 
> 1:mrconfig:~ # latency
> 2:xeno_init_private_heap
> 3:map_sem_heap syscall 0
> 4:xeno_map_heap open 3
> 5:xnheap_ioctl private data: 00000000
> 6:xeno_map_heap ioctl 0 handle 0xc7dd9210
> 7:xnheap_mmap 00000000 00000000
> 8:xeno_map_heap 0xffffffff
> 9:Xenomai: mmap local sem heap: No such device or address
> 10:mrconfig:~ #
> 
> 
> It looks like (if I figured it out correctly) as if in function sem_heap.c->xeno_map_heap()  (which is called from xeno_init_privat_heap() via function map_sem_heap())  the ioctl-Call fails. 
> xeno_map_heap() passes correctly an argument unequal NULL as third parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3. parameter arrives as NULL(line 5). This sets file->private_data to NULL which in turn lets xnheap_mmap() fail, as this function expects file->private_data != NULL (line7).
> Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which outputs the error message " Xenomai: mmap local sem heap: No such device or address".
> The one million dollar question is, why the 3. parameter of ioctl() mutates to NULL. Any idea?
> 
> If I can do anything else, let me know.
> 

You will need these patches to run linux 2.4.25 over 2.5.6. The first
one fixes the ioctl() issue.
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=c2a24b90667e12d0614e5d8442dba74f137f9d4d
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=bebc2a8e6b430c99041800330dc6061665371d90

Note: the switch test does not seem to be running correctly on my
icecube (albeit the latency one does), somehow linux reschedule events
get lost. For this reason, I would not consider the current state as
being production-grade.

> Roderik
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Philippe Gerum [mailto:rpm@xenomai.org]
> > Gesendet: Dienstag, 14. Juni 2011 11:40
> > An: Wildenburg, Roderik RAEK1 MRA
> > Cc: xenomai@xenomai.org
> > Betreff: Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> > 
> > On Tue, 2011-06-14 at 10:52 +0200, roderik.wildenburg@domain.hid
> > wrote:
> > > Sorry for asking again, but my question form June 7. wasn´t answered and I am
> > not able to work it out by my own:
> > > When I use a PPC-Kernel 2.4.25 with Xenomai 2.5.6 I get the message
> > > "Xenomai: mmap local sem heap: No such device or address" when I start the
> > latency test (and other programs).
> > >
> > > But the rtheap-Device exists (see below). Can anybody give me a short hint in
> > which direction to search.
> > > Is Xenomai 2.5.6 intend to work with Kernel 2.4. ?
> > >
> > 
> > Yes. I don't have the bandwidth avail to have a look at this ATM. I'll
> > try to this week.
> > 
> > > Thank you in advance
> > > Roderik
> > >
> > > -----------------------------------------
> > > mrconfig:/fat/sbin # ll /dev/rtheap
> > > crw-rw-rw-    1 root     root      10, 254 May 19 14:16 /dev/rtheap
> > >
> > > mrconfig:/fat/sbin # strace ./latency
> > > execve("./latency", ["./latency"], [/* 37 vars */]) = 0
> > > uname({sys="Linux", node="mrconfig", ...}) = 0
> > > :
> > > :
> > > :
> > > access("/dev/rtheap", F_OK)             = 0
> > > rt_sigaction(SIGILL, {0xff23cb8, [ILL], SA_RESTART}, {SIG_DFL}, 8) = 0
> > > rt_sigaction(SIGILL, {SIG_DFL}, {0xff23cb8, [ILL], SA_RESTART}, 8) = 0
> > > open("/dev/rtheap", O_RDWR)             = 3
> > > ioctl(3, 0, 0xc7dd9210)                 = 0
> > > mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = -1
> > ENXIO (No such device or address)
> > > close(3)                                = 0
> > > dup(2)                                  = 3
> > > fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
> > > fstat64(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 64), ...}) = 0
> > > ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> > > mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30016000
> > > _llseek(3, 0, 0x7fffeac8, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
> > > write(3, "Xenomai: mmap local sem heap: No"..., 56Xenomai: mmap local sem
> > heap: No such device or address
> > > ) = 56
> > > close(3)                                = 0
> > > munmap(0x30016000, 4096)                = 0
> > > exit(1)
> > >
> > > --------------------------------------------------------
> > > manroland AG
> > > Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> > > Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul
> > Steidle
> > > Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht
> > Offenbach HRB-Nr. 42592
> > > USt-Ident-Nr. DE 250200933
> > >
> > >
> > > _______________________________________________
> > > Xenomai-help mailing list
> > > Xenomai-help@domain.hid
> > > https://mail.gna.org/listinfo/xenomai-help
> > 
> > --
> > Philippe.
> > 
> >
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933

-- 
Philippe.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Gilles Chanteperdrix]

On 06/18/2011 10:50 AM, Philippe Gerum wrote:
> On Tue, 2011-06-14 at 14:47 +0200, roderik.wildenburg@domain.hid
> wrote:
>> Perhaps this may help:
>> I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with printf and printk (see appended files) and this is the output:
>>
>> 1:mrconfig:~ # latency
>> 2:xeno_init_private_heap
>> 3:map_sem_heap syscall 0
>> 4:xeno_map_heap open 3
>> 5:xnheap_ioctl private data: 00000000
>> 6:xeno_map_heap ioctl 0 handle 0xc7dd9210
>> 7:xnheap_mmap 00000000 00000000
>> 8:xeno_map_heap 0xffffffff
>> 9:Xenomai: mmap local sem heap: No such device or address
>> 10:mrconfig:~ #
>>
>>
>> It looks like (if I figured it out correctly) as if in function sem_heap.c->xeno_map_heap()  (which is called from xeno_init_privat_heap() via function map_sem_heap())  the ioctl-Call fails. 
>> xeno_map_heap() passes correctly an argument unequal NULL as third parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3. parameter arrives as NULL(line 5). This sets file->private_data to NULL which in turn lets xnheap_mmap() fail, as this function expects file->private_data != NULL (line7).
>> Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which outputs the error message " Xenomai: mmap local sem heap: No such device or address".
>> The one million dollar question is, why the 3. parameter of ioctl() mutates to NULL. Any idea?
>>
>> If I can do anything else, let me know.
>>
> 
> You will need these patches to run linux 2.4.25 over 2.5.6. The first
> one fixes the ioctl() issue.
> http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=c2a24b90667e12d0614e5d8442dba74f137f9d4d
> http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=bebc2a8e6b430c99041800330dc6061665371d90
> 
> Note: the switch test does not seem to be running correctly on my
> icecube (albeit the latency one does), somehow linux reschedule events
> get lost. For this reason, I would not consider the current state as
> being production-grade.

How do you see that reschedule events are lost? Does this happen also on
other systems?

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Sat, 2011-06-18 at 15:44 +0200, Gilles Chanteperdrix wrote:
> On 06/18/2011 10:50 AM, Philippe Gerum wrote:
> > On Tue, 2011-06-14 at 14:47 +0200, roderik.wildenburg@domain.hid
> > wrote:
> >> Perhaps this may help:
> >> I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with printf and printk (see appended files) and this is the output:
> >>
> >> 1:mrconfig:~ # latency
> >> 2:xeno_init_private_heap
> >> 3:map_sem_heap syscall 0
> >> 4:xeno_map_heap open 3
> >> 5:xnheap_ioctl private data: 00000000
> >> 6:xeno_map_heap ioctl 0 handle 0xc7dd9210
> >> 7:xnheap_mmap 00000000 00000000
> >> 8:xeno_map_heap 0xffffffff
> >> 9:Xenomai: mmap local sem heap: No such device or address
> >> 10:mrconfig:~ #
> >>
> >>
> >> It looks like (if I figured it out correctly) as if in function sem_heap.c->xeno_map_heap()  (which is called from xeno_init_privat_heap() via function map_sem_heap())  the ioctl-Call fails. 
> >> xeno_map_heap() passes correctly an argument unequal NULL as third parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3. parameter arrives as NULL(line 5). This sets file->private_data to NULL which in turn lets xnheap_mmap() fail, as this function expects file->private_data != NULL (line7).
> >> Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which outputs the error message " Xenomai: mmap local sem heap: No such device or address".
> >> The one million dollar question is, why the 3. parameter of ioctl() mutates to NULL. Any idea?
> >>
> >> If I can do anything else, let me know.
> >>
> > 
> > You will need these patches to run linux 2.4.25 over 2.5.6. The first
> > one fixes the ioctl() issue.
> > http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=c2a24b90667e12d0614e5d8442dba74f137f9d4d
> > http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=bebc2a8e6b430c99041800330dc6061665371d90
> > 
> > Note: the switch test does not seem to be running correctly on my
> > icecube (albeit the latency one does), somehow linux reschedule events
> > get lost. For this reason, I would not consider the current state as
> > being production-grade.
> 
> How do you see that reschedule events are lost?

The pace of the supposedly 1sec periodic display stabilizes only when
other processes run in the background and becomes erratic when the
switch test is running alone, whilst the system does not seem to lose
its idea of time. Additionally, signals do not seem to make their way to
the shadows upon ^C. I did not track the issue in depth though, so at
this stage I'm speculating.

>  Does this happen also on
> other systems?
> 

Can't tell, I'm not using 2.5.x that much these days. I did not see any
issue during the sh4 port, which seems to exclude 2.6.x from the
potential victims.

Guts feeling is that this might be specific to 2.4 kernels.

-- 
Philippe.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[roderik.wildenburg]

I confirm that switchtest runs (nearly) perfectly on PPC-Kernel 2.6.34 with Xenomai 2.5.6. The only anomaly I could see is a "collapse" of the number of context switches exactly every 7 seconds by 2% (see below).  Is this worth to pay attention to? (No other Xenomai-Task is running except for a watchdog task with a period of 500ms) 
On the opposite, switchtest runs erratic on PPC-2.4.25 with Xenomai 2.5.6 as you already mentioned: The number of context switches is much smaller then (only about 2%) with  PPC-2.6.34 and fluctuate very much (see below).
Do you think you will find some spare time to fix this Problem?

Roderik


Xenomai 2.5.6 on PPC-2.6.34:
RTH|ctx switches|-------total
RTD|        4347|     7290193
RTD|        4347|     7294540
RTD|        4347|     7298887
RTD|        4347|     7303234
RTD|        4282|     7307516
RTD|        4345|     7311861
RTD|        4345|     7316206
RTD|        4347|     7320553
RTD|        4347|     7324900
RTD|        4347|     7329247
RTD|        4347|     7333594
RTD|        4282|     7337876
RTD|        4345|     7342221
RTD|        4345|     7346566
RTD|        4347|     7350913
RTD|        4347|     7355260
RTD|        4347|     7359607
RTD|        4347|     7363954
RTD|        4282|     7368236
RTD|        4345|     7372581
RTD|        4345|     7376926
RTT|  00:28:31
WE01:~ # cat /proc/xenomai/sched
CPU  PID    CLASS  PRI      TIMEOUT   TIMEBASE   STAT       NAME
  0  0      idle    -1      -         master     R          ROOT
  0  0      rt      99      496ms670us  master     D          rt-watchdog


Xenomai 2.5.6 on PPC-2.4.25:
RTH|ctx switches|-------total
RTD|         138|       25321
RTD|          73|       25394
RTD|          65|       25459
RTD|         138|       25597
RTD|          73|       25670
RTD|          65|       25735
RTD|         138|       25873
RTD|         138|       26011
RTD|         138|       26149
RTD|         138|       26287
RTD|         138|       26425
RTD|         138|       26563
RTD|         138|       26701
RTD|         138|       26839
RTD|         138|       26977
RTD|          73|       27050
RTD|          65|       27115
RTD|         138|       27253
RTD|         138|       27391
RTD|         138|       27529
RTD|         138|       27667
RTT|  00:09:48
mrconfig:~ # cat /proc/xenomai/sched
CPU  PID    CLASS  PRI      TIMEOUT   TIMEBASE   STAT       NAME
  0  0      idle    -1      -         master     R          ROOT
  0  0      rt      60      185ms803us  master     D          rt-watchdog


> -----Ursprüngliche Nachricht-----
> Von: Philippe Gerum [mailto:rpm@xenomai.org]
> Gesendet: Samstag, 18. Juni 2011 16:22
> An: Gilles Chanteperdrix
> Cc: Wildenburg, Roderik RAEK1 MRA; xenomai@xenomai.org
> Betreff: Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> 
> On Sat, 2011-06-18 at 15:44 +0200, Gilles Chanteperdrix wrote:
> > On 06/18/2011 10:50 AM, Philippe Gerum wrote:
> > > On Tue, 2011-06-14 at 14:47 +0200, roderik.wildenburg@domain.hid
> > > wrote:
> > >> Perhaps this may help:
> > >> I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with printf
> and printk (see appended files) and this is the output:
> > >>
> > >> 1:mrconfig:~ # latency
> > >> 2:xeno_init_private_heap
> > >> 3:map_sem_heap syscall 0
> > >> 4:xeno_map_heap open 3
> > >> 5:xnheap_ioctl private data: 00000000
> > >> 6:xeno_map_heap ioctl 0 handle 0xc7dd9210
> > >> 7:xnheap_mmap 00000000 00000000
> > >> 8:xeno_map_heap 0xffffffff
> > >> 9:Xenomai: mmap local sem heap: No such device or address
> > >> 10:mrconfig:~ #
> > >>
> > >>
> > >> It looks like (if I figured it out correctly) as if in function sem_heap.c-
> >xeno_map_heap()  (which is called from xeno_init_privat_heap() via function
> map_sem_heap())  the ioctl-Call fails.
> > >> xeno_map_heap() passes correctly an argument unequal NULL as third
> parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3.
> parameter arrives as NULL(line 5). This sets file->private_data to NULL which in
> turn lets xnheap_mmap() fail, as this function expects file->private_data != NULL
> (line7).
> > >> Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which
> outputs the error message " Xenomai: mmap local sem heap: No such device or
> address".
> > >> The one million dollar question is, why the 3. parameter of ioctl() mutates to
> NULL. Any idea?
> > >>
> > >> If I can do anything else, let me know.
> > >>
> > >
> > > You will need these patches to run linux 2.4.25 over 2.5.6. The first
> > > one fixes the ioctl() issue.
> > > http://git.xenomai.org/?p=xenomai-
> rpm.git;a=commit;h=c2a24b90667e12d0614e5d8442dba74f137f9d4d
> > > http://git.xenomai.org/?p=xenomai-
> rpm.git;a=commit;h=bebc2a8e6b430c99041800330dc6061665371d90
> > >
> > > Note: the switch test does not seem to be running correctly on my
> > > icecube (albeit the latency one does), somehow linux reschedule events
> > > get lost. For this reason, I would not consider the current state as
> > > being production-grade.
> >
> > How do you see that reschedule events are lost?
> 
> The pace of the supposedly 1sec periodic display stabilizes only when
> other processes run in the background and becomes erratic when the
> switch test is running alone, whilst the system does not seem to lose
> its idea of time. Additionally, signals do not seem to make their way to
> the shadows upon ^C. I did not track the issue in depth though, so at
> this stage I'm speculating.
> 
> >  Does this happen also on
> > other systems?
> >
> 
> Can't tell, I'm not using 2.5.x that much these days. I did not see any
> issue during the sh4 port, which seems to exclude 2.6.x from the
> potential victims.
> 
> Guts feeling is that this might be specific to 2.4 kernels.
> 
> --
> Philippe.
> 
>

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Tue, 2011-06-21 at 12:04 +0200, roderik.wildenburg@domain.hid
wrote:
> I confirm that switchtest runs (nearly) perfectly on PPC-Kernel 2.6.34 with Xenomai 2.5.6. The only anomaly I could see is a "collapse" of the number of context switches exactly every 7 seconds by 2% (see below).  Is this worth to pay attention to? (No other Xenomai-Task is running except for a watchdog task with a period of 500ms)

2% off seems a lot for a transient load, and this would not happen on a
periodic basis anyway. This needs to be investigated. Could you run
switchtest in nofpu mode?

>  
> On the opposite, switchtest runs erratic on PPC-2.4.25 with Xenomai 2.5.6 as you already mentioned: The number of context switches is much smaller then (only about 2%) with  PPC-2.6.34 and fluctuate very much (see below).
> Do you think you will find some spare time to fix this Problem?
> 

Spare time has become a luxury over the last months. I'll try to find a
time slot next week to have a look at this again.

> Roderik
> 
> 
> Xenomai 2.5.6 on PPC-2.6.34:
> RTH|ctx switches|-------total
> RTD|        4347|     7290193
> RTD|        4347|     7294540
> RTD|        4347|     7298887
> RTD|        4347|     7303234
> RTD|        4282|     7307516
> RTD|        4345|     7311861
> RTD|        4345|     7316206
> RTD|        4347|     7320553
> RTD|        4347|     7324900
> RTD|        4347|     7329247
> RTD|        4347|     7333594
> RTD|        4282|     7337876
> RTD|        4345|     7342221
> RTD|        4345|     7346566
> RTD|        4347|     7350913
> RTD|        4347|     7355260
> RTD|        4347|     7359607
> RTD|        4347|     7363954
> RTD|        4282|     7368236
> RTD|        4345|     7372581
> RTD|        4345|     7376926
> RTT|  00:28:31
> WE01:~ # cat /proc/xenomai/sched
> CPU  PID    CLASS  PRI      TIMEOUT   TIMEBASE   STAT       NAME
>   0  0      idle    -1      -         master     R          ROOT
>   0  0      rt      99      496ms670us  master     D          rt-watchdog
> 
> 
> Xenomai 2.5.6 on PPC-2.4.25:
> RTH|ctx switches|-------total
> RTD|         138|       25321
> RTD|          73|       25394
> RTD|          65|       25459
> RTD|         138|       25597
> RTD|          73|       25670
> RTD|          65|       25735
> RTD|         138|       25873
> RTD|         138|       26011
> RTD|         138|       26149
> RTD|         138|       26287
> RTD|         138|       26425
> RTD|         138|       26563
> RTD|         138|       26701
> RTD|         138|       26839
> RTD|         138|       26977
> RTD|          73|       27050
> RTD|          65|       27115
> RTD|         138|       27253
> RTD|         138|       27391
> RTD|         138|       27529
> RTD|         138|       27667
> RTT|  00:09:48
> mrconfig:~ # cat /proc/xenomai/sched
> CPU  PID    CLASS  PRI      TIMEOUT   TIMEBASE   STAT       NAME
>   0  0      idle    -1      -         master     R          ROOT
>   0  0      rt      60      185ms803us  master     D          rt-watchdog
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Philippe Gerum [mailto:rpm@xenomai.org]
> > Gesendet: Samstag, 18. Juni 2011 16:22
> > An: Gilles Chanteperdrix
> > Cc: Wildenburg, Roderik RAEK1 MRA; xenomai@xenomai.org
> > Betreff: Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> > 
> > On Sat, 2011-06-18 at 15:44 +0200, Gilles Chanteperdrix wrote:
> > > On 06/18/2011 10:50 AM, Philippe Gerum wrote:
> > > > On Tue, 2011-06-14 at 14:47 +0200, roderik.wildenburg@domain.hid
> > > > wrote:
> > > >> Perhaps this may help:
> > > >> I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with printf
> > and printk (see appended files) and this is the output:
> > > >>
> > > >> 1:mrconfig:~ # latency
> > > >> 2:xeno_init_private_heap
> > > >> 3:map_sem_heap syscall 0
> > > >> 4:xeno_map_heap open 3
> > > >> 5:xnheap_ioctl private data: 00000000
> > > >> 6:xeno_map_heap ioctl 0 handle 0xc7dd9210
> > > >> 7:xnheap_mmap 00000000 00000000
> > > >> 8:xeno_map_heap 0xffffffff
> > > >> 9:Xenomai: mmap local sem heap: No such device or address
> > > >> 10:mrconfig:~ #
> > > >>
> > > >>
> > > >> It looks like (if I figured it out correctly) as if in function sem_heap.c-
> > >xeno_map_heap()  (which is called from xeno_init_privat_heap() via function
> > map_sem_heap())  the ioctl-Call fails.
> > > >> xeno_map_heap() passes correctly an argument unequal NULL as third
> > parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3.
> > parameter arrives as NULL(line 5). This sets file->private_data to NULL which in
> > turn lets xnheap_mmap() fail, as this function expects file->private_data != NULL
> > (line7).
> > > >> Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which
> > outputs the error message " Xenomai: mmap local sem heap: No such device or
> > address".
> > > >> The one million dollar question is, why the 3. parameter of ioctl() mutates to
> > NULL. Any idea?
> > > >>
> > > >> If I can do anything else, let me know.
> > > >>
> > > >
> > > > You will need these patches to run linux 2.4.25 over 2.5.6. The first
> > > > one fixes the ioctl() issue.
> > > > http://git.xenomai.org/?p=xenomai-
> > rpm.git;a=commit;h=c2a24b90667e12d0614e5d8442dba74f137f9d4d
> > > > http://git.xenomai.org/?p=xenomai-
> > rpm.git;a=commit;h=bebc2a8e6b430c99041800330dc6061665371d90
> > > >
> > > > Note: the switch test does not seem to be running correctly on my
> > > > icecube (albeit the latency one does), somehow linux reschedule events
> > > > get lost. For this reason, I would not consider the current state as
> > > > being production-grade.
> > >
> > > How do you see that reschedule events are lost?
> > 
> > The pace of the supposedly 1sec periodic display stabilizes only when
> > other processes run in the background and becomes erratic when the
> > switch test is running alone, whilst the system does not seem to lose
> > its idea of time. Additionally, signals do not seem to make their way to
> > the shadows upon ^C. I did not track the issue in depth though, so at
> > this stage I'm speculating.
> > 
> > >  Does this happen also on
> > > other systems?
> > >
> > 
> > Can't tell, I'm not using 2.5.x that much these days. I did not see any
> > issue during the sh4 port, which seems to exclude 2.6.x from the
> > potential victims.
> > 
> > Guts feeling is that this might be specific to 2.4 kernels.
> > 
> > --
> > Philippe.
> > 
> >
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
> 

-- 
Philippe.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[roderik.wildenburg]

> 2% off seems a lot for a transient load, and this would not happen on a
> periodic basis anyway. This needs to be investigated. Could you run
> switchtest in nofpu mode?

Still fluctuates about 2% (see !!  mark) but now more erratic. The reduced number of context switches is caused by the reduced number of tasks?

WE01:~ # switchtest -n
== Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
RTT|  00:00:01
RTH|ctx switches|-------total
RTD|        2225|        2225
RTD|        2241|        4466
RTD|        2282|        6748
RTD|        2245|        8993
RTD|        2264|       11257
RTD|        2245|       13502
RTD|        2264|       15766
RTD|        2227|       17993
RTD|        2282|       20275
RTD|        2245|       22520
RTD|        2246|       24766
RTD|        2263|       27029
RTD|        2264|       29293
RTD|        2245|       31538
RTD|        2264|       33802
RTD|        2245|       36047
RTD|        2246|       38293
RTD|        2245|       40538
RTD|        2282|       42820
RTD|        2245|       45065
RTD|        2264|       47329
RTT|  00:00:22
RTH|ctx switches|-------total
RTD|        2245|       49574
RTD|        2264|       51838
RTD|        2227|       54065
RTD|        2282|       56347
RTD|        2243|       58590
RTD|        2248|       60838
RTD|        2263|       63101
RTD|        2264|       65365
RTD|        2245|       67610
RTD|        2264|       69874
RTD|        2245|       72119
RTD|        2246|       74365
RTD|        2245|       76610
RTD|        2282|       78892
RTD|        2245|       81137
RTD|        2264|       83401
RTD|        2245|       85646
RTD|        2264|       87910
RTD|        2227|       90137
RTD|        2282|       92419
RTD|        2245|       94664
RTT|  00:00:43
RTH|ctx switches|-------total
RTD|        2246|       96910
RTD|        2263|       99173
RTD|        2264|      101437
RTD|        2245|      103682
RTD|        2264|      105946
RTD|        2245|      108191
RTD|        2246|      110437
RTD|        2245|      112682
RTD|        2282|      114964
RTD|        2245|      117209
RTD|        2264|      119473
RTD|        2245|      121718
RTD|        2264|      123982
!!RTD|        2227|      126209
!!RTD|        2282|      128491
RTD|        2245|      130736
RTD|        2246|      132982
RTD|        2263|      135245
RTD|        2264|      137509
RTD|        2245|      139754
RTD|        2264|      142018
WE01:~ # cat /proc/xenomai/version
2.5.6
WE01:~ # cat /proc/xenomai/sched
CPU  PID    CLASS  PRI      TIMEOUT   TIMEBASE   STAT       NAME
  0  0      idle    -1      -         master     R          ROOT
  0  0      rt      99      233ms634us  master     D          rt-watchdog
WE01:~ # cat /proc/xenomai/stat
CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
  0  0      0          6972142    0     00500080   90.5  ROOT
  0  0      0          39412      0     00000084    0.0  rt-watchdog
  0  0      0          9305099    0     00000000    0.5  IRQ512: [timer]





> -----Ursprüngliche Nachricht-----
> Von: Philippe Gerum [mailto:rpm@xenomai.org]
> Gesendet: Dienstag, 21. Juni 2011 12:36
> An: Wildenburg, Roderik RAEK1 MRA
> Cc: gilles.chanteperdrix@xenomai.org; xenomai@xenomai.org
> Betreff: Re: AW: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> 
> On Tue, 2011-06-21 at 12:04 +0200, roderik.wildenburg@domain.hid
> wrote:
> > I confirm that switchtest runs (nearly) perfectly on PPC-Kernel 2.6.34 with
> Xenomai 2.5.6. The only anomaly I could see is a "collapse" of the number of
> context switches exactly every 7 seconds by 2% (see below).  Is this worth to pay
> attention to? (No other Xenomai-Task is running except for a watchdog task with a
> period of 500ms)
> 
> 2% off seems a lot for a transient load, and this would not happen on a
> periodic basis anyway. This needs to be investigated. Could you run
> switchtest in nofpu mode?
> 
> >
> > On the opposite, switchtest runs erratic on PPC-2.4.25 with Xenomai 2.5.6 as
> you already mentioned: The number of context switches is much smaller then
> (only about 2%) with  PPC-2.6.34 and fluctuate very much (see below).
> > Do you think you will find some spare time to fix this Problem?
> >
> 
> Spare time has become a luxury over the last months. I'll try to find a
> time slot next week to have a look at this again.
> 
> > Roderik
> >
> >
> > Xenomai 2.5.6 on PPC-2.6.34:
> > RTH|ctx switches|-------total
> > RTD|        4347|     7290193
> > RTD|        4347|     7294540
> > RTD|        4347|     7298887
> > RTD|        4347|     7303234
> > RTD|        4282|     7307516
> > RTD|        4345|     7311861
> > RTD|        4345|     7316206
> > RTD|        4347|     7320553
> > RTD|        4347|     7324900
> > RTD|        4347|     7329247
> > RTD|        4347|     7333594
> > RTD|        4282|     7337876
> > RTD|        4345|     7342221
> > RTD|        4345|     7346566
> > RTD|        4347|     7350913
> > RTD|        4347|     7355260
> > RTD|        4347|     7359607
> > RTD|        4347|     7363954
> > RTD|        4282|     7368236
> > RTD|        4345|     7372581
> > RTD|        4345|     7376926
> > RTT|  00:28:31
> > WE01:~ # cat /proc/xenomai/sched
> > CPU  PID    CLASS  PRI      TIMEOUT   TIMEBASE   STAT       NAME
> >   0  0      idle    -1      -         master     R          ROOT
> >   0  0      rt      99      496ms670us  master     D          rt-watchdog
> >
> >
> > Xenomai 2.5.6 on PPC-2.4.25:
> > RTH|ctx switches|-------total
> > RTD|         138|       25321
> > RTD|          73|       25394
> > RTD|          65|       25459
> > RTD|         138|       25597
> > RTD|          73|       25670
> > RTD|          65|       25735
> > RTD|         138|       25873
> > RTD|         138|       26011
> > RTD|         138|       26149
> > RTD|         138|       26287
> > RTD|         138|       26425
> > RTD|         138|       26563
> > RTD|         138|       26701
> > RTD|         138|       26839
> > RTD|         138|       26977
> > RTD|          73|       27050
> > RTD|          65|       27115
> > RTD|         138|       27253
> > RTD|         138|       27391
> > RTD|         138|       27529
> > RTD|         138|       27667
> > RTT|  00:09:48
> > mrconfig:~ # cat /proc/xenomai/sched
> > CPU  PID    CLASS  PRI      TIMEOUT   TIMEBASE   STAT       NAME
> >   0  0      idle    -1      -         master     R          ROOT
> >   0  0      rt      60      185ms803us  master     D          rt-watchdog
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Philippe Gerum [mailto:rpm@xenomai.org]
> > > Gesendet: Samstag, 18. Juni 2011 16:22
> > > An: Gilles Chanteperdrix
> > > Cc: Wildenburg, Roderik RAEK1 MRA; xenomai@xenomai.org
> > > Betreff: Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> > >
> > > On Sat, 2011-06-18 at 15:44 +0200, Gilles Chanteperdrix wrote:
> > > > On 06/18/2011 10:50 AM, Philippe Gerum wrote:
> > > > > On Tue, 2011-06-14 at 14:47 +0200, roderik.wildenburg@domain.hid
> > > > > wrote:
> > > > >> Perhaps this may help:
> > > > >> I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with
> printf
> > > and printk (see appended files) and this is the output:
> > > > >>
> > > > >> 1:mrconfig:~ # latency
> > > > >> 2:xeno_init_private_heap
> > > > >> 3:map_sem_heap syscall 0
> > > > >> 4:xeno_map_heap open 3
> > > > >> 5:xnheap_ioctl private data: 00000000
> > > > >> 6:xeno_map_heap ioctl 0 handle 0xc7dd9210
> > > > >> 7:xnheap_mmap 00000000 00000000
> > > > >> 8:xeno_map_heap 0xffffffff
> > > > >> 9:Xenomai: mmap local sem heap: No such device or address
> > > > >> 10:mrconfig:~ #
> > > > >>
> > > > >>
> > > > >> It looks like (if I figured it out correctly) as if in function sem_heap.c-
> > > >xeno_map_heap()  (which is called from xeno_init_privat_heap() via
> function
> > > map_sem_heap())  the ioctl-Call fails.
> > > > >> xeno_map_heap() passes correctly an argument unequal NULL as third
> > > parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3.
> > > parameter arrives as NULL(line 5). This sets file->private_data to NULL which
> in
> > > turn lets xnheap_mmap() fail, as this function expects file->private_data !=
> NULL
> > > (line7).
> > > > >> Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which
> > > outputs the error message " Xenomai: mmap local sem heap: No such device
> or
> > > address".
> > > > >> The one million dollar question is, why the 3. parameter of ioctl() mutates
> to
> > > NULL. Any idea?
> > > > >>
> > > > >> If I can do anything else, let me know.
> > > > >>
> > > > >
> > > > > You will need these patches to run linux 2.4.25 over 2.5.6. The first
> > > > > one fixes the ioctl() issue.
> > > > > http://git.xenomai.org/?p=xenomai-
> > > rpm.git;a=commit;h=c2a24b90667e12d0614e5d8442dba74f137f9d4d
> > > > > http://git.xenomai.org/?p=xenomai-
> > > rpm.git;a=commit;h=bebc2a8e6b430c99041800330dc6061665371d90
> > > > >
> > > > > Note: the switch test does not seem to be running correctly on my
> > > > > icecube (albeit the latency one does), somehow linux reschedule events
> > > > > get lost. For this reason, I would not consider the current state as
> > > > > being production-grade.
> > > >
> > > > How do you see that reschedule events are lost?
> > >
> > > The pace of the supposedly 1sec periodic display stabilizes only when
> > > other processes run in the background and becomes erratic when the
> > > switch test is running alone, whilst the system does not seem to lose
> > > its idea of time. Additionally, signals do not seem to make their way to
> > > the shadows upon ^C. I did not track the issue in depth though, so at
> > > this stage I'm speculating.
> > >
> > > >  Does this happen also on
> > > > other systems?
> > > >
> > >
> > > Can't tell, I'm not using 2.5.x that much these days. I did not see any
> > > issue during the sh4 port, which seems to exclude 2.6.x from the
> > > potential victims.
> > >
> > > Guts feeling is that this might be specific to 2.4 kernels.
> > >
> > > --
> > > Philippe.
> > >
> > >
> >
> > --------------------------------------------------------
> > manroland AG
> > Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> > Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul
> Steidle
> > Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht
> Offenbach HRB-Nr. 42592
> > USt-Ident-Nr. DE 250200933
> >
> 
> --
> Philippe.
> 
>

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Gilles Chanteperdrix]

On 06/21/2011 01:22 PM, roderik.wildenburg@domain.hid wrote:
>> 2% off seems a lot for a transient load, and this would not happen on a
>> periodic basis anyway. This needs to be investigated. Could you run
>> switchtest in nofpu mode?
> 
> Still fluctuates about 2% (see !!  mark) but now more erratic. The reduced number of context switches is caused by the reduced number of tasks?

switchest works by switching context between several tasks. One of this
task does sleep, in order to avoid starving linux, and also prints the
numbers approximately every second.

When there are less task, we enter the sleeping task more often, so,
yes, there are less context switches.

But more importantly, since, the time when we print the result is so
imprecise, some variations are normal, so, chances are that the 2%
variation is normal.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[roderik.wildenburg]

> But more importantly, since, the time when we print the result is so
> imprecise, some variations are normal, so, chances are that the 2%
> variation is normal.
>

Ok. Here is a switchtest with Xenomai 2.4.9 on PPC-Kernel 2.4.25 and indeed fluctuation is again about 2%.
But the number of context switches is just about 25% of switchtest from Xeno 2.5.6 on a PPC-2.6.34. Did you change the tasks period from 2.4.9 to 2.5.6?
So, if the gurus say this variation is within the normal bandwidth it is ok for me.

>Spare time has become a luxury over the last months. I'll try to find a
>time slot next week to have a look at this again.

Tanks a lot!
 I don´t dare to say, but I am on vacation for the rest of this and the next week, so I only can do testing as of 4. of July again.

Roderik

----------------------------------------------------------------------------
Xenomai 2.4.9 on PPC-2.4.25:
RW24:/fat/sbin # switchtest
== Testing FPU check routines...
r0: 1 != 2
r1: 1 != 2
r2: 1 != 2
r3: 1 != 2
r4: 1 != 2
r5: 1 != 2
r6: 1 != 2
r7: 1 != 2
r8: 1 != 2
r9: 1 != 2
r10: 1 != 2
r11: 1 != 2
r12: 1 != 2
r13: 1 != 2
r14: 1 != 2
r15: 1 != 2
r16: 1 != 2
r17: 1 != 2
r18: 1 != 2
r19: 1 != 2
r20: 1 != 2
r21: 1 != 2
r22: 1 != 2
r23: 1 != 2
r24: 1 != 2
r25: 1 != 2
r26: 1 != 2
r27: 1 != 2
r28: 1 != 2
r29: 1 != 2
r30: 1 != 2
r31: 1 != 2
== FPU check routines: OK.
== Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5 rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12 rtus_ufps-13 rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18 rtuo_ufps-19 rtuo_ufps-20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22
RTT|  00:00:01
RTH|ctx switches|-------total
RTD|        1150|        1150
RTD|        1150|        2300
RTD|        1173|        3473
RTD|        1173|        4646
RTD|        1150|        5796
RTD|        1173|        6969
RTD|        1150|        8119
RTD|        1173|        9292
RTD|        1150|       10442
RTD|        1173|       11615
RTD|        1173|       12788
RTD|        1150|       13938
RTD|        1173|       15111
RTD|        1173|       16284
RTD|        1150|       17434
RTD|        1150|       18584
RTD|        1150|       19734
RTD|        1173|       20907
RTD|        1150|       22057
RTD|        1150|       23207
RTD|        1150|       24357
RTT|  00:00:22
RTH|ctx switches|-------total
RTD|        1173|       25530
RTD|        1173|       26703
RTD|        1173|       27876
RTD|        1173|       29049
RTD|        1150|       30199
RTD|        1150|       31349
RTD|        1150|       32499
RTD|        1173|       33672
RTD|        1173|       34845
RTD|        1173|       36018
RTD|        1150|       37168
RTD|        1150|       38318
RTD|        1150|       39468
RTD|        1173|       40641
RTD|        1150|       41791
RTD|        1150|       42941
RTD|        1173|       44114
RTD|        1150|       45264
RTD|        1150|       46414
RTD|        1150|       47564
RTD|        1173|       48737
RTT|  00:00:43
RW24:/fat/sbin # cat /proc/xenomai/version
2.4.9
RW24:/fat/sbin # cat /proc/xenomai/sched
CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
  0  0       -1      0          0          master    R          ROOT
  0  0       99      200000000  45608637   master    D          rt-watchdog
RW24:/fat/sbin # cat /proc/xenomai/stat
CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
  0  0      0          38989      0     00500080   98.3  ROOT
  0  0      0          701        0     00000084    0.0  rt-watchdog
  0  0      0          14730      0     00000000    0.1  IRQ256: [timer]
RW24:/fat/sbin #


> -----Ursprüngliche Nachricht-----
> Von: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Gesendet: Dienstag, 21. Juni 2011 13:33
> An: Wildenburg, Roderik RAEK1 MRA
> Cc: rpm@xenomai.org; xenomai@xenomai.org
> Betreff: Re: AW: AW: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> 
> On 06/21/2011 01:22 PM, roderik.wildenburg@domain.hid wrote:
> >> 2% off seems a lot for a transient load, and this would not happen on a
> >> periodic basis anyway. This needs to be investigated. Could you run
> >> switchtest in nofpu mode?
> >
> > Still fluctuates about 2% (see !!  mark) but now more erratic. The reduced
> number of context switches is caused by the reduced number of tasks?
> 
> switchest works by switching context between several tasks. One of this
> task does sleep, in order to avoid starving linux, and also prints the
> numbers approximately every second.
> 
> When there are less task, we enter the sleeping task more often, so,
> yes, there are less context switches.
> 
> But more importantly, since, the time when we print the result is so
> imprecise, some variations are normal, so, chances are that the 2%
> variation is normal.
> 
> --
>                                                                 Gilles.

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Tue, 2011-06-21 at 15:05 +0200, roderik.wildenburg@domain.hid
wrote:
> > But more importantly, since, the time when we print the result is so
> > imprecise, some variations are normal, so, chances are that the 2%
> > variation is normal.
> >
> 
> Ok. Here is a switchtest with Xenomai 2.4.9 on PPC-Kernel 2.4.25 and indeed fluctuation is again about 2%.
> But the number of context switches is just about 25% of switchtest from Xeno 2.5.6 on a PPC-2.6.34. Did you change the tasks period from 2.4.9 to 2.5.6?
> So, if the gurus say this variation is within the normal bandwidth it is ok for me.

The number of switches is related to the number of tasks running in this
test, nofpu reduces this number. So that is ok. The problem with this
test is that switches/sec values are sampled by a regular linux thread
which nanosleeps, so at least over 2.4, the delay is not accurate. So
the number of switches observed can't be either.

I still have to check over 2.6 + hires if we can still explain this 2%
offset the same way.

> 
> >Spare time has become a luxury over the last months. I'll try to find a
> >time slot next week to have a look at this again.
> 
> Tanks a lot!
>  I don´t dare to say, but I am on vacation for the rest of this and the next week, so I only can do testing as of 4. of July again.
> 

Ok.

> Roderik
> 
> ----------------------------------------------------------------------------
> Xenomai 2.4.9 on PPC-2.4.25:
> RW24:/fat/sbin # switchtest
> == Testing FPU check routines...
> r0: 1 != 2
> r1: 1 != 2
> r2: 1 != 2
> r3: 1 != 2
> r4: 1 != 2
> r5: 1 != 2
> r6: 1 != 2
> r7: 1 != 2
> r8: 1 != 2
> r9: 1 != 2
> r10: 1 != 2
> r11: 1 != 2
> r12: 1 != 2
> r13: 1 != 2
> r14: 1 != 2
> r15: 1 != 2
> r16: 1 != 2
> r17: 1 != 2
> r18: 1 != 2
> r19: 1 != 2
> r20: 1 != 2
> r21: 1 != 2
> r22: 1 != 2
> r23: 1 != 2
> r24: 1 != 2
> r25: 1 != 2
> r26: 1 != 2
> r27: 1 != 2
> r28: 1 != 2
> r29: 1 != 2
> r30: 1 != 2
> r31: 1 != 2
> == FPU check routines: OK.
> == Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5 rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12 rtus_ufps-13 rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18 rtuo_ufps-19 rtuo_ufps-20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22
> RTT|  00:00:01
> RTH|ctx switches|-------total
> RTD|        1150|        1150
> RTD|        1150|        2300
> RTD|        1173|        3473
> RTD|        1173|        4646
> RTD|        1150|        5796
> RTD|        1173|        6969
> RTD|        1150|        8119
> RTD|        1173|        9292
> RTD|        1150|       10442
> RTD|        1173|       11615
> RTD|        1173|       12788
> RTD|        1150|       13938
> RTD|        1173|       15111
> RTD|        1173|       16284
> RTD|        1150|       17434
> RTD|        1150|       18584
> RTD|        1150|       19734
> RTD|        1173|       20907
> RTD|        1150|       22057
> RTD|        1150|       23207
> RTD|        1150|       24357
> RTT|  00:00:22
> RTH|ctx switches|-------total
> RTD|        1173|       25530
> RTD|        1173|       26703
> RTD|        1173|       27876
> RTD|        1173|       29049
> RTD|        1150|       30199
> RTD|        1150|       31349
> RTD|        1150|       32499
> RTD|        1173|       33672
> RTD|        1173|       34845
> RTD|        1173|       36018
> RTD|        1150|       37168
> RTD|        1150|       38318
> RTD|        1150|       39468
> RTD|        1173|       40641
> RTD|        1150|       41791
> RTD|        1150|       42941
> RTD|        1173|       44114
> RTD|        1150|       45264
> RTD|        1150|       46414
> RTD|        1150|       47564
> RTD|        1173|       48737
> RTT|  00:00:43
> RW24:/fat/sbin # cat /proc/xenomai/version
> 2.4.9
> RW24:/fat/sbin # cat /proc/xenomai/sched
> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
>   0  0       -1      0          0          master    R          ROOT
>   0  0       99      200000000  45608637   master    D          rt-watchdog
> RW24:/fat/sbin # cat /proc/xenomai/stat
> CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
>   0  0      0          38989      0     00500080   98.3  ROOT
>   0  0      0          701        0     00000084    0.0  rt-watchdog
>   0  0      0          14730      0     00000000    0.1  IRQ256: [timer]
> RW24:/fat/sbin #
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> > Gesendet: Dienstag, 21. Juni 2011 13:33
> > An: Wildenburg, Roderik RAEK1 MRA
> > Cc: rpm@xenomai.org; xenomai@xenomai.org
> > Betreff: Re: AW: AW: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> > 
> > On 06/21/2011 01:22 PM, roderik.wildenburg@domain.hid wrote:
> > >> 2% off seems a lot for a transient load, and this would not happen on a
> > >> periodic basis anyway. This needs to be investigated. Could you run
> > >> switchtest in nofpu mode?
> > >
> > > Still fluctuates about 2% (see !!  mark) but now more erratic. The reduced
> > number of context switches is caused by the reduced number of tasks?
> > 
> > switchest works by switching context between several tasks. One of this
> > task does sleep, in order to avoid starving linux, and also prints the
> > numbers approximately every second.
> > 
> > When there are less task, we enter the sleeping task more often, so,
> > yes, there are less context switches.
> > 
> > But more importantly, since, the time when we print the result is so
> > imprecise, some variations are normal, so, chances are that the 2%
> > variation is normal.
> > 
> > --
> >                                                                 Gilles.
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
> 

-- 
Philippe.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[roderik.wildenburg]

> 
> The number of switches is related to the number of tasks running in this
> test, nofpu reduces this number. So that is ok. 

I understand this, but both tests X2.4.9+PPC2.4.25 and X2.5.6+PPC-2.6.34 I run without(!) the option --nofpu. And in both cases there were 22 tasks.
With X2.4.9+2.4.25 I got about 1170 CTX-switches and with 2.5.6+2.6.34 about 4300 CTW-switches.
Only one test I run with --nofpu option (X2.5.6+PPC2.6.34)  (mail form 13:25 o´clock)!  and got about 2200 CTX-switches and there the difference is due to reduced number of taks.

>The problem with this
> test is that switches/sec values are sampled by a regular linux thread
> which nanosleeps, so at least over 2.4, the delay is not accurate. So
> the number of switches observed can't be either.
> 
> I still have to check over 2.6 + hires if we can still explain this 2%
> offset the same way.

But in (2.6.34)+2.5.6 the display task is still an ordinary linux task (__real_pthread_create, as far as I can see). Why should it be more accurate?
Sorry for steeling your time and asking stupid  questions.

Roderik

> 
> >
> > >Spare time has become a luxury over the last months. I'll try to find a
> > >time slot next week to have a look at this again.
> >
> > Tanks a lot!
> >  I don´t dare to say, but I am on vacation for the rest of this and the next week, so
> I only can do testing as of 4. of July again.
> >
> 
> Ok.
> 
> > Roderik
> >
> > ----------------------------------------------------------------------------
> > Xenomai 2.4.9 on PPC-2.4.25:
> > RW24:/fat/sbin # switchtest
> > == Testing FPU check routines...
> > r0: 1 != 2
> > r1: 1 != 2
> > r2: 1 != 2
> > r3: 1 != 2
> > r4: 1 != 2
> > r5: 1 != 2
> > r6: 1 != 2
> > r7: 1 != 2
> > r8: 1 != 2
> > r9: 1 != 2
> > r10: 1 != 2
> > r11: 1 != 2
> > r12: 1 != 2
> > r13: 1 != 2
> > r14: 1 != 2
> > r15: 1 != 2
> > r16: 1 != 2
> > r17: 1 != 2
> > r18: 1 != 2
> > r19: 1 != 2
> > r20: 1 != 2
> > r21: 1 != 2
> > r22: 1 != 2
> > r23: 1 != 2
> > r24: 1 != 2
> > r25: 1 != 2
> > r26: 1 != 2
> > r27: 1 != 2
> > r28: 1 != 2
> > r29: 1 != 2
> > r30: 1 != 2
> > r31: 1 != 2
> > == FPU check routines: OK.
> > == Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5
> rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12 rtus_ufps-13
> rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18 rtuo_ufps-19 rtuo_ufps-
> 20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22
> > RTT|  00:00:01
> > RTH|ctx switches|-------total
> > RTD|        1150|        1150
> > RTD|        1150|        2300
> > RTD|        1173|        3473
> > RTD|        1173|        4646
> > RTD|        1150|        5796
> > RTD|        1173|        6969
> > RTD|        1150|        8119
> > RTD|        1173|        9292
> > RTD|        1150|       10442
> > RTD|        1173|       11615
> > RTD|        1173|       12788
> > RTD|        1150|       13938
> > RTD|        1173|       15111
> > RTD|        1173|       16284
> > RTD|        1150|       17434
> > RTD|        1150|       18584
> > RTD|        1150|       19734
> > RTD|        1173|       20907
> > RTD|        1150|       22057
> > RTD|        1150|       23207
> > RTD|        1150|       24357
> > RTT|  00:00:22
> > RTH|ctx switches|-------total
> > RTD|        1173|       25530
> > RTD|        1173|       26703
> > RTD|        1173|       27876
> > RTD|        1173|       29049
> > RTD|        1150|       30199
> > RTD|        1150|       31349
> > RTD|        1150|       32499
> > RTD|        1173|       33672
> > RTD|        1173|       34845
> > RTD|        1173|       36018
> > RTD|        1150|       37168
> > RTD|        1150|       38318
> > RTD|        1150|       39468
> > RTD|        1173|       40641
> > RTD|        1150|       41791
> > RTD|        1150|       42941
> > RTD|        1173|       44114
> > RTD|        1150|       45264
> > RTD|        1150|       46414
> > RTD|        1150|       47564
> > RTD|        1173|       48737
> > RTT|  00:00:43
> > RW24:/fat/sbin # cat /proc/xenomai/version
> > 2.4.9
> > RW24:/fat/sbin # cat /proc/xenomai/sched
> > CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
> >   0  0       -1      0          0          master    R          ROOT
> >   0  0       99      200000000  45608637   master    D          rt-watchdog
> > RW24:/fat/sbin # cat /proc/xenomai/stat
> > CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
> >   0  0      0          38989      0     00500080   98.3  ROOT
> >   0  0      0          701        0     00000084    0.0  rt-watchdog
> >   0  0      0          14730      0     00000000    0.1  IRQ256: [timer]
> > RW24:/fat/sbin #
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> > > Gesendet: Dienstag, 21. Juni 2011 13:33
> > > An: Wildenburg, Roderik RAEK1 MRA
> > > Cc: rpm@xenomai.org; xenomai@xenomai.org
> > > Betreff: Re: AW: AW: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> > >
> > > On 06/21/2011 01:22 PM, roderik.wildenburg@domain.hid wrote:
> > > >> 2% off seems a lot for a transient load, and this would not happen on a
> > > >> periodic basis anyway. This needs to be investigated. Could you run
> > > >> switchtest in nofpu mode?
> > > >
> > > > Still fluctuates about 2% (see !!  mark) but now more erratic. The reduced
> > > number of context switches is caused by the reduced number of tasks?
> > >
> > > switchest works by switching context between several tasks. One of this
> > > task does sleep, in order to avoid starving linux, and also prints the
> > > numbers approximately every second.
> > >
> > > When there are less task, we enter the sleeping task more often, so,
> > > yes, there are less context switches.
> > >
> > > But more importantly, since, the time when we print the result is so
> > > imprecise, some variations are normal, so, chances are that the 2%
> > > variation is normal.
> > >
> > > --
> > >                                                                 Gilles.
> >
> > --------------------------------------------------------
> > manroland AG
> > Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> > Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul
> Steidle
> > Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht
> Offenbach HRB-Nr. 42592
> > USt-Ident-Nr. DE 250200933
> >
> 
> --
> Philippe.
> 
>

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Gilles Chanteperdrix]

On 06/21/2011 03:15 PM, Philippe Gerum wrote:
> On Tue, 2011-06-21 at 15:05 +0200, roderik.wildenburg@domain.hid
> wrote:
>>> But more importantly, since, the time when we print the result is so
>>> imprecise, some variations are normal, so, chances are that the 2%
>>> variation is normal.
>>>
>>
>> Ok. Here is a switchtest with Xenomai 2.4.9 on PPC-Kernel 2.4.25 and indeed fluctuation is again about 2%.
>> But the number of context switches is just about 25% of switchtest from Xeno 2.5.6 on a PPC-2.6.34. Did you change the tasks period from 2.4.9 to 2.5.6?
>> So, if the gurus say this variation is within the normal bandwidth it is ok for me.
> 
> The number of switches is related to the number of tasks running in this
> test, nofpu reduces this number. So that is ok. The problem with this
> test is that switches/sec values are sampled by a regular linux thread
> which nanosleeps, so at least over 2.4, the delay is not accurate. So
> the number of switches observed can't be either.

The task which nanosleeps does not really sample the number of context
switches, it is part of the context switches chain, and simply prints
the number when it sees that the last time the number was printed is
more than 1s ago. So, how many context switches happen depends greatly
on how many time the context switches chain passed by this task, and so
is not regular.

The switchtest code also changed between 2.4 and 2.6, which is why you
can not compare the numbers.

Pay no attention to the number of context switches. All which matters is
that this number increase over time, this is why we print them.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Tue, 2011-06-21 at 16:05 +0200, Gilles Chanteperdrix wrote:
> On 06/21/2011 03:15 PM, Philippe Gerum wrote:
> > On Tue, 2011-06-21 at 15:05 +0200, roderik.wildenburg@domain.hid
> > wrote:
> >>> But more importantly, since, the time when we print the result is so
> >>> imprecise, some variations are normal, so, chances are that the 2%
> >>> variation is normal.
> >>>
> >>
> >> Ok. Here is a switchtest with Xenomai 2.4.9 on PPC-Kernel 2.4.25 and indeed fluctuation is again about 2%.
> >> But the number of context switches is just about 25% of switchtest from Xeno 2.5.6 on a PPC-2.6.34. Did you change the tasks period from 2.4.9 to 2.5.6?
> >> So, if the gurus say this variation is within the normal bandwidth it is ok for me.
> > 
> > The number of switches is related to the number of tasks running in this
> > test, nofpu reduces this number. So that is ok. The problem with this
> > test is that switches/sec values are sampled by a regular linux thread
> > which nanosleeps, so at least over 2.4, the delay is not accurate. So
> > the number of switches observed can't be either.
> 
> The task which nanosleeps does not really sample the number of context
> switches, it is part of the context switches chain, and simply prints
> the number when it sees that the last time the number was printed is
> more than 1s ago. So, how many context switches happen depends greatly
> on how many time the context switches chain passed by this task, and so
> is not regular.

This is why the sleeper actually samples somehow, polling then printing
the switch count from the driver based on a 1ms period it runs, given
that the scheduling chain should be reasonably fixed. Granted, this
cannot be precise at all in any case.

> 
> The switchtest code also changed between 2.4
>  and 2.6, which is why you
> can not compare the numbers.
> 
> Pay no attention to the number of context switches. All which matters is
> that this number increase over time, this is why we print them.
> 

And as a matter of fact, this is the good way to quickly detect the
kernel 2.4 issue we have.

-- 
Philippe.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Tue, 2011-06-21 at 12:35 +0200, Philippe Gerum wrote:
> On Tue, 2011-06-21 at 12:04 +0200, roderik.wildenburg@domain.hid
> wrote:
> > I confirm that switchtest runs (nearly) perfectly on PPC-Kernel 2.6.34 with Xenomai 2.5.6. The only anomaly I could see is a "collapse" of the number of context switches exactly every 7 seconds by 2% (see below).  Is this worth to pay attention to? (No other Xenomai-Task is running except for a watchdog task with a period of 500ms)
> 
> 2% off seems a lot for a transient load, and this would not happen on a
> periodic basis anyway. This needs to be investigated. Could you run
> switchtest in nofpu mode?
> 
> >  
> > On the opposite, switchtest runs erratic on PPC-2.4.25 with Xenomai 2.5.6 as you already mentioned: The number of context switches is much smaller then (only about 2%) with  PPC-2.6.34 and fluctuate very much (see below).
> > Do you think you will find some spare time to fix this Problem?
> > 
> 
> Spare time has become a luxury over the last months. I'll try to find a
> time slot next week to have a look at this again.

This should help, no I-pipe update needed.

http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=35e9df567e19410526089e24fbbaf92c47de9c43

-- 
Philippe.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[roderik.wildenburg]

Hello Philippe,

thank you very much for your patch and your precious time you spent on solving this issue!
Switchtest now seems to work proper (but fluctuation increased from 2% to 5% 1173->1108 see below).
I will perform the latency measurement for 2.4.5+2.5.6 as soon as possible.

Roderik

RTH|ctx switches|-------total
RTD|        1173|      148279
RTD|        1173|      149452
RTD|        1173|      150625
RTD|        1173|      151798
RTD|        1173|      152971
RTD|        1173|      154144
RTD|        1108|      155252
RTD|        1173|      156425
RTD|        1171|      157596
RTD|        1171|      158767
RTD|        1173|      159940
RTD|        1173|      161113
RTD|        1173|      162286
RTD|        1173|      163459
RTD|        1173|      164632
mrconfig:~ # uname -r
2.4.25
mrconfig:~ # cat /proc/xenomai/version
2.5.6
mrconfig:~ #


> -----Ursprüngliche Nachricht-----
> Von: Philippe Gerum [mailto:rpm@xenomai.org]
> Gesendet: Sonntag, 3. Juli 2011 17:48
> An: Wildenburg, Roderik RAEK1 MRA
> Cc: gilles.chanteperdrix@xenomai.org; xenomai@xenomai.org
> Betreff: Re: AW: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25
> 
> On Tue, 2011-06-21 at 12:35 +0200, Philippe Gerum wrote:
> > On Tue, 2011-06-21 at 12:04 +0200, roderik.wildenburg@domain.hid
> > wrote:
> > > I confirm that switchtest runs (nearly) perfectly on PPC-Kernel 2.6.34 with
> Xenomai 2.5.6. The only anomaly I could see is a "collapse" of the number of
> context switches exactly every 7 seconds by 2% (see below).  Is this worth to pay
> attention to? (No other Xenomai-Task is running except for a watchdog task with a
> period of 500ms)
> >
> > 2% off seems a lot for a transient load, and this would not happen on a
> > periodic basis anyway. This needs to be investigated. Could you run
> > switchtest in nofpu mode?
> >
> > >
> > > On the opposite, switchtest runs erratic on PPC-2.4.25 with Xenomai 2.5.6 as
> you already mentioned: The number of context switches is much smaller then
> (only about 2%) with  PPC-2.6.34 and fluctuate very much (see below).
> > > Do you think you will find some spare time to fix this Problem?
> > >
> >
> > Spare time has become a luxury over the last months. I'll try to find a
> > time slot next week to have a look at this again.
> 
> This should help, no I-pipe update needed.
> 
> http://git.xenomai.org/?p=xenomai-
> rpm.git;a=commit;h=35e9df567e19410526089e24fbbaf92c47de9c43
> 
> --
> Philippe.
> 
>

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Sat, 2011-06-18 at 15:44 +0200, Gilles Chanteperdrix wrote:
> On 06/18/2011 10:50 AM, Philippe Gerum wrote:
> > On Tue, 2011-06-14 at 14:47 +0200, roderik.wildenburg@domain.hid
> > wrote:
> >> Perhaps this may help:
> >> I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with printf and printk (see appended files) and this is the output:
> >>
> >> 1:mrconfig:~ # latency
> >> 2:xeno_init_private_heap
> >> 3:map_sem_heap syscall 0
> >> 4:xeno_map_heap open 3
> >> 5:xnheap_ioctl private data: 00000000
> >> 6:xeno_map_heap ioctl 0 handle 0xc7dd9210
> >> 7:xnheap_mmap 00000000 00000000
> >> 8:xeno_map_heap 0xffffffff
> >> 9:Xenomai: mmap local sem heap: No such device or address
> >> 10:mrconfig:~ #
> >>
> >>
> >> It looks like (if I figured it out correctly) as if in function sem_heap.c->xeno_map_heap()  (which is called from xeno_init_privat_heap() via function map_sem_heap())  the ioctl-Call fails. 
> >> xeno_map_heap() passes correctly an argument unequal NULL as third parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3. parameter arrives as NULL(line 5). This sets file->private_data to NULL which in turn lets xnheap_mmap() fail, as this function expects file->private_data != NULL (line7).
> >> Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which outputs the error message " Xenomai: mmap local sem heap: No such device or address".
> >> The one million dollar question is, why the 3. parameter of ioctl() mutates to NULL. Any idea?
> >>
> >> If I can do anything else, let me know.
> >>
> > 
> > You will need these patches to run linux 2.4.25 over 2.5.6. The first
> > one fixes the ioctl() issue.
> > http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=c2a24b90667e12d0614e5d8442dba74f137f9d4d
> > http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=bebc2a8e6b430c99041800330dc6061665371d90
> > 
> > Note: the switch test does not seem to be running correctly on my
> > icecube (albeit the latency one does), somehow linux reschedule events
> > get lost. For this reason, I would not consider the current state as
> > being production-grade.
> 
> How do you see that reschedule events are lost? Does this happen also on
> other systems?
> 

nios2, x86_32, blackfin, arm11/mpcore, 85xx are all running the switch
test fine over 2.5.x + 2.6 kernels. This tends to point the finger at an
issue between the pipeline for 2.4/ppc and the real-time core.

-- 
Philippe.

Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum]

On Sat, 2011-06-18 at 16:35 +0200, Philippe Gerum wrote:
> On Sat, 2011-06-18 at 15:44 +0200, Gilles Chanteperdrix wrote:
> > On 06/18/2011 10:50 AM, Philippe Gerum wrote:
> > > On Tue, 2011-06-14 at 14:47 +0200, roderik.wildenburg@domain.hid
> > > wrote:
> > >> Perhaps this may help:
> > >> I instrumented src/common/sem_heap.c   and ksrc/nucleus/heap.c with printf and printk (see appended files) and this is the output:
> > >>
> > >> 1:mrconfig:~ # latency
> > >> 2:xeno_init_private_heap
> > >> 3:map_sem_heap syscall 0
> > >> 4:xeno_map_heap open 3
> > >> 5:xnheap_ioctl private data: 00000000
> > >> 6:xeno_map_heap ioctl 0 handle 0xc7dd9210
> > >> 7:xnheap_mmap 00000000 00000000
> > >> 8:xeno_map_heap 0xffffffff
> > >> 9:Xenomai: mmap local sem heap: No such device or address
> > >> 10:mrconfig:~ #
> > >>
> > >>
> > >> It looks like (if I figured it out correctly) as if in function sem_heap.c->xeno_map_heap()  (which is called from xeno_init_privat_heap() via function map_sem_heap())  the ioctl-Call fails. 
> > >> xeno_map_heap() passes correctly an argument unequal NULL as third parameter to ioctl() (line6), but in kernel space function xnheap_ioctl() the 3. parameter arrives as NULL(line 5). This sets file->private_data to NULL which in turn lets xnheap_mmap() fail, as this function expects file->private_data != NULL (line7).
> > >> Therefore xnheap_mmap() returns -ENIXIO to xeno_map_heap() which outputs the error message " Xenomai: mmap local sem heap: No such device or address".
> > >> The one million dollar question is, why the 3. parameter of ioctl() mutates to NULL. Any idea?
> > >>
> > >> If I can do anything else, let me know.
> > >>
> > > 
> > > You will need these patches to run linux 2.4.25 over 2.5.6. The first
> > > one fixes the ioctl() issue.
> > > http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=c2a24b90667e12d0614e5d8442dba74f137f9d4d
> > > http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=bebc2a8e6b430c99041800330dc6061665371d90
> > > 
> > > Note: the switch test does not seem to be running correctly on my
> > > icecube (albeit the latency one does), somehow linux reschedule events
> > > get lost. For this reason, I would not consider the current state as
> > > being production-grade.
> > 
> > How do you see that reschedule events are lost? Does this happen also on
> > other systems?
> > 
> 
> nios2, x86_32, blackfin, arm11/mpcore, 85xx are all running the switch
> test fine over 2.5.x + 2.6 kernels. This tends to point the finger at an
> issue between the pipeline for 2.4/ppc and the real-time core.
> 

mpc52xx over 2.6 is ok as well, but not over 2.4. Something may be at
work in the pipeline code for 2.4.25.

-- 
Philippe.