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



Reply via email to