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, [email protected] > > > 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. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
