Re: [Xenomai-core] [PATCH] debug_maxlat as module_param
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi, this tiny patch exports the NMI watchdog's threshold as module parameter debug_maxlat of xeno_hal. This means that one can either override the value via a kernel parameter or in sysfs/modules/xeno_hal/parameters (before activating the hal). rthal_maxlat_tsc should be updated when rthal_maxlat_us_arg changes. I didn't digged that deep, is this possible during runtime? My current workflow looks like this: unload xeno_nucleus (and higher modules), change maxlat, reload the modules. Mmh, I guess one has to register some update handler with sysfs in that case. Any hint where to look for a pattern? In nucleus/module.c, the latency parameter may be read and written at run-time through procfs, have a look at the functions latency_read_proc and latency_write_proc. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] debug_maxlat as module_param
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi, this tiny patch exports the NMI watchdog's threshold as module parameter debug_maxlat of xeno_hal. This means that one can either override the value via a kernel parameter or in sysfs/modules/xeno_hal/parameters (before activating the hal). rthal_maxlat_tsc should be updated when rthal_maxlat_us_arg changes. I didn't digged that deep, is this possible during runtime? My current workflow looks like this: unload xeno_nucleus (and higher modules), change maxlat, reload the modules. Mmh, I guess one has to register some update handler with sysfs in that case. Any hint where to look for a pattern? In nucleus/module.c, the latency parameter may be read and written at run-time through procfs, have a look at the functions latency_read_proc and latency_write_proc. -- Gilles Chanteperdrix.
Re: [Xenomai-core] [PATCH] debug_maxlat as module_param
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi, this tiny patch exports the NMI watchdog's threshold as module parameter debug_maxlat of xeno_hal. This means that one can either override the value via a kernel parameter or in sysfs/modules/xeno_hal/parameters (before activating the hal). rthal_maxlat_tsc should be updated when rthal_maxlat_us_arg changes. I didn't digged that deep, is this possible during runtime? My current workflow looks like this: unload xeno_nucleus (and higher modules), change maxlat, reload the modules. Mmh, I guess one has to register some update handler with sysfs in that case. Any hint where to look for a pattern? Please don't depend on sysfs for generic features since they would not be available on 2.4. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] debug_maxlat as module_param
Hi,
this tiny patch exports the NMI watchdog's threshold as module parameter
debug_maxlat of xeno_hal. This means that one can either override the
value via a kernel parameter or in sysfs/modules/xeno_hal/parameters
(before activating the hal).
Unfortunately, this tiny patch caused some headache to me as it first
made the kernel crash early during boot in sysfs_create_group(). I do
not understand why I need the second patch, I only guessed from the
kernel build output that some unlucky linking order screwed up
module_params in xenomai's non-generic arch files. If this is the only
solution, we have to verify if 2.4 still works (untested) and we have to
patch the Makefiles of the other archs.
Jan
PS: The NMI watchdog is nice, but we are really lacking a qualified
backtrace with all invoked functions in a critical path. I'm optimistic
that we will see Fu's first latency trace patch version already next
week. :)
Index: ksrc/arch/i386/hal.c
===
--- ksrc/arch/i386/hal.c (Revision 285)
+++ ksrc/arch/i386/hal.c (Arbeitskopie)
@@ -212,7 +212,8 @@
unsigned long rthal_maxlat_tsc;
EXPORT_SYMBOL(rthal_maxlat_tsc);
-static unsigned rthal_maxlat_us = CONFIG_XENO_HW_NMI_DEBUG_LATENCY_MAX;
+unsigned rthal_maxlat_us_arg = CONFIG_XENO_HW_NMI_DEBUG_LATENCY_MAX;
+module_param_named(debug_maxlat, rthal_maxlat_us_arg, uint, 0644);
static void rthal_latency_above_max(struct pt_regs *regs)
{
@@ -220,7 +221,7 @@
snprintf(buf,
sizeof(buf),
NMI watchdog detected timer latency above %u us\n,
- rthal_maxlat_us);
+ rthal_maxlat_us_arg);
die_nmi(regs, buf);
}
#endif
@@ -297,7 +298,7 @@
#ifdef CONFIG_XENO_HW_NMI_DEBUG_LATENCY
if (!p-mode) {
-rthal_maxlat_tsc = rthal_llimd(rthal_maxlat_us * 1000ULL,
+rthal_maxlat_tsc = rthal_llimd(rthal_maxlat_us_arg * 1000ULL,
RTHAL_CPU_FREQ,
10);
@@ -307,7 +308,7 @@
printk(Xenomai: NMI watchdog not available.\n);
else
printk(Xenomai: NMI watchdog started (threshold=%u us).\n,
- rthal_maxlat_us);
+ rthal_maxlat_us_arg);
}
#endif /* CONFIG_XENO_HW_NMI_DEBUG_LATENCY */
Index: scripts/prepare-kernel.sh
===
--- scripts/prepare-kernel.sh (Revision 285)
+++ scripts/prepare-kernel.sh (Arbeitskopie)
@@ -301,6 +301,7 @@
# compilation files.
do_links $xenomai_root/ksrc/arch/$xenomai_arch $linux_tree/arch/$linux_arch/xenomai
+do_links $xenomai_root/ksrc/arch/generic $linux_tree/arch/$linux_arch/xenomai/generic
do_links $xenomai_root/ksrc $linux_tree/kernel/xenomai
do_links $xenomai_root/ksrc/drivers $linux_tree/drivers/xenomai
do_links $xenomai_root/include/asm-$xenomai_arch $linux_tree/include/asm-$linux_arch/xenomai
Index: ksrc/Makefile
===
--- ksrc/Makefile (Revision 285)
+++ ksrc/Makefile (Arbeitskopie)
@@ -2,14 +2,12 @@
# Makefile frag for Linux v2.6
-obj-$(CONFIG_XENOMAI) += arch/ nucleus/ skins/
+obj-$(CONFIG_XENOMAI) += nucleus/ skins/
else
# Makefile frag for Linux v2.4
-subdir-$(CONFIG_XENOMAI) += arch
-
subdir-$(CONFIG_XENO_OPT_NUCLEUS) += nucleus
mod-subdirs := skins
Index: ksrc/arch/Makefile
===
--- ksrc/arch/Makefile (Revision 285)
+++ ksrc/arch/Makefile (Arbeitskopie)
@@ -1,15 +0,0 @@
-ifeq ($(PATCHLEVEL),6)
-
-# Makefile frag for Linux v2.6
-
-obj-$(CONFIG_XENOMAI) += generic/
-
-else
-
-# Makefile frag for Linux v2.4
-
-subdir-y += generic
-
-include $(TOPDIR)/Rules.make
-
-endif
Index: ksrc/arch/i386/Makefile
===
--- ksrc/arch/i386/Makefile (Revision 285)
+++ ksrc/arch/i386/Makefile (Arbeitskopie)
@@ -2,7 +2,7 @@
# Makefile frag for Linux v2.6
-obj-$(CONFIG_XENOMAI) += xeno_hal.o
+obj-$(CONFIG_XENOMAI) += xeno_hal.o generic/
xeno_hal-y := hal.o usercopy.o
@@ -14,6 +14,8 @@
# Makefile frag for Linux v2.4
+subdir-y += generic
+
USE_STANDARD_AS_RULE := true
O_TARGET := built-in.o
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] debug_maxlat as module_param
Jan Kiszka wrote: Hi, this tiny patch exports the NMI watchdog's threshold as module parameter debug_maxlat of xeno_hal. This means that one can either override the value via a kernel parameter or in sysfs/modules/xeno_hal/parameters (before activating the hal). rthal_maxlat_tsc should be updated when rthal_maxlat_us_arg changes. -- Gilles Chanteperdrix.
Re: [Xenomai-core] [PATCH] debug_maxlat as module_param
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi, this tiny patch exports the NMI watchdog's threshold as module parameter debug_maxlat of xeno_hal. This means that one can either override the value via a kernel parameter or in sysfs/modules/xeno_hal/parameters (before activating the hal). rthal_maxlat_tsc should be updated when rthal_maxlat_us_arg changes. I didn't digged that deep, is this possible during runtime? My current workflow looks like this: unload xeno_nucleus (and higher modules), change maxlat, reload the modules. Mmh, I guess one has to register some update handler with sysfs in that case. Any hint where to look for a pattern? Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] debug_maxlat as module_param
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi, this tiny patch exports the NMI watchdog's threshold as module parameter debug_maxlat of xeno_hal. This means that one can either override the value via a kernel parameter or in sysfs/modules/xeno_hal/parameters (before activating the hal). rthal_maxlat_tsc should be updated when rthal_maxlat_us_arg changes. I didn't digged that deep, is this possible during runtime? My current workflow looks like this: unload xeno_nucleus (and higher modules), change maxlat, reload the modules. Mmh, I guess one has to register some update handler with sysfs in that case. Any hint where to look for a pattern? Please don't depend on sysfs for generic features since they would not be available on 2.4. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
