On Fri, Jun 14, 2013 at 11:16 AM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > 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. > Why?
> >> 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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel