[LITMUS^RT] call for testing 3.10

Mon Jul 22 02:42:25 CEST 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20130721/4d702f38/attachment.html>