Jan Kiszka kirjoitti:
Heikki Lindholm wrote:


Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel
mode benchmarking for ppc64. Previously klatency worked fine, but now
latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending
patches a comin'?

Nope, it should work as it is. But as Stelian also reported problems on
his fresh ARM port with the in-kernel test, I cannot exclude that there
/might/ be a problem in the benchmark.

As I don't have any ppc64 hanging around somewhere, we will have to go
through this together. Things I would like to know:

Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;)

 o When and how does it crash? At start-up immediately? Or after a

I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die.

 o Are there any details / backtraces available with the crash?

Becaktrace limits to xnpod_schedule if I remember right.

 o Does -t2 work?

Umm. Probably not. See below.

 o What happens if your disable "rtdm_event_pulse(&ctx->result_event);"
   in eval_outer_loop (thus no signalling of intermediate results during
   the test)? Does it still crash, maybe later during cleanup now?

Doesn't freeze and can be exited with ctrl-c and even re-run.

One odd thing (probably unrelated) is that the first two ioctls get called in what seems like wrong order, eg. START_TMTEST first ends up in tmbench_ioctl_rt and then _nrt and INTERM_RESULT ends up first in _nrt and then _rt.

-- Heikki Lindholm

Xenomai-core mailing list

Reply via email to