Re: Re: time is running out

> I have the same problem as reported about the speed of the clock
> (which seems to speed up to 2 or 3 times faster than should be) when
> rtl_sched is loaded on a number of configurations on 2 boxes I test
> rtlinux on.  Here is one of the latest configs which the problem
> appears with.  This problem also happens when none of the experimental
> optimizations are set.  Happens with both gcc 2.95.3 and 3.3.4.
> ps: Also setting PSC causes regression.sh to segfault and the module
> becomes unremove-able.  I think I had read something about PSC being
> broken at some point but I'm not sure...
>

Hi All !

 the problem must have apeard quite some time back - no idea why I never noticed
 it - at some point I changed the HZ variable in include/asm-i368/param.h from 
 100 to 1000 (guese whyle trying to reduce the delays of soft-irqs). This change
 is what is causing the time to advance incorectly as the HZ variable in rtlinux
 is assumed to be 100 at a few points (which is definitly a bug in rtlinux).

 quick-fix - correct the line in param.h

include/asm-i386/apram.h (quite at the top of file)
#define HZ 1000 -> #define HZ 100

 will give rtlinux a scan to find the potentially problematic code and make it
 HZ clean....TODO++

 The second problem (and that should only be in the latest rc1 tree): the 
 interrupts emulatoin was changed to trigger the linux side unconditionally
 which was a hack to kick soft-irq with a low latency independant from the 
 occurance of hardwar interrupts, and secondly the pending of irqs to linux
 unconditionally to allow sharing of irqs.

 patch to rc1 applied - pleas pull the updates from cvs !

 let me know if this does't solves the problem for you (time was roughly 2-3 
 times faster with the wrong HZ variable and is now constant against my ntp 
 server running for about 2h).

thx !
hofrat
_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl