Hi,
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
Stefan Sommerfeld [EMAIL PROTECTED] writes:
I'm using a self-compiled gcc 3.4.3 for xscale. I'll try to compile a
different version to check if this helps. I'll also try to setup a
test system which should trigger this problem faster (not 24 hours) to
do some more investigation.
You could
I am experiencing a problem with a serial driver that I'm developing. It
uses separate RX and TX ISRs and DSRs. The RX and TX ISRs just schedule the
corresponding DSR to run.
The test begins by transmitting data, which is looped back to the receiver.
It starts out with:
TX ISR - TX DSR
The test begins by transmitting data, which is looped back to the receiver.
It starts out with:
TX ISR - TX DSR
TX ISR - TX DSR
...
TX-ISR - TX DSR
Then I get the RX ISR during the TX DSR, which just schedules
the RX DSR. However, the RX DSR does not run until 39
On 2006-01-14, Jay Foster [EMAIL PROTECTED] wrote:
I still think that FIFO queuing of the DSRs is better than
LIFO queuing, because in the absence of any DSR priority
information, the best that can be done is temporal priority
(ie FIFO).
That happens to work for your application, but I don't
From: Grant Edwards
I still maintain that your application is either broken or you
don't have enough CPU. If one interrupts source requires so
much DSR time that others can't run, then there is simply
something wrong. You seem to prefer a tx underrun error to an
rx overrun error. I
On 2006-01-14, Paul D. DeRocco [EMAIL PROTECTED] wrote:
I still maintain that your application is either broken or you
don't have enough CPU. If one interrupts source requires so
much DSR time that others can't run, then there is simply
something wrong. You seem to prefer a tx underrun
