Scheduler bug?

Leon Pollak leonp at
Sun May 10 13:49:29 UTC 2009

On Sunday May 10 2009, Joel Sherrill wrote:
> So they are OK with changing the hardware clock on a tested unit and
> invalidating all testing but not upgrading the software.  Any change on
> a validated system is a change.
Well, Korean AirForce - are not ordinary people...:-)
May be I do not know everything - this is what I was told...

> We will have to use the collective RTEMS memory on this one.  I recall
> a bug that does sound like this.
> 2005-08-17	Andrew Sinclair <Andrew.Sinclair at
> <mailto:Andrew.Sinclair at>>
> 	PR 807/rtems
> 	* rtems/src/timerfireafter.c, rtems/src/timerserverfireafter.c,
> 	score/src/watchdoginsert.c: Tighten critical section checks on an ISR
> 	using the same timer being inserted by a lower priority ISR or
> 	interupt task.
> Does this sound like it?  It was fixed in 4.6.4 (not 4.6.2)
Hmm... Well.... I don't know... May be yes...

> This only impacted 3 files so is no more of a change than increasing the
> clock frequency.  
Joel, excuse me, I am not sure, I understand...
Do you say, that increasing clock frequency, for example, to 10ms per tick, 
will solve the problem and not make it less probable?

> How is it OK to (*&% with the hardware and not with the
> software.
> Change is (*^ change.
You are right.
I suppose that they were doing some kind of "stress test". But I really do not 

Really thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list