[Xenomai-core] [PATCH] debug_maxlat as module_param

[Xenomai-core] [PATCH] debug_maxlat as module_param

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 929 bytes --]

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. :)

[-- Attachment #1.2: maxlat_arg.patch --]
[-- Type: text/x-patch, Size: 1389 bytes --]

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,
                                        1000000000);
 
@@ -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 */
 

[-- Attachment #1.3: arch_generic.patch --]
[-- Type: text/x-patch, Size: 1948 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Xenomai-core] [PATCH] debug_maxlat as module_param

[Gilles Chanteperdrix]

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Xenomai-core] [PATCH] debug_maxlat as module_param

[Philippe Gerum]

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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.

Re: [Xenomai-core] [PATCH] debug_maxlat as module_param

[Gilles Chanteperdrix]

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.