Jan Kiszka wrote:
Yep, I dug deeper meanwhile and also came across this.
I already have a trivial hack running here. The most tricky part for me
was to learn quilt, but now I start to love it :). Here is a snapshot
series for 2.6.15.5:
kgdb series from CVS
prepare-ipipe-x86.patch
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
debugging is nice, tracing is still nicer. As you suggested, I extended
the tracer with per-domain stall flags (needs some output clean-up,
preliminary patch attached nevertheless).
And here is the result (full trace attached):
:|(0x51)
Niklaus Giger wrote:
Am Samstag, 8. April 2006 10:44 schrieb Jan Kiszka:
Niklaus Giger wrote:
Hi everybody
..
This is a really great idea! Of course, I already have another test
candidate in mind: RTnet 8). Specifically the PPC environment would be
interesting, as our buildbot (sorry,
Hi Philippe,
here is a tiny patch to re-trigger trace freezing by writing a positive
number to /proc/ipipe/trace/frozen. Writing 0 provides the old
behaviour, i.e. resets the frozen trace so that ipipe_trace_freeze() can
capture a new trace.
Please apply.
Jan
Index:
Jan Kiszka wrote:
Hi,
this is the preliminary, though already usable result of my recent
effort to extend the tool situation for Xenomai: A kgdb patch series for
2.6.15 on x86. It already works quite well but likely does not yet catch
all fatal scenarios (e.g. page faults in the Xenomai
Jan Kiszka wrote:
Hi,
as promised, here is the patch to extend the I-ipipe trace so that it
displays also the domain stall flags of the first 4 domains (I don't
expect more in practice yet ;) ). The information is shown if you switch
on the verbose mode (echo 1 /proc/ipipe/tracer/verbose).
Jan Kiszka wrote:
Hi Philippe,
here is a tiny patch to re-trigger trace freezing by writing a positive
number to /proc/ipipe/trace/frozen. Writing 0 provides the old
behaviour, i.e. resets the frozen trace so that ipipe_trace_freeze() can
capture a new trace.
Please apply.
Applied, thanks.
I tried latency -t 1 on an SMP machines, and observed a very
reproducible crash. Most of the time, the machine locks up
completely. The rest of the time, I get :
Xenomai: suspending kernel thread e7559044 ('timerbench') at 0xb01051f2 after ex
ception #14
And the system remains runnable, but
Gilles Chanteperdrix wrote:
I tried latency -t 1 on an SMP machines, and observed a very
reproducible crash. Most of the time, the machine locks up
completely. The rest of the time, I get :
Xenomai: suspending kernel thread e7559044 ('timerbench') at 0xb01051f2 after
ex
ception #14
And
The following patch enables GDB 6.x for the simulator. Please give this
a try if you happen to use the Xenosim. TIA,
--- sim/scope/gdbhelper.cc (revision 904)
+++ sim/scope/gdbhelper.cc (working copy)
@@ -423,6 +423,8 @@
char *ibuf = gdb_ibuf.gets(), *estart = gdb_ibuf.gets();
Jan Kiszka wrote:
Niklaus Giger wrote:
Am Samstag, 8. April 2006 10:44 schrieb Jan Kiszka:
Niklaus Giger wrote:
Hi everybody
..
This is a really great idea! Of course, I already have another test
candidate in mind: RTnet 8). Specifically the PPC environment would be
interesting, as our
Hi,
this patch adds xnlogerr to the XENO_ASSERT macro, making the failure
visible so that the user does not have to bother. Furthermore, it adds
panic tracing.
Tested and found useful with latest RTDM debugging, ok to apply?
Jan
Index: include/rtdm/rtdm_driver.h
Gilles Chanteperdrix wrote:
I tried latency -t 1 on an SMP machines, and observed a very
reproducible crash. Most of the time, the machine locks up
completely. The rest of the time, I get :
Xenomai: suspending kernel thread e7559044 ('timerbench') at 0xb01051f2 after ex
ception #14
And the
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi,
this is the preliminary, though already usable result of my recent
effort to extend the tool situation for Xenomai: A kgdb patch series for
2.6.15 on x86. It already works quite well but likely does not yet catch
all fatal scenarios (e.g. page faults in
14 matches
Mail list logo
