There was a discussion on the developers list last week or the week
before
about a subtle race condition that arose when an interrupt occurred at
the
exact instant that a single thread called a blocking primitive and the
scheduler was busy transitioning to the idle thread. See
http://ecos.sourceware.org/ml/ecos-devel/2006-01/msg00000.html for more
details. Nick posted a patch, which I presume was applied to the CVS
tree.
You could try applying his patch yourself or updating to the latest CVS
tree
(and seeing if the tree does, in fact, include his patch).
It is unlikely that this is the problem. The bug I fixed was a failure
to call DSRs during the initial context switch to a newly created
thread. In any case that only delayed the DSR until the next scheduler
unlock, it didn't lose the DSR entirely. The program that showed the
problem was somewhat unusual in that it had nothing else to do until
the DSR ran.
As for the reported problem. I cannot think of anything that might be
causing a DSR to be lost entirely. The code dealing with all of this
has been thoroughly exercised over many years and has been the subject
of much scrutiny. I'm as certain as anyone can be that it is
correct. If there were a race condition anywhere in here then I would
expect it to have manifested itself elsewhere before now.
Actually I can think of one reason why races may be introduced
unexpectedly. This is if the compiler is reordering instructions
incorrectly and moving things across barriers that it should not. In
particular if it is not honouring the volatile nature of the asm
inlines that enable and disable interrupts.
I don't know what version of the compiler you are using, but it might
be instructive to see if a different version exhibits different
behaviour. However, we have never seen any problems like this, so I am
really clutching at straws here.