rtdm_task_init does not work with Xenomai 3
Dear all,
I tried to have an example using rtdm_task_init with Xenomai 3.0.7. The example
is tis one:
—
#include
static int periode_us = 1000;
static int a, ret;
module_param(periode_us, int, 0644);
rtdm_task_t task;
void task_ultrason(void *arg){
a=1;
rtdm_printk(KERN_INFO "%s.%s() : hello = %d\n", THIS_MODULE->name,
__FUNCTION__,a);
}
int __init ultrason_init(void) {
a=0;
rtdm_printk(KERN_INFO "%s.%s() : hello = %d\n", THIS_MODULE->name,
__FUNCTION__,a);
ret = rtdm_task_init(, "ultrason", task_ultrason, NULL, 99,
periode_us*1000);
if (ret) {
rtdm_printk(KERN_INFO "%s.%s() : error rtdm_task_init, hello = %d\n",
THIS_MODULE->name, __FUNCTION__,a);
}
else rtdm_printk(KERN_INFO "%s.%s() : success rtdm_task_init, hello =
%d\n", THIS_MODULE->name, __FUNCTION__,a);
return 0;
}
void __exit ultrason_exit(void) {
a=2;
rtdm_task_destroy();
rtdm_printk(KERN_INFO "%s.%s() : hello = %d\n", THIS_MODULE->name,
__FUNCTION__,a);
}
module_init(ultrason_init);
module_exit(ultrason_exit);
MODULE_LICENSE("GPL »);
—
When I insert the module and remove it, I found in dmesg:
—
[ 5045.187448] test.ultrason_init() : hello = 0
[ 5045.189495] test.ultrason_init() : success rtdm_task_init, hello = 0
[ 5049.631665] test.ultrason_exit() : hello = 2
—
The task_ultrason is never called.
I read from
https://gitlab.denx.de/Xenomai/xenomai/-/wikis/Migrating_From_Xenomai_2_To_3
,
that rtdm_task_init() shall be called from secondary mode.
Since Xenomai 3, rtdm_task_init() involves creating a regular kernel thread,
which will be given real-time capabilities, such as running under the control
of the Cobalt kernel. In order to invoke standard kernel services,
rtdm_task_init() must be called from a regular Linux kernel context.
So, how to adapt my example to call rtdm_task_init() from from a regular Linux
kernel context to make this example working?
Thank you for your help.
BR,
Marwane.
Re: Porting Xenomai to STM32MP1
t; >> Name: kernel_log.txt > >> URL: < > http://xenomai.org/pipermail/xenomai/attachments/20200521/a133eb59/attachment-0001.txt> > ; > > > >It's hard to see from just the log what is happening. To confirm, you > >can boot without Xenomai but just the ipipe without issue? Are you > >able to post the patch of the port for us to look at? > > > >Thanks > > > >Greg > > I confirm that I can boot without issue with CONFIG_IPIPE enabled > and CONFIG_XENOMAI disabled. Attached a patch with my changes. > Thank you very much, > > Cesare > > > > __ > > MARPOSS S.p.A., with a sole shareholder > Via Saliceto, 13 - 40010 BENTIVOGLIO (BO) - ITALY > > Share Capital euro 15,000,000 paid in full - Tax Code and Registration No. > at Business Register of Bologna 03354081204 > Economic and Administrative Index No. 516318 - VAT IT 03354081204 > > __ > > *The information contained in this e-mail and any attachments is > confidential and may also be privileged. If you have received the > e-mail and any attachments by mistake, please inform us immediately, > destroy them without storing or copying them on any medium, and do not > disclose or use the contents for any purpose.* > *Although our systems implement reasonable precautions against viruses and > other threats, we cannot accept responsibility for any loss or damage > arising from managing the contents of this e-mail. * > > *P* *Please consider the environment before printing this e-mail* > Are you still seeing the issue? I finally looked over the diff, still looking at a few things but it looks good. -- next part -- A non-text attachment was scrubbed... Name: noname Type: image/jpeg Size: 19872 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20200602/99d135b6/attachment.jpe>
Re: an xhci problem on raspberry pi 4b
On 2020年06月02日 17:08, Jan Kiszka wrote: On 02.06.20 10:51, chensong wrote: On 2020年06月02日 15:49, Jan Kiszka wrote: On 01.06.20 15:51, Greg Gallagher via Xenomai wrote: I'm not sure if the rpi4 is in mainline yet but you may have more success trying this with the mainline kernel The RPi4 is still far aways from mainline, unfortunately. The usual downstream mess. any thought about "[0.712926] irq 38 handler xhci_msi_irq+0x0/0x30 enabled interrupts " in kernel/irq/handle.c:153? call stack is like：irqs_diabled -- raw_irqs_diabled -- arch_irqs_diabled -- ipipe_test_root Not handled msi irq domain(Brcm_MSI) approprately? Often this means that some code path along the early interrupt handling is not I-pipe aware (un-hardened spinlock etc.). Did you already try enabling all I-pipe debug options? not yet, that's a good idea, i will give it a try. Jan
Re: an xhci problem on raspberry pi 4b
On 02.06.20 10:51, chensong wrote: > > > On 2020年06月02日 15:49, Jan Kiszka wrote: >> On 01.06.20 15:51, Greg Gallagher via Xenomai wrote: >>> I'm not sure if the rpi4 is in mainline yet but you may have more >>> success trying this with the mainline kernel >>> >> >> The RPi4 is still far aways from mainline, unfortunately. The usual >> downstream mess. > > any thought about "[ 0.712926] irq 38 handler xhci_msi_irq+0x0/0x30 > enabled interrupts " in kernel/irq/handle.c:153? > > call stack is like：irqs_diabled -- raw_irqs_diabled -- > arch_irqs_diabled -- ipipe_test_root > > Not handled msi irq domain(Brcm_MSI) approprately? Often this means that some code path along the early interrupt handling is not I-pipe aware (un-hardened spinlock etc.). Did you already try enabling all I-pipe debug options? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: an xhci problem on raspberry pi 4b
On 2020年06月02日 15:49, Jan Kiszka wrote: On 01.06.20 15:51, Greg Gallagher via Xenomai wrote: I'm not sure if the rpi4 is in mainline yet but you may have more success trying this with the mainline kernel The RPi4 is still far aways from mainline, unfortunately. The usual downstream mess. any thought about "[0.712926] irq 38 handler xhci_msi_irq+0x0/0x30 enabled interrupts " in kernel/irq/handle.c:153? call stack is like：irqs_diabled -- raw_irqs_diabled -- arch_irqs_diabled -- ipipe_test_root Not handled msi irq domain(Brcm_MSI) approprately? Jan
Re: [PATCH] Enable zynq gpio and xilinx gpio support for the Zynq MP platform.
On 31.05.20 05:29, Greg Gallagher via Xenomai wrote: > From: Joshua Karch > > Signed-off-by: Joshua Karch > Signed-off-by: Greg Gallagher > --- > kernel/drivers/gpio/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig > index dbc862754..44f41688c 100644 > --- a/kernel/drivers/gpio/Kconfig > +++ b/kernel/drivers/gpio/Kconfig > @@ -34,7 +34,7 @@ config XENO_DRIVERS_GPIO_SUN8I_H3 > SoC, as found on the NanoPI boards. > > config XENO_DRIVERS_GPIO_ZYNQ7000 > - depends on ARCH_ZYNQ > + depends on ARCH_ZYNQ || ARCH_ZYNQMP > tristate "Support for Zynq7000 GPIOs" > help > > @@ -42,7 +42,7 @@ config XENO_DRIVERS_GPIO_ZYNQ7000 > Xilinx's Zynq7000 SoC. > > config XENO_DRIVERS_GPIO_XILINX > - depends on ARCH_ZYNQ > + depends on ARCH_ZYNQ || ARCH_ZYNQMP > tristate "Support for Xilinx GPIOs" > help > > Massaged and applied. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: an xhci problem on raspberry pi 4b
On 01.06.20 15:51, Greg Gallagher via Xenomai wrote: > I'm not sure if the rpi4 is in mainline yet but you may have more > success trying this with the mainline kernel > The RPi4 is still far aways from mainline, unfortunately. The usual downstream mess. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: Handling MSI-X interrupts in the head stage for x86 platform
On 02.06.20 08:40, Alexander Frolov via Xenomai wrote: > > > On 6/1/20 12:23 PM, Meng, Fino via Xenomai wrote: >> >>> Sent: Monday, June 1, 2020 4:09 PM >>> >>> Hi all! >>> >>> I have a PCIe device in x86 motherboard that generate periodic MSI-X >>> interrupts and I would like to handle them in the head >>> stage, how it can be done? >>> Thank you! Appreciate any help! >>> >>> Best, >>> Alex >> Hi Alex, >> >> Kernel/driver/serial/16550A.c is a pci device, and have less code than >> net/igb driver, >> Which specific device u want to enable? Does it have a vanilla kernel >> driver already? > > Not sure that 16550A uses MSI-X interrupts. However, net/igb does. Is it > only driver in Xenomai that supports MSI-X? > > > I am using FPGA based device for periodic interrupts which is totally > custom. We have are own driver. > > Nevertheless, I have tested its latency from root stage driver and it is > appropriately good (not over than 60us). It seems that > msix irqs are not stalled anywhere. Is it possible? > > Can I guarantee that there will be no condition when MSIX interrupt will > be deferred by head stage on more than that? What latency > improvement I can expect from moving to RTDM based driver? > Head stage defers according to priorities: There there is an interrupt or a task for head stage pending, that will win. No guarantees beyond what your own workload can guarantee. In addition, no guarantees architecturally on what will happen in Linux (root stage) which could defer your interrupt. If you want determinism, move it to head stage. Jan PS: MSI-X works as well as MSI or legacy INTx. -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: Stalled head domain on x86_64 platform
On 02.06.20 09:37, Alexander Frolov via Xenomai wrote: > Hi all! > > I've encountered with the following ipipe error message. What can it be? > Thank you! > > Best, > Alex > > > [ 2275.770959] I-pipe: Detected stalled head domain, probably caused by > a bug. > A critical section may have been left unterminated. > [ 2275.770965] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G W O > 4.19.84-xenomai-nicevt4.debug1 #1 > [ 2275.770968] Hardware name: GIGABYTE MZ31-AR0-00/MZ31-AR0-00, BIOS F13 > 04/15/2019 > [ 2275.770970] I-pipe domain: Linux > [ 2275.770973] Call Trace: > [ 2275.770984] dump_stack+0x8c/0xc0 > [ 2275.770990] ipipe_root_only.cold+0x11/0x32 > [ 2275.770994] ipipe_stall_root+0xe/0x60 > [ 2275.770999] __ipipe_trap_prologue+0x11a/0x300 > [ 2275.771005] int3+0x45/0x70 You likely have some feature on that uses jump labels. That was prevented in ipipe-core-4.19.89-x86-9. Jan > [ 2275.771010] RIP: 0010:xntimer_start+0x37/0x220 > [ 2275.771013] Code: 89 ce 41 55 49 89 d5 41 54 55 48 89 fd 53 48 83 ec > 08 48 8b 47 68 4c 8b 25 16 52 2e 01 48 63 40 18 4c 03 24 c5 00 27 2b 98 > cc 00 00 00 48 8b 4d 38 f6 c1 01 0f 84 43 01 00 00 0f 31 48 c1 e2 > [ 2275.771016] RSP: 0018:a81e4192bd48 EFLAGS: 0086 > [ 2275.771021] RAX: 0002 RBX: 00025290 RCX: > > [ 2275.771024] RDX: RSI: 000efc6c RDI: > 89691d537270 > [ 2275.771026] RBP: 89691d537270 R08: 00b0 R09: > 0211deffb6c0 > [ 2275.771029] R10: 0211def07480 R11: 0211def07480 R12: > 89691d542300 > [ 2275.771031] R13: R14: R15: > 000efc6c > [ 2275.771038] ? xntimer_start+0x37/0x220 > [ 2275.771042] program_htick_shot+0x8d/0x130 > [ 2275.771047] clockevents_program_event+0x8d/0xf0 > [ 2275.771052] hrtimer_interrupt+0x14b/0x250 > [ 2275.771057] smp_apic_timer_interrupt+0x4e/0x120 > [ 2275.771060] __ipipe_do_sync_stage+0x167/0x1d0 > [ 2275.771065] ipipe_unstall_root+0x55/0x60 > [ 2275.771069] cpuidle_enter_state+0xc9/0x360 > [ 2275.771075] do_idle+0x1ef/0x280 > [ 2275.771080] cpu_startup_entry+0x6f/0x80 > [ 2275.771083] start_secondary+0x178/0x1a0 > [ 2275.771087] secondary_startup_64+0xa4/0xb0 > [ 2275.771094] I-pipe tracer log (100 points): > [ 2275.771096] |*#func 0 > ipipe_trace_panic_freeze+0x0 (ipipe_root_only+0xcf) > [ 2275.771120] |*#func -1 ipipe_root_only+0x0 > (ipipe_stall_root+0xe) > [ 2275.771142] |*#func -1 ipipe_stall_root+0x0 > (__ipipe_trap_prologue+0x11a) > [ 2275.771164] |*#func -2 ipipe_test_root+0x0 > (__ipipe_trap_prologue+0xc2) > [ 2275.771186] |*#func -2 __ipipe_trap_prologue+0x0 > (int3+0x45) > [ 2275.771207] |*#func -2 xntimer_start+0x0 > (program_htick_shot+0x8d) > [ 2275.771229] | #begin 0x8000 -2 program_htick_shot+0xdb > (<>) > [ 2275.771251] #func -2 program_htick_shot+0x0 > (clockevents_program_event+0x8d) > [ 2275.771273] #func -3 ktime_get+0x0 > (clockevents_program_event+0x50) > [ 2275.771294] #func -3 > clockevents_program_event+0x0 (hrtimer_interrupt+0x14b) > [ 2275.771316] #func -3 tick_program_event+0x0 > (hrtimer_interrupt+0x14b) > [ 2275.771338] | #end 0x8001 -3 ipipe_stall_root+0x53 > (<>) > [ 2275.771360] | #begin 0x8001 -3 ipipe_stall_root+0x47 > (<>) > [ 2275.771381] | #end 0x8001 -3 ipipe_root_only+0x74 > (<>) > [ 2275.771402] | #begin 0x8001 -3 ipipe_root_only+0x68 > (<>) > [ 2275.771424] #func -3 ipipe_root_only+0x0 > (ipipe_stall_root+0xe) > [ 2275.771446] #func -3 ipipe_stall_root+0x0 > (_raw_spin_unlock_irqrestore+0x1e) > [ 2275.771469] | #end 0x8001 -3 ipipe_root_only+0x74 > (<>) > [ 2275.771490] | #begin 0x8001 -4 ipipe_root_only+0x68 > (<>) > [ 2275.771511] #func -4 ipipe_root_only+0x0 > (ipipe_restore_root+0xe) > [ 2275.771533] #func -4 ipipe_restore_root+0x0 > (_raw_spin_unlock_irqrestore+0x1e) > [ 2275.771556] #func -4 > _raw_spin_unlock_irqrestore+0x0 (hrtimer_interrupt+0x13d) > [ 2275.771577] #func -4 > __ipipe_spin_unlock_debug+0x0 (hrtimer_interrupt+0x132) > [ 2275.771599] #func -4 > __hrtimer_next_event_base+0x0 (hrtimer_interrupt+0x11b) > [ 2275.771621] #func -4 > __hrtimer_next_event_base+0x0 (__hrtimer_get_next_event+0x6c) > [ 2275.771642] #func -4 > __hrtimer_get_next_event+0x0 (hrtimer_interrupt+0x11b) > [ 2275.771663] #func -4 enqueue_hrtimer+0x0 > (__hrtimer_run_queues+0x137) > [ 2275.771685] | #end 0x8001 -4 ipipe_stall_root+0x53 > (<>) > [
Stalled head domain on x86_64 platform
Hi all! I've encountered with the following ipipe error message. What can it be? Thank you! Best, Alex [ 2275.770959] I-pipe: Detected stalled head domain, probably caused by a bug. A critical section may have been left unterminated. [ 2275.770965] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G W O 4.19.84-xenomai-nicevt4.debug1 #1 [ 2275.770968] Hardware name: GIGABYTE MZ31-AR0-00/MZ31-AR0-00, BIOS F13 04/15/2019 [ 2275.770970] I-pipe domain: Linux [ 2275.770973] Call Trace: [ 2275.770984] dump_stack+0x8c/0xc0 [ 2275.770990] ipipe_root_only.cold+0x11/0x32 [ 2275.770994] ipipe_stall_root+0xe/0x60 [ 2275.770999] __ipipe_trap_prologue+0x11a/0x300 [ 2275.771005] int3+0x45/0x70 [ 2275.771010] RIP: 0010:xntimer_start+0x37/0x220 [ 2275.771013] Code: 89 ce 41 55 49 89 d5 41 54 55 48 89 fd 53 48 83 ec 08 48 8b 47 68 4c 8b 25 16 52 2e 01 48 63 40 18 4c 03 24 c5 00 27 2b 98 cc 00 00 00 48 8b 4d 38 f6 c1 01 0f 84 43 01 00 00 0f 31 48 c1 e2 [ 2275.771016] RSP: 0018:a81e4192bd48 EFLAGS: 0086 [ 2275.771021] RAX: 0002 RBX: 00025290 RCX: [ 2275.771024] RDX: RSI: 000efc6c RDI: 89691d537270 [ 2275.771026] RBP: 89691d537270 R08: 00b0 R09: 0211deffb6c0 [ 2275.771029] R10: 0211def07480 R11: 0211def07480 R12: 89691d542300 [ 2275.771031] R13: R14: R15: 000efc6c [ 2275.771038] ? xntimer_start+0x37/0x220 [ 2275.771042] program_htick_shot+0x8d/0x130 [ 2275.771047] clockevents_program_event+0x8d/0xf0 [ 2275.771052] hrtimer_interrupt+0x14b/0x250 [ 2275.771057] smp_apic_timer_interrupt+0x4e/0x120 [ 2275.771060] __ipipe_do_sync_stage+0x167/0x1d0 [ 2275.771065] ipipe_unstall_root+0x55/0x60 [ 2275.771069] cpuidle_enter_state+0xc9/0x360 [ 2275.771075] do_idle+0x1ef/0x280 [ 2275.771080] cpu_startup_entry+0x6f/0x80 [ 2275.771083] start_secondary+0x178/0x1a0 [ 2275.771087] secondary_startup_64+0xa4/0xb0 [ 2275.771094] I-pipe tracer log (100 points): [ 2275.771096] |*#func 0 ipipe_trace_panic_freeze+0x0 (ipipe_root_only+0xcf) [ 2275.771120] |*#func -1 ipipe_root_only+0x0 (ipipe_stall_root+0xe) [ 2275.771142] |*#func -1 ipipe_stall_root+0x0 (__ipipe_trap_prologue+0x11a) [ 2275.771164] |*#func -2 ipipe_test_root+0x0 (__ipipe_trap_prologue+0xc2) [ 2275.771186] |*#func -2 __ipipe_trap_prologue+0x0 (int3+0x45) [ 2275.771207] |*#func -2 xntimer_start+0x0 (program_htick_shot+0x8d) [ 2275.771229] | #begin 0x8000 -2 program_htick_shot+0xdb (<>) [ 2275.771251] #func -2 program_htick_shot+0x0 (clockevents_program_event+0x8d) [ 2275.771273] #func -3 ktime_get+0x0 (clockevents_program_event+0x50) [ 2275.771294] #func -3 clockevents_program_event+0x0 (hrtimer_interrupt+0x14b) [ 2275.771316] #func -3 tick_program_event+0x0 (hrtimer_interrupt+0x14b) [ 2275.771338] | #end 0x8001 -3 ipipe_stall_root+0x53 (<>) [ 2275.771360] | #begin 0x8001 -3 ipipe_stall_root+0x47 (<>) [ 2275.771381] | #end 0x8001 -3 ipipe_root_only+0x74 (<>) [ 2275.771402] | #begin 0x8001 -3 ipipe_root_only+0x68 (<>) [ 2275.771424] #func -3 ipipe_root_only+0x0 (ipipe_stall_root+0xe) [ 2275.771446] #func -3 ipipe_stall_root+0x0 (_raw_spin_unlock_irqrestore+0x1e) [ 2275.771469] | #end 0x8001 -3 ipipe_root_only+0x74 (<>) [ 2275.771490] | #begin 0x8001 -4 ipipe_root_only+0x68 (<>) [ 2275.771511] #func -4 ipipe_root_only+0x0 (ipipe_restore_root+0xe) [ 2275.771533] #func -4 ipipe_restore_root+0x0 (_raw_spin_unlock_irqrestore+0x1e) [ 2275.771556] #func -4 _raw_spin_unlock_irqrestore+0x0 (hrtimer_interrupt+0x13d) [ 2275.771577] #func -4 __ipipe_spin_unlock_debug+0x0 (hrtimer_interrupt+0x132) [ 2275.771599] #func -4 __hrtimer_next_event_base+0x0 (hrtimer_interrupt+0x11b) [ 2275.771621] #func -4 __hrtimer_next_event_base+0x0 (__hrtimer_get_next_event+0x6c) [ 2275.771642] #func -4 __hrtimer_get_next_event+0x0 (hrtimer_interrupt+0x11b) [ 2275.771663] #func -4 enqueue_hrtimer+0x0 (__hrtimer_run_queues+0x137) [ 2275.771685] | #end 0x8001 -4 ipipe_stall_root+0x53 (<>) [ 2275.771706] | #begin 0x8001 -5 ipipe_stall_root+0x47 (<>) [ 2275.771728] | #end 0x8001 -5 ipipe_root_only+0x74 (<>) [ 2275.771749] | #begin 0x8001 -5 ipipe_root_only+0x68 (<>) [ 2275.771770] #func -5 ipipe_root_only+0x0 (ipipe_stall_root+0xe) [ 2275.771792]
Re: Handling MSI-X interrupts in the head stage for x86 platform
On 6/1/20 12:23 PM, Meng, Fino via Xenomai wrote: Sent: Monday, June 1, 2020 4:09 PM Hi all! I have a PCIe device in x86 motherboard that generate periodic MSI-X interrupts and I would like to handle them in the head stage, how it can be done? Thank you! Appreciate any help! Best, Alex Hi Alex, Kernel/driver/serial/16550A.c is a pci device, and have less code than net/igb driver, Which specific device u want to enable? Does it have a vanilla kernel driver already? Not sure that 16550A uses MSI-X interrupts. However, net/igb does. Is it only driver in Xenomai that supports MSI-X? I am using FPGA based device for periodic interrupts which is totally custom. We have are own driver. Nevertheless, I have tested its latency from root stage driver and it is appropriately good (not over than 60us). It seems that msix irqs are not stalled anywhere. Is it possible? Can I guarantee that there will be no condition when MSIX interrupt will be deferred by head stage on more than that? What latency improvement I can expect from moving to RTDM based driver? Thank you!
