On 6/14/2013 6:03 AM, Sebastian Huber wrote:
On 06/13/2013 11:30 PM, Joel Sherrill wrote:
Hi
Out of curiosity, did you hack confdefs.h to force this as the
scheduler in uniprocessor configurations to ensure it does
the correct things in that situation?
I hacked some things to run the tests with the new scheduler.
Unfortunately, I think this is an important thing to test but not
necessarily
what you want for systems.
I added also the
support for the preempt mode (this makes no sense on SMP).
Preemption (and timeslicing) still make sense. When a task is no
preempt, it
should stay on the core until it voluntarily blocks or makes itself
preemptible.
This effectively means the scheduler has to avoid kicking it off while
no preempt.
Does the scheduler take into account "time on CPU" when considering
tasks of equal priority? It should evict the one which has been executing
the longest.
The following tests
fail:
sp02 - This is a bug in the test. I will send a fix.
sp66 - I think there is a bug in the test.
spfatal03 - Fails due to RTEMS_SMP is defined.
tm20 - Didn't look at it since this test tinkers with internal variables.
tm27 - Ditto.
The test sp66 checks the priority ceiling protocol. The problem is that the
driver task has preemption disabled:
[...]
sleep(1);
puts( "Calling semaphore release" );
status = rtems_semaphore_release( Mutex_id );
directive_failed( status, "rtems_semaphore_release" );
To make sure the priority ceiling works, we have to check that Task_1 actually
runs which is impossible since Init has preempt disabled.
puts( "*** END OF TEST 65 ***" );
rtems_test_exit(0);
[...]
Does sp66 run with the uniprocessor schedulers?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
