[LITMUS^RT] DEMO plugin problems

[Matteo Locatelli]

>That’s strange. Are you sure this happens only with the demo plugin? Is
liblitmus up-to-date? I don’t immediately see a reason why this >should
fail with the DEMO plugin.
>
>Nathan, did you happen to see anything like this? Can you reproduce this?

Yes, this happen only with the DEMO plugin.

>Did the tasks actually run? Most of the tracing happens in core LITMUS^RT
code (i.e., it’s independent of the plugin), so I don’t think this
>difference is due to tracing differences in the plugins.

Yes the task runs, I tried both with rtspin and rtlaunch; if I use the
instruction "rtspin -p 0 10 100 4" the task runs for 4 seconds then stops,
if I use rtlaunch with a simple hello world program it prints "Hello World"
so the task is running.

>The plotting script still is pretty much beta, so it doesn’t handle
unexpected data very gracefully. If you send me your traces I can take a
>look. Of course, you could try to debug this yourself and send a patch,
which would also be very much appreciated. ;-)

Ok, I send you the trace as an attachment. Thanks for your reply
Best regards
Matteo

2017-07-18 0:54 GMT+02:00 Björn Brandenburg <bbb at mpi-sws.org>:

> On 16. Jul 2017, at 11:04, Matteo Locatelli <matteo.locatelli1993 at gmail.
> com> wrote:
> > using the recently updated guide for the creation of a new Litmus
> plugin, I created the DEMO plugin which works correctly except for two
> things:
> > 1 - when I try to use the release_ts functionality, an error appears
> saying "wait_for_ts_release(): Function not implemented”
>
> That’s strange. Are you sure this happens only with the demo plugin? Is
> liblitmus up-to-date? I don’t immediately see a reason why this should fail
> with the DEMO plugin.
>
> Nathan, did you happen to see anything like this? Can you reproduce this?
>
> > 2 - when I use the st-trace-schedule functionality and run some
> processes using rtspin, the amount of bytes written to the traces are
> smaller then usual (72 bytes with the DEMO plugin, approximately 4000 bytes
> with the PSN-EDF scheduler)
>
> Did the tasks actually run? Most of the tracing happens in core LITMUS^RT
> code (i.e., it’s independent of the plugin), so I don’t think this
> difference is due to tracing differences in the plugins.
>
> > and if I try to draw the schedule using the st-draw functionality, it
> gives this error:
> >
> > Traceback (most recent call last):
> >   File "/opt/feather-trace-tools/st-draw", line 146, in <module>
> >     main()
> >   File "/opt/feather-trace-tools/st-draw", line 136, in main
> >     sched_trace.draw.render(opts, trace)
> >   File "/opt/feather-trace-tools/sched_trace/draw.py", line 282, in
> render
> >     y   = ypos(task_idx[pid] + 1)
> > KeyError: 2741
>
> The plotting script still is pretty much beta, so it doesn’t handle
> unexpected data very gracefully. If you send me your traces I can take a
> look. Of course, you could try to debug this yourself and send a patch,
> which would also be very much appreciated. ;-)
>
> - 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/20170718/838b6e68/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schedule_host=litmus_scheduler=DEMO_trace=my-trace_cpu=0.bin
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20170718/838b6e68/attachment.bin>