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