[LITMUS^RT] call for testing 3.10

[Jeff Zhou]

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