[Xenomai-core] [PATCH] pid and current-domain tracing
Hi,
here are three patches, two enhancing the ipipe tracer, the third
propagating the new features to Xenomai.
The tracer gains support for recording a Linux pid + a priority value.
The priority can be set to an arbitrary value (12 bit, signed), but will
typically be related to the pid. When the tracer's verbose mode is
active, it tries to resolve the pid to a task_struct and prints the
first chars of the command line followed by the priority in the related
lines.
This feature is applied to Xenomai for tracing RT-task switches and
wakeups. Kind of poor man's LTT, but with the advantage of per-function
tracing. I already used this while trying to understand my
prio-inversion issue.
Finally, the tracer is enhanced by a facility to track the currently
active ipipe domain. The field for displaying domain stall flags is
reused for this.
Some example from my Pentium-133 box:
> I-pipe frozen back-tracing service on 2.6.16.16/ipipe-1.3-05
>
> Freeze: 6070092534285 cycles, Trace Points: 1000 (+10)
>
> +- Hard IRQs ('|': locked)
> |+
> ||+---
> |||+-- Xenomai
> +- Linux ('*': domain stalled, '+': current, '#': current+stalled)
> |+-- Delay flag ('+': > 1 us, '!': > 10
> us)
> ||+- NMI noise ('N')
> |||
> TypeUser Val. TimeDelay Function (Parent)
> :+func -3221+ 2.105 n_tty_set_room+0x8
> (n_tty_receive_buf+0xe4b)
> :+func -3219+ 2.060 kill_fasync+0x9
> (n_tty_receive_buf+0xe78)
> :+func -3217+ 1.458 __wake_up+0xe
> (n_tty_receive_buf+0xe97)
> :+func -3216+ 2.421 __ipipe_test_and_stall_root+0x8
> (__wake_up+0x1a)
> :#func -3213+ 2.135 __wake_up_common+0xe (__wake_up+0x50)
> :#func -3211+ 6.090 default_wake_function+0x8
> (__wake_up_common+0x33)
> :| #func -3205+ 2.676 __ipipe_handle_irq+0xe
> (common_interrupt+0x18)
> :| #func -3203+ 2.360 __ipipe_ack_common_irq+0xa
> (__ipipe_handle_irq+0x80)
> :| #func -3200+ 3.428
> ipipe_test_and_stall_pipeline_from+0x8 (__ipipe_ack_common_irq+0x16)
> :| #func -3197+ 4.511 mask_and_ack_8259A+0xb
> (__ipipe_ack_common_irq+0x3f)
> :| #func -3192+ 2.571 __ipipe_dispatch_wired+0xe
> (__ipipe_handle_irq+0x8a)
> :| #*func -3190+ 2.766 xnintr_irq_handler+0xb
> (__ipipe_dispatch_wired+0x7d)
> :| #*func -3187+ 4.902 rt_irqbench_task_irq+0xa
> [xeno_irqbench] (xnintr_irq_handler+0x24)
> :| #*func -3182+ 3.451 rtdm_event_signal+0x9
> (rt_irqbench_task_irq+0x46 [xeno_irqbench])
> :| #*func -3179+ 3.796 xnsynch_flush+0xe
> (rtdm_event_signal+0x2d)
> :| #*func -3175+ 3.263 xnpod_resume_thread+0xe
> (xnsynch_flush+0x76)
> :| #*[ 922] irqloop 99 -3171+ 4.375 xnpod_resume_thread+0x48
> (xnsynch_flush+0x76)
> :| #*func -3167+ 2.992 xnpod_schedule+0xe
> (rtdm_event_signal+0x36)
> :| #*func -3164+ 2.511 rthal_irq_end+0x8
> (xnintr_irq_handler+0x41)
> :| #*func -3162+ 3.969 enable_8259A_irq+0x9
> (rthal_irq_end+0x2e)
> :| #*func -3158+ 2.511 xnpod_schedule+0xe
> (xnintr_irq_handler+0x5f)
> :| #*[0] swapper 0 -3155+ 8.669 xnpod_schedule+0x82
> (xnintr_irq_handler+0x5f)
> :| #*func -3146+ 7.766 __switch_to+0xe
> (xnpod_schedule+0x5e8)
> :| #*[ 922] irqloop 99 -3139+ 6.992 xnpod_schedule+0x6bc
> (xnpod_suspend_thread+0xed)
> :| #*func -3132! 18.015 __ipipe_restore_pipeline_head+0x8
> (rtdm_event_timedwait+0xea)
> : +*func -3114+ 2.774 __ipipe_syscall_root+0x9
> (system_call+0x20)
> : +*func -3111+ 2.323 __ipipe_dispatch_event+0xe
> (__ipipe_syscall_root+0x55)
> : +*func -3109+ 4.676 hisyscall_event+0xe
> (__ipipe_dispatch_event+0x5e)
> : +*func -3104+ 2.135 sys_rtdm_ioctl+0x8
> (hisyscall_event+0x140)
> : +*func -3102+ 2.157 _rtdm_ioctl+0xe (sys_rtdm_ioctl+0x16)
> : +*func -3100+ 2.052 rtdm_context_get+0x9
> (_rtdm_ioctl+0x1f)
Jan
---
include/linux/ipipe_trace.h |3 -
kernel/ipipe/tracer.c | 129 ++--
2 files changed, 102 insertions(+), 30 deletions(-)
Index: linux-2.6.16.16/include/linux/ipipe_trace.h
===
--- linux-2.6.16.16.orig/include/linux/ipipe_trace.h
+++ linux-2.6.16.16/include/linux/ipipe_trace.h
@@ -2,7 +2,7 @@
* include/linux/ipipe_trace.h
*
* Copyright (C) 2005 Luotao Fu.
- * 2005 Jan Kiszka.
+ * 2005, 2006 Jan Kiszka.
*
* This program is free software; you
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
Here comes an update of the irqbench patch.
Changelog:
- avoid printf from signal context in irqloop
- reorder irq-enable code in the driver to avoid spurious replies on
startup
- avoid creating/destroying pthread under SCHED_FIFO (but still suffers
from prio inversion during cleanup here)
- fix broken conditional compilation of irqbench for x86 (probably
unnoticed due to forgotten bootstrap run, sigh)
- include irqbench-doc.patch
Jan
Subject: Introduce IRQ latency benchmark
This patch introduces another rttesting driver, xeno_irqbench, for measuring external IRQ latencies. The irqbench device is controlled by a user-mode tool irqloop. A second tool for plain Linux, irqbench, is provided to trigger the event over serial or parallel cross-link (the latter is incomplete yet) and measure the reaction latency.
---
configure.in |2
doc/txt/Makefile.am|1
doc/txt/irqbench.txt | 51
include/rtdm/rttesting.h | 38 ++
ksrc/drivers/Makefile |2
ksrc/drivers/testing/Kconfig | 21 +
ksrc/drivers/testing/Makefile | 13 -
ksrc/drivers/testing/irqbench.c| 470 +
src/testsuite/Makefile.am |2
src/testsuite/irqbench/Makefile.am | 47 +++
src/testsuite/irqbench/irqbench.c | 306
src/testsuite/irqbench/irqloop.c | 173 +
src/testsuite/irqbench/runinfo |1
13 files changed, 1116 insertions(+), 11 deletions(-)
Index: xenomai/include/rtdm/rttesting.h
===
--- xenomai.orig/include/rtdm/rttesting.h
+++ xenomai/include/rtdm/rttesting.h
@@ -94,6 +94,28 @@ typedef struct rttst_tmbench_config {
} rttst_tmbench_config_t;
+#define RTTST_IRQBENCH_USER_TASK0
+#define RTTST_IRQBENCH_KERNEL_TASK 1
+#define RTTST_IRQBENCH_HANDLER 2
+
+#define RTTST_IRQBENCH_SERPORT 0
+#define RTTST_IRQBENCH_PARPORT 1
+
+struct rttst_irqbench_config {
+int mode;
+int priority;
+int calibration_loops;
+unsigned intport_type;
+unsigned long port_ioaddr;
+unsigned intport_irq;
+} rttst_irqbench_config_t;
+
+struct rttst_irqbench_stats {
+unsigned long long irqs_received;
+unsigned long long irqs_acknowledged;
+} rttst_irqbench_stats_t;
+
+
#define RTTST_SWTEST_FPU0x1
#define RTTST_SWTEST_USE_FPU0x2 /* Only for kernel-space tasks. */
@@ -134,6 +156,22 @@ struct rttst_swtest_dir {
_IOWR(RTIOC_TYPE_TESTING, 0x11, struct rttst_overall_bench_res)
+#define RTTST_RTIOC_IRQBENCH_START \
+_IOW(RTIOC_TYPE_TESTING, 0x20, struct rttst_irqbench_config)
+
+#define RTTST_RTIOC_IRQBENCH_STOP \
+_IO(RTIOC_TYPE_TESTING, 0x21)
+
+#define RTTST_RTIOC_IRQBENCH_GET_STATS \
+_IOR(RTIOC_TYPE_TESTING, 0x22, struct rttst_irqbench_stats)
+
+#define RTTST_RTIOC_IRQBENCH_WAIT_IRQ \
+_IO(RTIOC_TYPE_TESTING, 0x23)
+
+#define RTTST_RTIOC_IRQBENCH_REPLY_IRQ \
+_IO(RTIOC_TYPE_TESTING, 0x24)
+
+
#define RTTST_RTIOC_SWTEST_SET_TASKS_COUNT \
_IOW(RTIOC_TYPE_TESTING, 0x30, unsigned long)
Index: xenomai/configure.in
===
--- xenomai.orig/configure.in
+++ xenomai/configure.in
@@ -82,6 +82,7 @@ case "$host" in
esac
AC_MSG_RESULT([$XENO_TARGET_ARCH])
+AM_CONDITIONAL(XENO_TARGET_ARCH_I386,[test $XENO_TARGET_ARCH = i386])
dnl
dnl Parse options
@@ -602,6 +603,7 @@ AC_CONFIG_FILES([ \
src/testsuite/switchbench/Makefile \
src/testsuite/cyclic/Makefile \
src/testsuite/switchtest/Makefile \
+ src/testsuite/irqbench/Makefile \
include/Makefile \
include/asm-generic/Makefile \
include/asm-blackfin/Makefile \
Index: xenomai/ksrc/drivers/Makefile
===
--- xenomai.orig/ksrc/drivers/Makefile
+++ xenomai/ksrc/drivers/Makefile
@@ -11,7 +11,7 @@ else
subdir-$(CONFIG_XENO_DRIVERS_16550A) += 16550A
subdir-$(CONFIG_XENO_DRIVERS_TIMERBENCH) += testing
-
+subdir-$(CONFIG_XENO_DRIVERS_IRQBENCH) += testing
subdir-$(CONFIG_XENO_DRIVERS_SWITCHTEST) += testing
include $(TOPDIR)/Rules.make
Index: xenomai/ksrc/drivers/testing/Kconfig
===
--- xenomai.orig/ksrc/drivers/testing/Kconfig
+++ xenomai/ksrc/drivers/testing/Kconfig
@@ -6,10 +6,19 @@ config XENO_DRIVERS_TIMERBENCH
Kernel-based benchmark driver for timer latency evaluation.
See testsuite/latency for a possible front-end.
+config XENO_DRIVERS_IRQBENCH
+ depends on XENO_SKIN_RTDM
+ tristate "IRQ benchmark driver"
+ default n
+ help
+ Loopback driver for IRQ latency evaluation over serial or parallel
+ port links. Additionally requires user-space helper and a logging tool
+ (see testsuite/irqbench).
+
co
Re: [Xenomai-core] [PATCH 4/6] Add prio switch to latency test
This is just a rebased version of the patch over revision #1275.
Jan
Subject: Add prio switch to latency test
Introduces -P switch to the latency test and extends xeno_timerbench to respect this for the kernel-based timer task as well. The patch also allows now to run multiple latency tests (both in-kernel and user-space) in parallel.
---
include/rtdm/rttesting.h |1 +
ksrc/drivers/testing/timerbench.c |4 ++--
src/testsuite/latency/latency.c | 20
3 files changed, 19 insertions(+), 6 deletions(-)
Index: xenomai/include/rtdm/rttesting.h
===
--- xenomai.orig/include/rtdm/rttesting.h
+++ xenomai/include/rtdm/rttesting.h
@@ -86,6 +86,7 @@ typedef struct rttst_overall_bench_res {
typedef struct rttst_tmbench_config {
int mode;
uint64_tperiod;
+int priority;
int warmup_loops;
int histogram_size;
int histogram_bucketsize;
Index: xenomai/ksrc/drivers/testing/timerbench.c
===
--- xenomai.orig/ksrc/drivers/testing/timerbench.c
+++ xenomai/ksrc/drivers/testing/timerbench.c
@@ -305,7 +305,7 @@ int rt_tmbench_ioctl_nrt(struct rtdm_dev
ctx->mode = RTTST_TMBENCH_TASK;
ret = rtdm_task_init(&ctx->timer_task, "timerbench",
timer_task_proc, ctx,
- RTDM_TASK_HIGHEST_PRIORITY, 0);
+ config->priority, 0);
}
} else {
/* FIXME: convert to RTDM timers */
@@ -465,7 +465,7 @@ int rt_tmbench_ioctl_rt(struct rtdm_dev_
static struct rtdm_device device = {
struct_version: RTDM_DEVICE_STRUCT_VER,
-device_flags: RTDM_NAMED_DEVICE | RTDM_EXCLUSIVE,
+device_flags: RTDM_NAMED_DEVICE,
context_size: sizeof(struct rt_tmbench_context),
device_name:"",
Index: xenomai/src/testsuite/latency/latency.c
===
--- xenomai.orig/src/testsuite/latency/latency.c
+++ xenomai/src/testsuite/latency/latency.c
@@ -34,6 +34,7 @@ int quiet = 0; /* suppress prin
int benchdev_no = 0;
int benchdev = -1;
int freeze_max = 0;
+int priority = T_HIPRIO;
#define USER_TASK 0
#define KERNEL_TASK 1
@@ -194,6 +195,7 @@ void display (void *cookie)
config.mode = RTTST_TMBENCH_HANDLER;
config.period = period_ns;
+config.priority = priority;
config.warmup_loops = WARMUP_TIME;
config.histogram_size = (do_histogram || do_stats) ? histogram_size : 0;
config.histogram_bucketsize = bucketsize;
@@ -424,7 +426,7 @@ int main (int argc, char **argv)
char task_name[16];
int cpu = 0;
-while ((c = getopt(argc,argv,"hp:l:T:qH:B:sD:t:fc:")) != EOF)
+while ((c = getopt(argc,argv,"hp:l:T:qH:B:sD:t:fc:P:")) != EOF)
switch (c)
{
case 'h':
@@ -487,6 +489,10 @@ int main (int argc, char **argv)
cpu = T_CPU(atoi(optarg));
break;
+case 'P':
+priority = atoi(optarg);
+break;
+
default:
fprintf(stderr, "usage: latency [options]\n"
@@ -501,7 +507,8 @@ int main (int argc, char **argv)
" [-D ] # number of testing device, default=0\n"
" [-t ] # 0=user task (default), 1=kernel task, 2=timer IRQ\n"
" [-f] # freeze trace for each new max latency\n"
-" [-c ] # pin measuring task down to given CPU\n");
+" [-c ] # pin measuring task down to given CPU\n"
+" [-P ] # task priority (test mode 0 and 1 only)\n");
exit(2);
}
@@ -529,6 +536,11 @@ int main (int argc, char **argv)
if (period_ns == 0)
period_ns = 10LL; /* ns */
+if (priority <= T_LOPRIO)
+priority = T_LOPRIO + 1;
+else if (priority > T_HIPRIO)
+priority = T_HIPRIO;
+
signal(SIGINT, sighand);
signal(SIGTERM, sighand);
signal(SIGHUP, sighand);
@@ -562,7 +574,7 @@ int main (int argc, char **argv)
rt_timer_set_mode(TM_ONESHOT); /* Force aperiodic timing. */
snprintf(task_name, sizeof(task_name), "display-%d", getpid());
-err = rt_task_create(&display_task,task_name,0,98,T_FPU);
+err = rt_task_create(&display_task,task_name,0,0,T_FPU);
if (err)
{
@@ -580,7 +592,7 @@ int main (int argc, char **argv)
if (test_mode == USER_TASK) {
snprintf(task_name, sizeof(tas
Re: [Xenomai-core] [PATCH 5/6] Overread dev-prefix on posix open
Update to fix a compiler warning (char * vs. const char *).
Jan
Subject: Overread dev-prefix on posix open
Adds support to the posix user-space lib to address RTDM-devices also with a (here meaningless) "/dev/" name prefix. Intended to increase user convenience slightly.
---
src/skins/posix/rtdm.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: xenomai/src/skins/posix/rtdm.c
===
--- xenomai.orig/src/skins/posix/rtdm.c
+++ xenomai/src/skins/posix/rtdm.c
@@ -41,10 +41,15 @@ static inline int set_errno(int ret)
int __wrap_open(const char *path, int oflag, ...)
{
int ret, oldtype;
+ const char *rtdm_path = path;
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
- ret = XENOMAI_SKINCALL2(__rtdm_muxid, __rtdm_open, path, oflag);
+ /* skip path prefix for RTDM invocation */
+ if (strncmp(path, "/dev/", 5) == 0)
+ rtdm_path += 5;
+
+ ret = XENOMAI_SKINCALL2(__rtdm_muxid, __rtdm_open, rtdm_path, oflag);
pthread_setcanceltype(oldtype, NULL);
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
Jan Kiszka wrote: > > > > Also note that calling printf from a signal handler risk deadlocking if > > the signal handler get called on the return path of the write call that > > take place in the middle of a printf call on the main thread. > > > > Ok, then we also need a fix for the latency test (this is where I > grabbed that pattern from). Is there a high risk that this locks up? I > wonder why I never observed or heard of problems with latency. The mutex used by the stdio lib depends on the file descriptor, so, it is possible to use a different file descriptor in the signal handler and on the interrupted context. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
On Wed, 2006-06-28 at 11:17 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-06-28 at 10:51 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
> plain text document attachment (enhance-kernel-fault-report.patch)
> Introduce xnarch_fault_um() to test if a fault happened in user-mode
> and applies the new feature to report core and driver crashes more
> verbosely.
> if (xnpod_shadow_p()) {
> #ifdef CONFIG_XENO_OPT_DEBUG
> -if (xnarch_fault_notify(fltinfo)) /* Don't report
> debug traps */
> +if (!xnarch_fault_um(fltinfo)) {
> +xnarch_trace_panic_freeze();
> >>> KGDB breakpoint issue?
> >> Sorry, please switch on verbose mode, didn't get yet what you mean.
> > Oops, sorry. I meant: what if a KGDB breakpoint is hit from kernel space
> > while running a shadow thread? The way I read the modified test sequence
> > above, such bp trap is going to trigger a panic, instead of being
> > silently passed to Linux.
> I would say: KGDB will not come along here with a breakpoint. It should
> already got involved in __ipipe_divert_exception().
> >>> Ok, so the only problem that remains would be inlined asm("int 1/3") in
> >>> kernel space not handled by KGDB (whether the KGDB patch is in or not).
> >>> I'm still scratching my head pondering if we can live with this or not.
> >> But this is perfectly one of the situations my patch tries to catch: a
> >> fatal bug in the kernel! Such a hand-coded kernel breakpoint without a
> >> debugger caring is a bug to me.
> >
> > Not that sure: passive debug code may exist. Only the presence of the
> > debugger should activate it.
> >
>
> ...but remains a bug for me /w RT code.
Someone inserting such passive breakpoints would have to know what she's
doing, in any case. Looking the relax counter in /proc/xenomai/stats
(which is among the first things to do when chasing unexpected
latencies) would also give a serious hint to the inattentive folks. What
bothers me is to restrict the usage one can do of debug vectors on
certain archs, just for the purpose of saving one's from careless
coding.
> We now complain about this
> exception happened. And there is no crash/BUG in this case, just a
> desirable warning with back-trace in the log.
>
Ok, If *_panic() routines do not actually panic at all, it's acceptable.
>
>
> PS: Other OSes show you a nice blue-screen when they ran on such
> orphaned breakpoints.
What other O/S do in this respect is not relevant; it's not an
inter-operability or compatibility issue between Xenomai and others,
it's a decision to make about which behaviour is the least intrusive wrt
debug strategies.
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
> > Then all other threads must block signal delivering with sigprocmask() > so that the main thread is the only one which "accepts" signals. Is that required, i.e. does pause() only wake up if the signal handler executed in the main thread's context? Then cyclictest contains a bug as well... If strictly speaking, then yes, it's required. But I expect your fix to be working perfectly, just because the current linux implementation always favors the main thread when it comes to choosing a thread to handle the signal. look at signal.c :: __group_complete_signal() routine where the actual magic happens. from the comments /* * Now find a thread we can wake up to take the signal off the queue. * * If the main thread wants the signal, it gets first crack. * Probably the least surprising to the average bear. */ ... As I understand, the only case when another thread may handle the signal indeed is when the main thread has already another pending signal. But even then nothing bad happens as pause() (in the main thread) will be interrupted by this pending signal. Just "finished" will be set up by some other thread but it doesn't really matter. -- Best regards, Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > > Is there no way to make this code easier to port for example by using > > > native or posix services for timings measurement and by abstracting the > > > non portable part and moving them to include/asm-i386 ? > > > > This tool is intentionally left Xenomai-free. You can put it on any x86 > > box around (and I assume that there is almost always some...) and run > > the test. Thus, no need for a second RT-patched system. > > > > Anyway, suggestions or patches to add a porting layer are welcome. The > > following points need to be addressed: time measuring, irq protection, > > hardware access. I just wonder if this is worth the effort. > > I do not understand: it appears to me that Xenomai trunk does not > compile on other architectures than x86 when applying the IRQ latency > benchmark patch. So, something needs to be done. It may be the enabling > of an automake conditional in configure.in when compiling for x86. > See the patch: Index: xenomai/src/testsuite/irqbench/Makefile.am === --- /dev/null +++ xenomai/src/testsuite/irqbench/Makefile.am @@ -0,0 +1,47 @@ +testdir = $(prefix)/testsuite/irqbench + +test_PROGRAMS = irqloop + +ifeq ($(XENO_TARGET_ARCH),i386) +test_PROGRAMS += irqbench +endif I just realised that some hint in the documentation that irqbench can easily be compiled outside Xenomai is required. > > > > > > > > Also note that calling printf from a signal handler risk deadlocking if > > > the signal handler get called on the return path of the write call that > > > take place in the middle of a printf call on the main thread. > > > > > > > Ok, then we also need a fix for the latency test (this is where I > > grabbed that pattern from). Is there a high risk that this locks up? I > > wonder why I never observed or heard of problems with latency. > > The latency test used to deadlock, that is why the summary printed on > signal is printed on stderr. Unfortunately, there seem to be one display > left on stdout, so it should still deadlock. The reason why we never see > the deadlock is (perhaps) that the continuous intermediate results are > printed on the context of the "display" thread, whereas the termination > signals are preferably delivered by the kernel to the "main" thread, > that only calls pause. Which makes the use of stderr in signals handlers > pointless. > > Anyway, since your program is frequently using printf on the context of > the main thread, the risk of deadlock is real. > Ok, I'm going to address this. Thanks for the hint! Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Prio-inversion on cleanup?
Jan Kiszka wrote: > Hi, > > could someone give this scenario a try (requires my recent patch series) > and tell me if you are also seeing excessive latencies: > > Start: > irqloop (+xeno_irqbench) -P 99 -t 0 > latency -p 200 -P 50 > > Terminate: > irqloop > > The termination seems to cause high latencies to the (then highest-prio) > periodic timer test. This does not happen with irqloop -t 1 > (kernel-based task), and I can reduce the effect by invoking > pthread_setschedparam(SCHED_NORMAL) for the irqloop test thread right > before termination. Also, running and terminating another latency > instance with prio 99 does not have this effect. > I extended the tracer with support for the new service ipipe_trace_pid(pid, priority); and recorded the following on irqloop cleanup: > : func -11679+ 2.661 sys_rtdm_close+0x8 > (losyscall_event+0xa3) > : func -11677+ 4.045 _rtdm_close+0xe > (sys_rtdm_close+0x11) > :| * func -11673+ 4.601 __ipipe_restore_pipeline_head+0x8 > (_rtdm_close+0x8c) > : func -11668+ 1.323 rt_irqbench_close+0x9 > [xeno_irqbench] (_rtdm_close+0xd1) > : func -11667+ 2.345 rt_irqbench_stop+0x9 > [xeno_irqbench] (rt_irqbench_close+0x21 [xeno_irqbench]) > : func -11664+ 3.383 _rtdm_synch_flush+0xa > (rt_irqbench_close+0x2e [xeno_irqbench]) > :| * func -11661+ 4.751 xnsynch_flush+0xe > (_rtdm_synch_flush+0x3b) > :| * func -11656+ 3.894 xnpod_resume_thread+0xe > (xnsynch_flush+0x76) > :| * func -11652+ 1.503 xnpod_schedule+0xe > (_rtdm_synch_flush+0x45) > :| * func -11651+ 2.932 ipipe_trigger_irq+0xc > (xnpod_schedule+0x29) > :| * func -11648+ 2.375 memcpy+0xe (ipipe_trigger_irq+0x4a) > :| * func -11645+ 3.270 __ipipe_handle_irq+0xe > (ipipe_trigger_irq+0x4f) > :| * func -11642+ 3.436 __ipipe_dispatch_wired+0xe > (__ipipe_handle_irq+0x8a) > :| * func -11639+ 2.345 __ipipe_restore_pipeline_head+0x8 > (_rtdm_synch_flush+0x5e) > :|func -11636+ 1.714 __ipipe_walk_pipeline+0xe > (__ipipe_restore_pipeline_head+0x67) > :|func -11635+ 1.624 ipipe_suspend_domain+0xb > (__ipipe_walk_pipeline+0x46) > :|func -11633+ 3.864 __ipipe_sync_stage+0xe > (ipipe_suspend_domain+0x47) > :| * func -11629+ 1.864 xnpod_schedule_handler+0x8 > (__ipipe_sync_stage+0x115) > :| * func -11627+ 3.684 xnpod_schedule+0xe > (xnpod_schedule_handler+0x17) > :| * [ 925] --0 -11624+ 6.496 xnpod_schedule+0x4f6 > (xnpod_schedule_handler+0x17) > :| * func -11617+ 7.157 __switch_to+0xe > (xnpod_schedule+0x612) > :| * [ 926] -- 99 -11610+ 9.157 xnpod_schedule+0x6e6 > (xnpod_suspend_thread+0xed) > :| * func -11601! 63.413 __ipipe_restore_pipeline_head+0x8 > (rtdm_event_timedwait+0xea) > :|func -11537+ 2.586 __ipipe_handle_irq+0xe > (common_interrupt+0x18) > :|func -11535+ 1.353 __ipipe_ack_common_irq+0xa > (__ipipe_handle_irq+0x80) > :|func -11533+ 2.165 > ipipe_test_and_stall_pipeline_from+0x8 (__ipipe_ack_common_irq+0x16) > :| * func -11531+ 3.218 mask_and_ack_8259A+0xb > (__ipipe_ack_common_irq+0x3f) > :|func -11528+ 2.030 __ipipe_dispatch_wired+0xe > (__ipipe_handle_irq+0x8a) > :| * func -11526+ 2.225 xnintr_clock_handler+0x8 > (__ipipe_dispatch_wired+0x7d) > :| * func -11524+ 2.030 xnintr_irq_handler+0xb > (xnintr_clock_handler+0x17) > :| * func -11522+ 2.345 xnpod_announce_tick+0x8 > (xnintr_irq_handler+0x24) > :| * func -11519+ 2.624 xntimer_do_tick_aperiodic+0xe > (xnpod_announce_tick+0xf) > :| * func -11517+ 1.390 xnthread_periodic_handler+0x8 > (xntimer_do_tick_aperiodic+0x7c) > :| * func -11515+ 6.977 xnpod_resume_thread+0xe > (xnthread_periodic_handler+0x1b) > :| * func -11508+ 3.383 xnpod_schedule+0xe > (xnintr_irq_handler+0x5f) > :|func -11505! 261.413 __ipipe_walk_pipeline+0xe > (__ipipe_handle_irq+0x179) > : func -11244+ 6.150 __ipipe_syscall_root+0x9 > (system_call+0x20) > :|func -11237+ 2.030 __ipipe_handle_irq+0xe > (common_interrupt+0x18) > :|func -11235+ 1.458 __ipipe_ack_common_irq+0xa > (__ipipe_handle_irq+0x80) > :|func -11234+ 1.909 > ipipe_test_and_stall_pipeline_from+0x8 (__ipipe_ack_common_irq+0x16) > :| * func -11232+ 3.172 mask_and_ack_8259A+0xb > (__ipipe_ack_common_irq+0x3f) > :|func -11229+ 2.436 __ipipe_dispatch_wired+0xe > (__ipipe_handle_irq+0x8a) > :| * func -11226
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
Dmitry Adamushko wrote:
> On 28/06/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
>> Jan Kiszka wrote:
>> >
>> > Ok, then we also need a fix for the latency test (this is where I
>> > grabbed that pattern from). Is there a high risk that this locks up? I
>> > wonder why I never observed or heard of problems with latency.
>>
>> The latency test used to deadlock, that is why the summary printed on
>> signal is printed on stderr. Unfortunately, there seem to be one display
>> left on stdout, so it should still deadlock. The reason why we never see
>> the deadlock is (perhaps) that the continuous intermediate results are
>> printed on the context of the "display" thread, whereas the termination
>> signals are preferably delivered by the kernel to the "main" thread,
>> that only calls pause. Which makes the use of stderr in signals handlers
>> pointless.
>
> It's very likely so.
>
> The main thread would use instead something like :
> ...
> while (!sig_term_received)
>pause();
>
> do_cleanup_chores();
> return 0;
>
> cleanup_upon_sig() should only set the sig_term_received flag up.
>
> Then all other threads must block signal delivering with sigprocmask()
> so that the main thread is the only one which "accepts" signals.
Is that required, i.e. does pause() only wake up if the signal handler
executed in the main thread's context? Then cyclictest contains a bug as
well...
>
> btw, according to POSIX 1003.1-2003, the write() call is amongst "safe"
> ones.
> http://www.die.net/doc/linux/man/man2/signal.2.html
>
> So write(1, ); heh... not that nice? :)
>
>
Something like this? Developed on top of my prio-switch patch. So far
without signal masking.
Jan
---
src/testsuite/latency/latency.c | 46
1 file changed, 24 insertions(+), 22 deletions(-)
Index: xenomai/src/testsuite/latency/latency.c
===
--- xenomai.orig/src/testsuite/latency/latency.c
+++ xenomai/src/testsuite/latency/latency.c
@@ -293,7 +293,7 @@ double dump_histogram (long *histogram,
double avg = 0; /* used to sum hits 1st */
if (do_histogram)
-fprintf(stderr,"---|--param|range-|--samples\n");
+printf("---|--param|range-|--samples\n");
for (n = 0; n < histogram_size; n++)
{
@@ -304,12 +304,11 @@ double dump_histogram (long *histogram,
total_hits += hits;
avg += n * hits;
if (do_histogram)
-fprintf(stderr,
-"HSD|%s| %3d -%3d | %8ld\n",
-kind,
-n,
-n+1,
-hits);
+printf("HSD|%s| %3d -%3d | %8ld\n",
+ kind,
+ n,
+ n+1,
+ hits);
}
}
@@ -338,8 +337,8 @@ void dump_stats (long *histogram, char*
variance /= total_hits - 1;
variance = sqrt(variance);
-fprintf(stderr,"HSS|%s| %9d| %10.3f| %10.3f\n",
-kind, total_hits, avg, variance);
+printf("HSS|%s| %9d| %10.3f| %10.3f\n",
+ kind, total_hits, avg, variance);
}
void dump_hist_stats (void)
@@ -351,23 +350,18 @@ void dump_hist_stats (void)
avgavg = dump_histogram (histogram_avg, "avg");
maxavg = dump_histogram (histogram_max, "max");
-fprintf(stderr,"HSH|--param|--samples-|--average--|---stddev--\n");
+printf("HSH|--param|--samples-|--average--|---stddev--\n");
dump_stats (histogram_min, "min", minavg);
dump_stats (histogram_avg, "avg", avgavg);
dump_stats (histogram_max, "max", maxavg);
}
-void cleanup_upon_sig(int sig __attribute__((unused)))
+void cleanup(void)
{
time_t actual_duration;
long gmaxj, gminj, gavgj;
-if (finished)
-return;
-
-finished = 1;
-
if (test_mode == USER_TASK) {
rt_sem_delete(&display_sem);
@@ -421,6 +415,11 @@ void cleanup_upon_sig(int sig __attribut
exit(0);
}
+void sighand(int sig __attribute__((unused)))
+{
+finished = 1;
+}
+
int main (int argc, char **argv)
{
int c, err;
@@ -532,7 +531,7 @@ int main (int argc, char **argv)
histogram_min = calloc(histogram_size, sizeof(long));
if (!(histogram_avg && histogram_max && histogram_min))
-cleanup_upon_sig(0);
+cleanup();
if (period_ns == 0)
period_ns = 10LL; /* ns */
@@ -542,10 +541,10 @@ int main (int argc, char **argv)
else if (priority > T_HIPRIO)
priority = T_HIPRIO;
-signal(SIGINT, cleanup_upon_sig);
-signal(SIGTERM, cleanup_upon_sig);
-signal(SIGHUP, cleanup_upon_sig);
-signal(SIGALRM, cleanup_upon_sig);
+signal(SIGINT, sighand);
+signal(SIGTERM, sighand);
+signal(SIGHUP, sighand);
+signal(SIGALRM, sighand);
setlinebuf(stdout);
@@ -610,7 +609,10 @@ int main (int argc, char
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
On 28/06/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote: Jan Kiszka wrote: > > Ok, then we also need a fix for the latency test (this is where I > grabbed that pattern from). Is there a high risk that this locks up? I > wonder why I never observed or heard of problems with latency. The latency test used to deadlock, that is why the summary printed on signal is printed on stderr. Unfortunately, there seem to be one display left on stdout, so it should still deadlock. The reason why we never see the deadlock is (perhaps) that the continuous intermediate results are printed on the context of the "display" thread, whereas the termination signals are preferably delivered by the kernel to the "main" thread, that only calls pause. Which makes the use of stderr in signals handlers pointless. It's very likely so. The main thread would use instead something like : ... while (!sig_term_received) pause(); do_cleanup_chores(); return 0; cleanup_upon_sig() should only set the sig_term_received flag up. Then all other threads must block signal delivering with sigprocmask() so that the main thread is the only one which "accepts" signals. btw, according to POSIX 1003.1-2003, the write() call is amongst "safe" ones. http://www.die.net/doc/linux/man/man2/signal.2.html So write(1, ); heh... not that nice? :) -- Best regards, Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
Jan Kiszka wrote: > > Is there no way to make this code easier to port for example by using > > native or posix services for timings measurement and by abstracting the > > non portable part and moving them to include/asm-i386 ? > > This tool is intentionally left Xenomai-free. You can put it on any x86 > box around (and I assume that there is almost always some...) and run > the test. Thus, no need for a second RT-patched system. > > Anyway, suggestions or patches to add a porting layer are welcome. The > following points need to be addressed: time measuring, irq protection, > hardware access. I just wonder if this is worth the effort. I do not understand: it appears to me that Xenomai trunk does not compile on other architectures than x86 when applying the IRQ latency benchmark patch. So, something needs to be done. It may be the enabling of an automake conditional in configure.in when compiling for x86. > > > > > Also note that calling printf from a signal handler risk deadlocking if > > the signal handler get called on the return path of the write call that > > take place in the middle of a printf call on the main thread. > > > > Ok, then we also need a fix for the latency test (this is where I > grabbed that pattern from). Is there a high risk that this locks up? I > wonder why I never observed or heard of problems with latency. The latency test used to deadlock, that is why the summary printed on signal is printed on stderr. Unfortunately, there seem to be one display left on stdout, so it should still deadlock. The reason why we never see the deadlock is (perhaps) that the continuous intermediate results are printed on the context of the "display" thread, whereas the termination signals are preferably delivered by the kernel to the "main" thread, that only calls pause. Which makes the use of stderr in signals handlers pointless. Anyway, since your program is frequently using printf on the context of the main thread, the risk of deadlock is real. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
Gilles Chanteperdrix wrote:
> [EMAIL PROTECTED] wrote:
> > Index: xenomai/src/testsuite/irqbench/irqbench.c
> > ===
> > --- /dev/null
> > +++ xenomai/src/testsuite/irqbench/irqbench.c
> > @@ -0,0 +1,301 @@
> > +/*
> > + * Copyright (C) 2006 Jan Kiszka <[EMAIL PROTECTED]>.
> > + *
> > + * Xenomai is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * Xenomai is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with Xenomai; if not, write to the Free Software Foundation,
> > + * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +
> > +#define SERPORT 0
> > +#define PARPORT 1
> > +
> > +/* --- Serial port --- */
> > +
> > +#define MCR_DTR 0x01
> > +#define MCR_RTS 0x02
> > +#define MCR_OUT20x08
> > +
> > +#define MSR_DELTA 0x0F
> > +
> > +#define LCR(base) (base + 3) /* Line Control Register */
> > +#define MCR(base) (base + 4) /* Modem Control Register */
> > +#define LSR(base) (base + 5) /* Line Status Register */
> > +#define MSR(base) (base + 6) /* Modem Status Register */
> > +
> > +/* --- Parallel port --- */
> > +
> > +#define CTRL_INIT 0x04
> > +
> > +#define STAT_STROBE 0x10
> > +
> > +#define DATA(base) (base + 0) /* Data register */
> > +#define STAT(base) (base + 1) /* Status register */
> > +#define CTRL(base) (base + 2) /* Control register */
> > +
> > +double tsc2ns_scale;
> > +long long min_lat = LLONG_MAX;
> > +long long max_lat = LLONG_MIN;
> > +long long avg_lat = 0;
> > +long outer_loops = 0;
> > +int warmup = 1;
> > +
> > +static inline long long rdtsc(void)
> > +{
> > +unsigned long long tsc;
> > +
> > +__asm__ __volatile__("rdtsc" : "=A" (tsc));
> > +return tsc;
> > +}
> > +
> > +
> > +static long tsc2ns(long long tsc)
> > +{
> > +if ((tsc > LONG_MAX) || (tsc < LONG_MIN)) {
> > +fprintf(stderr, "irqbench: overflow (%lld ns)!\n",
> > +(long long)(tsc2ns_scale * (double)tsc));
> > +exit(2);
> > +}
> > +return (long)(tsc2ns_scale * (double)tsc);
> > +}
> > +
> > +
> > +static inline long long ns2tsc(long long ns)
> > +{
> > +return (long long)(((double)ns) / tsc2ns_scale);
> > +}
> > +
> > +
> > +void calibrate_tsc(void)
> > +{
> > +FILE *proc;
> > +char *lineptr = NULL;
> > +size_t len;
> > +double cpu_mhz;
> > +
> > +proc = fopen("/proc/cpuinfo", "r");
> > +if (proc == NULL) {
> > +perror("irqbench: Unable to open /proc/cpuinfo");
> > +exit(1);
> > +}
> > +
> > +while (getline(&lineptr, &len, proc) != -1)
> > +if (strncmp(lineptr, "cpu MHz", 7) == 0) {
> > +sscanf(strchr(lineptr, ':') + 1, "%lf", &cpu_mhz);
> > +break;
> > +}
> > +
> > +if (lineptr)
> > +free(lineptr);
> > +fclose(proc);
> > +
> > +printf("CPU frequency: %.3lf MHz\n", cpu_mhz);
> > +
> > +tsc2ns_scale = 1000.0 / cpu_mhz;
> > +}
> > +
> > +
> > +void sighand(int signal)
> > +{
> > +if (!warmup) {
> > +avg_lat /= outer_loops;
> > +printf("---\n%.3f / %.3f / %.3f us\n",
> > + ((double)min_lat) / 1000.0, ((double)avg_lat) / 1000.0,
> > + ((double)max_lat) / 1000.0);
> > +}
> > +exit(0);
> > +}
> > +
> > +
> > +int main(int argc, char *argv[])
> > +{
> > +int port_type = SERPORT;
> > +unsigned long port_ioaddr = 0x3F8;
> > +long long period = 10;
> > +long long timeout;
> > +long long start, delay;
> > +unsigned inttoggle;
> > +int trigger_trace = 0;
> > +int c;
> > +
> > +
> > +signal(SIGINT, sighand);
> > +signal(SIGTERM, sighand);
> > +signal(SIGHUP, sighand);
> > +signal(SIGALRM, sighand);
> > +
> > +calibrate_tsc();
> > +
> > +while ((c = getopt(argc,argv,"p:T:o:a:f")) != EOF)
> > +switch (c) {
> > +case 'p':
> > +period = atoi(optarg) * 1000;
> > +break;
> > +
> > +case 'T':
> > +alarm(atoi(optarg));
> > +
Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark
[EMAIL PROTECTED] wrote:
> Index: xenomai/src/testsuite/irqbench/irqbench.c
> ===
> --- /dev/null
> +++ xenomai/src/testsuite/irqbench/irqbench.c
> @@ -0,0 +1,301 @@
> +/*
> + * Copyright (C) 2006 Jan Kiszka <[EMAIL PROTECTED]>.
> + *
> + * Xenomai is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Xenomai is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with Xenomai; if not, write to the Free Software Foundation,
> + * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
> +#define SERPORT 0
> +#define PARPORT 1
> +
> +/* --- Serial port --- */
> +
> +#define MCR_DTR 0x01
> +#define MCR_RTS 0x02
> +#define MCR_OUT20x08
> +
> +#define MSR_DELTA 0x0F
> +
> +#define LCR(base) (base + 3) /* Line Control Register */
> +#define MCR(base) (base + 4) /* Modem Control Register */
> +#define LSR(base) (base + 5) /* Line Status Register */
> +#define MSR(base) (base + 6) /* Modem Status Register */
> +
> +/* --- Parallel port --- */
> +
> +#define CTRL_INIT 0x04
> +
> +#define STAT_STROBE 0x10
> +
> +#define DATA(base) (base + 0) /* Data register */
> +#define STAT(base) (base + 1) /* Status register */
> +#define CTRL(base) (base + 2) /* Control register */
> +
> +double tsc2ns_scale;
> +long long min_lat = LLONG_MAX;
> +long long max_lat = LLONG_MIN;
> +long long avg_lat = 0;
> +long outer_loops = 0;
> +int warmup = 1;
> +
> +static inline long long rdtsc(void)
> +{
> +unsigned long long tsc;
> +
> +__asm__ __volatile__("rdtsc" : "=A" (tsc));
> +return tsc;
> +}
> +
> +
> +static long tsc2ns(long long tsc)
> +{
> +if ((tsc > LONG_MAX) || (tsc < LONG_MIN)) {
> +fprintf(stderr, "irqbench: overflow (%lld ns)!\n",
> +(long long)(tsc2ns_scale * (double)tsc));
> +exit(2);
> +}
> +return (long)(tsc2ns_scale * (double)tsc);
> +}
> +
> +
> +static inline long long ns2tsc(long long ns)
> +{
> +return (long long)(((double)ns) / tsc2ns_scale);
> +}
> +
> +
> +void calibrate_tsc(void)
> +{
> +FILE *proc;
> +char *lineptr = NULL;
> +size_t len;
> +double cpu_mhz;
> +
> +proc = fopen("/proc/cpuinfo", "r");
> +if (proc == NULL) {
> +perror("irqbench: Unable to open /proc/cpuinfo");
> +exit(1);
> +}
> +
> +while (getline(&lineptr, &len, proc) != -1)
> +if (strncmp(lineptr, "cpu MHz", 7) == 0) {
> +sscanf(strchr(lineptr, ':') + 1, "%lf", &cpu_mhz);
> +break;
> +}
> +
> +if (lineptr)
> +free(lineptr);
> +fclose(proc);
> +
> +printf("CPU frequency: %.3lf MHz\n", cpu_mhz);
> +
> +tsc2ns_scale = 1000.0 / cpu_mhz;
> +}
> +
> +
> +void sighand(int signal)
> +{
> +if (!warmup) {
> +avg_lat /= outer_loops;
> +printf("---\n%.3f / %.3f / %.3f us\n",
> + ((double)min_lat) / 1000.0, ((double)avg_lat) / 1000.0,
> + ((double)max_lat) / 1000.0);
> +}
> +exit(0);
> +}
> +
> +
> +int main(int argc, char *argv[])
> +{
> +int port_type = SERPORT;
> +unsigned long port_ioaddr = 0x3F8;
> +long long period = 10;
> +long long timeout;
> +long long start, delay;
> +unsigned inttoggle;
> +int trigger_trace = 0;
> +int c;
> +
> +
> +signal(SIGINT, sighand);
> +signal(SIGTERM, sighand);
> +signal(SIGHUP, sighand);
> +signal(SIGALRM, sighand);
> +
> +calibrate_tsc();
> +
> +while ((c = getopt(argc,argv,"p:T:o:a:f")) != EOF)
> +switch (c) {
> +case 'p':
> +period = atoi(optarg) * 1000;
> +break;
> +
> +case 'T':
> +alarm(atoi(optarg));
> +break;
> +
> +case 'o':
> +port_type = atoi(optarg);
> +break;
> +
> +case 'a':
> +port_ioaddr = strtol(optarg, NULL,
> +(strncmp(optarg, "0x", 2) == 0) ? 16 : 10);
> +break;
> +
> +case 'f':
> +tr
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
Philippe Gerum wrote:
> On Wed, 2006-06-28 at 10:51 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
> On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
plain text document attachment (enhance-kernel-fault-report.patch)
Introduce xnarch_fault_um() to test if a fault happened in user-mode
and applies the new feature to report core and driver crashes more
verbosely.
if (xnpod_shadow_p()) {
#ifdef CONFIG_XENO_OPT_DEBUG
- if (xnarch_fault_notify(fltinfo)) /* Don't report
debug traps */
+ if (!xnarch_fault_um(fltinfo)) {
+ xnarch_trace_panic_freeze();
>>> KGDB breakpoint issue?
>> Sorry, please switch on verbose mode, didn't get yet what you mean.
> Oops, sorry. I meant: what if a KGDB breakpoint is hit from kernel space
> while running a shadow thread? The way I read the modified test sequence
> above, such bp trap is going to trigger a panic, instead of being
> silently passed to Linux.
I would say: KGDB will not come along here with a breakpoint. It should
already got involved in __ipipe_divert_exception().
>>> Ok, so the only problem that remains would be inlined asm("int 1/3") in
>>> kernel space not handled by KGDB (whether the KGDB patch is in or not).
>>> I'm still scratching my head pondering if we can live with this or not.
>> But this is perfectly one of the situations my patch tries to catch: a
>> fatal bug in the kernel! Such a hand-coded kernel breakpoint without a
>> debugger caring is a bug to me.
>
> Not that sure: passive debug code may exist. Only the presence of the
> debugger should activate it.
>
...but remains a bug for me /w RT code. We now complain about this
exception happened. And there is no crash/BUG in this case, just a
desirable warning with back-trace in the log.
Jan
PS: Other OSes show you a nice blue-screen when they ran on such
orphaned breakpoints.
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
On Wed, 2006-06-28 at 10:51 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
> >> plain text document attachment (enhance-kernel-fault-report.patch)
> >> Introduce xnarch_fault_um() to test if a fault happened in user-mode
> >> and applies the new feature to report core and driver crashes more
> >> verbosely.
> >>if (xnpod_shadow_p()) {
> >> #ifdef CONFIG_XENO_OPT_DEBUG
> >> - if (xnarch_fault_notify(fltinfo)) /* Don't report
> >> debug traps */
> >> + if (!xnarch_fault_um(fltinfo)) {
> >> + xnarch_trace_panic_freeze();
> > KGDB breakpoint issue?
> Sorry, please switch on verbose mode, didn't get yet what you mean.
> >>> Oops, sorry. I meant: what if a KGDB breakpoint is hit from kernel space
> >>> while running a shadow thread? The way I read the modified test sequence
> >>> above, such bp trap is going to trigger a panic, instead of being
> >>> silently passed to Linux.
> >> I would say: KGDB will not come along here with a breakpoint. It should
> >> already got involved in __ipipe_divert_exception().
> >
> > Ok, so the only problem that remains would be inlined asm("int 1/3") in
> > kernel space not handled by KGDB (whether the KGDB patch is in or not).
> > I'm still scratching my head pondering if we can live with this or not.
>
> But this is perfectly one of the situations my patch tries to catch: a
> fatal bug in the kernel! Such a hand-coded kernel breakpoint without a
> debugger caring is a bug to me.
Not that sure: passive debug code may exist. Only the presence of the
debugger should activate it.
>
> Jan
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
Philippe Gerum wrote:
> On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
>> plain text document attachment (enhance-kernel-fault-report.patch)
>> Introduce xnarch_fault_um() to test if a fault happened in user-mode and
>> applies the new feature to report core and driver crashes more
>> verbosely.
>> if (xnpod_shadow_p()) {
>> #ifdef CONFIG_XENO_OPT_DEBUG
>> -if (xnarch_fault_notify(fltinfo)) /* Don't report
>> debug traps */
>> +if (!xnarch_fault_um(fltinfo)) {
>> +xnarch_trace_panic_freeze();
> KGDB breakpoint issue?
Sorry, please switch on verbose mode, didn't get yet what you mean.
>>> Oops, sorry. I meant: what if a KGDB breakpoint is hit from kernel space
>>> while running a shadow thread? The way I read the modified test sequence
>>> above, such bp trap is going to trigger a panic, instead of being
>>> silently passed to Linux.
>> I would say: KGDB will not come along here with a breakpoint. It should
>> already got involved in __ipipe_divert_exception().
>
> Ok, so the only problem that remains would be inlined asm("int 1/3") in
> kernel space not handled by KGDB (whether the KGDB patch is in or not).
> I'm still scratching my head pondering if we can live with this or not.
But this is perfectly one of the situations my patch tries to catch: a
fatal bug in the kernel! Such a hand-coded kernel breakpoint without a
debugger caring is a bug to me.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
> plain text document attachment (enhance-kernel-fault-report.patch)
> Introduce xnarch_fault_um() to test if a fault happened in user-mode and
> applies the new feature to report core and driver crashes more
> verbosely.
> if (xnpod_shadow_p()) {
> #ifdef CONFIG_XENO_OPT_DEBUG
> -if (xnarch_fault_notify(fltinfo)) /* Don't report
> debug traps */
> +if (!xnarch_fault_um(fltinfo)) {
> +xnarch_trace_panic_freeze();
> >>> KGDB breakpoint issue?
> >> Sorry, please switch on verbose mode, didn't get yet what you mean.
> >
> > Oops, sorry. I meant: what if a KGDB breakpoint is hit from kernel space
> > while running a shadow thread? The way I read the modified test sequence
> > above, such bp trap is going to trigger a panic, instead of being
> > silently passed to Linux.
>
> I would say: KGDB will not come along here with a breakpoint. It should
> already got involved in __ipipe_divert_exception().
Ok, so the only problem that remains would be inlined asm("int 1/3") in
kernel space not handled by KGDB (whether the KGDB patch is in or not).
I'm still scratching my head pondering if we can live with this or not.
>
> Jan
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
Philippe Gerum wrote:
> On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
plain text document attachment (enhance-kernel-fault-report.patch)
Introduce xnarch_fault_um() to test if a fault happened in user-mode and
applies the new feature to report core and driver crashes more verbosely.
if (xnpod_shadow_p()) {
#ifdef CONFIG_XENO_OPT_DEBUG
- if (xnarch_fault_notify(fltinfo)) /* Don't report debug
traps */
+ if (!xnarch_fault_um(fltinfo)) {
+ xnarch_trace_panic_freeze();
>>> KGDB breakpoint issue?
>> Sorry, please switch on verbose mode, didn't get yet what you mean.
>
> Oops, sorry. I meant: what if a KGDB breakpoint is hit from kernel space
> while running a shadow thread? The way I read the modified test sequence
> above, such bp trap is going to trigger a panic, instead of being
> silently passed to Linux.
I would say: KGDB will not come along here with a breakpoint. It should
already got involved in __ipipe_divert_exception().
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
> >> plain text document attachment (enhance-kernel-fault-report.patch)
> >> Introduce xnarch_fault_um() to test if a fault happened in user-mode and
> >> applies the new feature to report core and driver crashes more verbosely.
> >
> >>if (xnpod_shadow_p()) {
> >> #ifdef CONFIG_XENO_OPT_DEBUG
> >> - if (xnarch_fault_notify(fltinfo)) /* Don't report debug
> >> traps */
> >> + if (!xnarch_fault_um(fltinfo)) {
> >> + xnarch_trace_panic_freeze();
> >
> > KGDB breakpoint issue?
>
> Sorry, please switch on verbose mode, didn't get yet what you mean.
Oops, sorry. I meant: what if a KGDB breakpoint is hit from kernel space
while running a shadow thread? The way I read the modified test sequence
above, such bp trap is going to trigger a panic, instead of being
silently passed to Linux.
>
> >
> >> + xnprintf
> >> + ("Switching %s to secondary mode after exception
> >> #%u in "
> >> + "kernel-space at 0x%lx (pid %d)\n", thread->name,
> >> + xnarch_fault_trap(fltinfo),
> >> + xnarch_fault_pc(fltinfo),
> >> + xnthread_user_pid(thread));
> >> + xnarch_trace_panic_dump();
> >> + } else if (xnarch_fault_notify(fltinfo)) /* Don't report debug
> >> traps */
> >
>
> Jan
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
Philippe Gerum wrote:
> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
>> plain text document attachment (enhance-kernel-fault-report.patch)
>> Introduce xnarch_fault_um() to test if a fault happened in user-mode and
>> applies the new feature to report core and driver crashes more verbosely.
>
>> if (xnpod_shadow_p()) {
>> #ifdef CONFIG_XENO_OPT_DEBUG
>> -if (xnarch_fault_notify(fltinfo)) /* Don't report debug
>> traps */
>> +if (!xnarch_fault_um(fltinfo)) {
>> +xnarch_trace_panic_freeze();
>
> KGDB breakpoint issue?
Sorry, please switch on verbose mode, didn't get yet what you mean.
>
>> +xnprintf
>> +("Switching %s to secondary mode after exception
>> #%u in "
>> + "kernel-space at 0x%lx (pid %d)\n", thread->name,
>> + xnarch_fault_trap(fltinfo),
>> + xnarch_fault_pc(fltinfo),
>> + xnthread_user_pid(thread));
>> +xnarch_trace_panic_dump();
>> +} else if (xnarch_fault_notify(fltinfo)) /* Don't report debug
>> traps */
>
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/6] Improve fault report
On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
> plain text document attachment (enhance-kernel-fault-report.patch)
> Introduce xnarch_fault_um() to test if a fault happened in user-mode and
> applies the new feature to report core and driver crashes more verbosely.
> if (xnpod_shadow_p()) {
> #ifdef CONFIG_XENO_OPT_DEBUG
> - if (xnarch_fault_notify(fltinfo)) /* Don't report debug
> traps */
> + if (!xnarch_fault_um(fltinfo)) {
> + xnarch_trace_panic_freeze();
KGDB breakpoint issue?
> + xnprintf
> + ("Switching %s to secondary mode after exception
> #%u in "
> + "kernel-space at 0x%lx (pid %d)\n", thread->name,
> + xnarch_fault_trap(fltinfo),
> + xnarch_fault_pc(fltinfo),
> + xnthread_user_pid(thread));
> + xnarch_trace_panic_dump();
> + } else if (xnarch_fault_notify(fltinfo)) /* Don't report debug
> traps */
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
