[LITMUS^RT] call for testing 3.10

Mon Jul 22 04:52:51 CEST 2013

Hi Daneil,

Your suggestion is good. The GSN-EDF plugin works fine after the config.
And I tested all the sched plugins:

(gdb) p testsuite
$3 = {{plugin = 0x40c9e7 "PFAIR", testcases = 0x60f380, num_cases = 8}, {
    plugin = 0x40c9ed "C-EDF", testcases = 0x60f3a0, num_cases = 8}, {
    plugin = 0x40c9f3 "P-FP", testcases = 0x60f3c0, num_cases = 34}, {
    plugin = 0x40c9f8 "LINUX", testcases = 0x60f450, num_cases = 7}, {
    plugin = 0x40c9fe "GSN-EDF", testcases = 0x60f480, num_cases = 11}, {
    plugin = 0x40ca06 "PSN-EDF", testcases = 0x60f4c0, num_cases = 17}}

Environment:
Intel(R) Pentium(R) CPU 2117U @ 1.80GHz Dual-Core
4G RAM laptop

./setsched PFAIR; ./runtests
** Result: 8 ok, 0 failed.

./setsched C-EDF; ./runtests
** Result: 8 ok, 0 failed.

./setsched P-FP; ./runtests
** Result: 31 ok, 3 failed.

./setsched LINUX; ./runtests
Error: Setting new plugin failed.

./setsched GSN-EDF; ./runtests
** Result: 11 ok, 0 failed.

./setsched PSN-EDF; ./runtests
** Result: 16 ok, 1 failed.

There are few fails, I cut off the detailed log, otherwise, a lot too long.
Before moving into details and debug, if it is still the config issue,
please let me know.

Thanks
Jeff

On Sun, Jul 21, 2013 at 7:42 PM, Daniel Bristot de Oliveira <
danielbristot at gmail.com> wrote:

