[LITMUS^RT] call for testing 3.10

[Björn Brandenburg]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20130721/c318c025/attachment.html>