Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Stelian Pop wrote:
Le dimanche 08 janvier 2006 à 18:56 +0200, Heikki Lindholm a écrit :
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'?
So it seems I'm not alone.
I have done some additionnal debugging on this issue in the last days. I
still haven't find the bug but I narrowed it down a bit.
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:
Hi guys, it's "/me too" time here for ppc. My mpc5200 board is jumping
out of the window when running "./latency -t1", while "./latency -t2"
works. No trace dump, hard freeze or spontaneous reboot, at your option.
OPT_NUCLEUS_DEBUG spits nothing. No issue with the regular user-space
test though.
x86 has no problem at all.
Ok, three smart guys, all having the same bug on their systems - who
will be first shouting "I got it"? If it's an issue in my code, I'm
going to pay you a beer (which I likely have to schedule already). ;)
Likely not this time (keep it cold anyway, who knows); I strongly suspect a bug in
xnarch_switch_to() for all archs but x86 which causes the sampling task code to be
spuriously rescheduled over the root thread after a few rounds of
rtdm_task_sleep_until. This might happen when a user-space shadow attempts to
switch to a kernel-based task. Sounds rather worrying eh?! More later.
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
