Re: [Xenomai-core] latency kernel part crashes on ppc64

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]

Heikki Lindholm wrote:
> Jan Kiszka kirjoitti:
> 
>> Heikki Lindholm wrote:
>>
>>> Hi,
>>>
>>> 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'?
>>

To get this clearly: You tested the old klatency(+front-end) on latest
xeno and it worked? Or does this parse "the old klatency worked over old
xeno on PPC64"?

Comparing the old test with the new framework, the major difference is
that the old one only knew a single kernel RT-task. Its front-end was
reading from a pipe and was therefore a pure linux program. Now we have
two RT-tasks, one is even a shadow, and they use RT-IPC. Not sure if
this really means that the bug must be in the benchmark suite...

>>
>>
>> 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
>>    while?
> 
> 
> 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.

Arrgh, "probably" - when it's so easy to test...

When you are already on it: pure user-space (-t0) also works?

> 
>>  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.

This takes me back to the number of active real-time tasks during the
test. This disabling reduces the scenario basically again to old
klatency times.

I looked at my code again, but - maybe I'm too blind now - I cannot find
even a potential pointer bug, especially when the histogram feature (-h)
is not used. I need more input! ;)

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]