> Hi Jeff,
>
> As Bjorn said, my problem was in my kernel config. By default, the options:
>
> LITMUS^RT  ---> Real-Time Synchronization  ---> "Non-preemptive section
> support" and "Support for real-time locking protocols"
>
> are disable. After enable both and recompile the kernel, the test runs
> without errors.
>
> Perhaps, change the default for "config NP_SECTION" and "config
> LITMUS_LOCKING" to "y" on file litmus/Kconfig will make life easier for
> guys like me, who are starting with Litmys^RT. But, may have a good reason
> to the default be 'n', then, it is only a suggestion.
>
> Good night :-) (I'm in UTC-3).
>
>
>
> On Sun, Jul 21, 2013 at 2:39 PM, Jeff Zhou <jeffzhou.us at gmail.com> wrote:
>
>> Hi, Björn:
>>
>> I see similar runtest log in rebased-3.10, like Daniel's work in 3.8.13,
>> after./setsched GSN-EDF
>>
>> Will the next the step be to push on this branch and attempt fixing,
>> until pass all the tests?
>>
>> Regards,
>> Jeff
>>
>>
>>
>> On Sun, Jul 21, 2013 at 7:01 AM, Björn Brandenburg <bbb at mpi-sws.org>wrote:
>>
>>>
>>> On Jul 19, 2013, at 7:44 PM, Daniel Bristot de Oliveira <
>>> danielbristot at gmail.com> wrote:
>>>
>>>
>>> I'm in a meeting, away from my desk, and from Xeon too. But I build the
>>> LITMUS rebased-3.8.13 on a VM (KVM) on my notebook and run the test:
>>>
>>> [root at localhost liblitmus]# ./setsched GSN-EDF
>>> [root at localhost liblitmus]# ./runtests
>>> ** LITMUS^RT test suite.
>>> ** Running tests for GSN-EDF.
>>> ** Testing: reject invalid rt_task pointers... ok.
>>> ** Testing: reject invalid rt_task values... ok.
>>> ** Testing: reject job control for non-rt tasks... ok.
>>> ** Testing: children of RT tasks are not automatically RT tasks... ok.
>>> ** Testing: tasks have write access to /dev/litmus/ctrl mappings... ok.
>>> ** Testing: admission control handles suspended tasks correctly... ok.
>>> ** Testing: admission control handles running tasks correctly... ok.
>>> ** Testing: FMLP no nesting allowed...
>>> !! TEST FAILURE od = open_fmlp_sem(fd, 0) -> -1, Invalid argument
>>>    at tests/nesting.c:18 (test_lock_fmlp_nesting)
>>>    in task PID=729
>>> ** Testing: reject invalid object descriptors...
>>> !! TEST FAILURE litmus_lock(3) -> -1, Function not implemented
>>> (expected: EINVAL)
>>>    at tests/fdso.c:34 (test_invalid_od)
>>>    in task PID=730
>>> ** Testing: reject invalid object types... ok.
>>> ** Testing: don't inherit FDSO handles across fork...
>>> !! TEST FAILURE od = open_fmlp_sem(fd, 0) -> -1, Invalid argument
>>>    at tests/fdso.c:62 (test_not_inherit_od)
>>>    in task PID=732
>>> ** Testing: don't let best-effort tasks lock FMLP semaphores...
>>> !! TEST FAILURE od = open_fmlp_sem(fd, 0) -> -1, Invalid argument
>>>    at tests/locks.c:16 (test_not_lock_fmlp_be)
>>>    in task PID=733
>>> ** Testing: FMLP acquisition and release...
>>> !! TEST FAILURE od = open_fmlp_sem(fd, 0) -> -1, Invalid argument
>>>    at tests/locks.c:91 (test_lock_fmlp)
>>>    in task PID=734
>>> ** Result: 8 ok, 5 failed.
>>>
>>> Dmesg:
>>>
>>> [  220.569011] Switching to LITMUS^RT plugin GSN-EDF.
>>> [  226.070144] Setting up rt task parameters for process 719.
>>> [  226.070149] Setting up rt task parameters for process 719.
>>> [  226.072635] Setting up rt task parameters for process 720.
>>> [  226.072638] litmus: real-time task 720 rejected because task density
>>> > 1.0
>>> [  226.072640] Setting up rt task parameters for process 720.
>>> [  226.072641] Setting up rt task parameters for process 720.
>>> [  226.072642] litmus: real-time task 720 rejected because task density
>>> > 1.0
>>> [  226.072643] Setting up rt task parameters for process -1.
>>> [  226.072644] Setting up rt task parameters for process 720.
>>> [  226.076256] Setting up rt task parameters for process 722.
>>> [  226.381512] Setting up rt task parameters for process 726.
>>> [  226.597153] Setting up rt task parameters for process 728.
>>> [  226.700791] Setting up rt task parameters for process 729.
>>> [  226.700810] get_inode_obj(ffff88003b7d3f28, 0, 0): couldn't find
>>> object
>>> [  226.708555] get_inode_obj(ffff88003b7d3f28, 0, 0): couldn't find
>>> object
>>> [  226.710410] get_inode_obj(ffff88003b7d3f28, 0, 0): couldn't find
>>> object
>>> [  226.712909] Setting up rt task parameters for process 734.
>>> [  226.712924] get_inode_obj(ffff88003b7d3f28, 0, 0): couldn't find
>>> object
>>>
>>>
>>>
>>> I think this is caused by your configurations. You need to enable
>>> locking support in the kernel for these tests to pass. The test suit is not
>>> clever enough to figure out whether the kernel has support compiled in.
>>>
>>>
>>>
>>>>
>>>> If everything works, the second step would be to build the branch that
>>>> includes PREEMPT_RT:
>>>>
>>>> https://github.com/LITMUS-RT/litmus-rt/commits/rebased-3.8.13-rt14
>>>>
>>>
>>>> And then debug it… I assume we are breaking some PREEMPT_RT assumptions
>>>> that will need fixing. If you have experience with PREEMPT_RT, you could
>>>> help us out by suggesting fixes for bugs in LITMUS^RT.
>>>>
>>>>
>>> I use the PREEMPT RT it at work, I work in a R&D lab, developing
>>> telecommunication devices. On my Ms, I'm developing a new ftrace tracer
>>> plugin, and I'm using and analyzing the kernel with PREEMPT RT.  I know how
>>> it works, the difference between the vanilla and the Preempt RT and some
>>> implementations, like the rt\_spinlocks.
>>>
>>> I'm sorry, in advance, if I'm a little late in the answers, I work 44
>>> hours/week and I'm finishing my ms degree, then, I'm a little busy... But I
>>> really want to find time to help.
>>>
>>>
>>>
>>>> For example, rt_domain.c calls hrtimer_cancel() while (indirectly)
>>>> holding a run queue lock. This works fine in mainline, but causes a
>>>> recursive locking problem in PREEMPT_RT. Once that is fixed, I'm sure there
>>>> will be more that breaks.
>>>>
>>>>
>>> If I can reproduce this on some machine here, I would like to debug, on
>>> this kind of bugs is where the fun lives :-)
>>>
>>>
>>> Excellent, thank you very much for your time and your help with
>>> debugging this!
>>>
>>> Thanks,
>>> Björn
>>>
>>>
>>>
>>> _______________________________________________
>>> litmus-dev mailing list
>>> litmus-dev at lists.litmus-rt.org
>>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>>
>>>
>>
>> _______________________________________________
>> litmus-dev mailing list
>> litmus-dev at lists.litmus-rt.org
>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>
>>
>
>
> --
> Daniel Bristot de Oliveira
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20130721/1f0cb41f/attachment.html>