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:r...@xenomai.org] > Gesendet: Samstag, 18. Juni 2011 16:22 > An: Gilles Chanteperdrix > Cc: Wildenburg, Roderik RAEK1 MRA; xenomai-help@gna.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.wildenb...@manroland.com > > > 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 _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
