Scheduler bug?

[Leon Pollak]

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 elprotech.com
> <mailto:Andrew.Sinclair at elprotech.com>>
>
> 	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 
know.


Really thanks!
-- 
Leon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090510/8b624a10/attachment.html>