leonp at plris.com
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 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
> Change is (*^ change.
You are right.
I suppose that they were doing some kind of "stress test". But I really do not
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users