Re: [Xenomai] Can not register into GitLab
On 06/20/2018 01:45 PM, Stéphane Reichert wrote: > Hi, > > > > I would like to download an ipipe patch, but the link on the GitLab opens > a “Sign in” page > > but there is nowhere a “Reigster” option. > This is Denx's gitlab infrastructure, I don't think there is any plan to open it for registration to a broad audience. Denx kindly offered to host the project's main development trees, with accounts given to the core maintainers basically. > > > How can I create an account to be able to download these patchs please ? > The patches are hosted on a different server, where I could create a download area for 3rd-party contributions would it turn to be useful. Which architecture, platform and kernel release does this patch target? Thanks, -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [NOTICE] GIT migration completed
On 06/20/2018 06:39 PM, Philippe Gerum wrote: > On 06/20/2018 06:09 PM, karim.allah.ah...@gmail.com wrote: >> Hello Philippe, >> >> Is there still a public 'dovetail' repo somewhere? >> > > For the adventurous, there is git://l...@xenomai.org/linux-dovetail.git. > Sorry, git://lab.xenomai.org/linux-dovetail.git But you still have to be adventurous. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [NOTICE] GIT migration completed
On 06/20/2018 06:09 PM, karim.allah.ah...@gmail.com wrote: > Hello Philippe, > > Is there still a public 'dovetail' repo somewhere? > For the adventurous, there is git://l...@xenomai.org/linux-dovetail.git. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai system tick
On 06/20/2018 03:47 PM, Bradley Valdenebro Peter (DC-AE/EHP2) wrote: > Hello, > > First off, thanks to all the Xenomai community for making it possible to have > a real-time framework in Linux. > > We are a group of engineers at Bosch-Rexroth which use Linux on one of our > motion control products. Since we have real-time constraints within the > control loops Xenomai is also used. > > We recently moved from a DSP based design to a more generic CPU/Linux design. > We are using a Zynq Z-7020 SoC (2x ARM Cortex-A9 processors (ARM v7)) running > Linux 4.4/Xenomai 3.0.6. We patch the linux kernel with > ipipe-core-4.4.43-arm-8 patch. Currently we are running Linux on one CPU and > Xenomai on the other. > > Our high-level control loop runs at 8kHz (125us) and we must make sure > deadlines are met. > We are using ftrace to study the behaviour of our system. Linux is configured > with a 1000Hz (1ms) system tick. We were expecting Xenomai to use this same > tick. > By looking at a recorded trace we can see that for every Linux tick there are > 6-7 Xenomai ticks. Each Xenomai ISR tick takes around 15us-20us. This means > that for every 1ms we are using around 10% to 15% to handle these interrupts. > Find attached a screenshot of the trace using kernelshark. > > We believe our 8kHz control loop is being impacted by this. If we change the > interrupt tick affinity to the Linux CPU we see on average a 20us performance > improvement on the loop. When the Xenomai tick takes place on the Linux CPU > we experience problems on our Ethernet/PTP network (handled by Linux). > > At this point we are not looking for a workaround or a change in our system's > architecture. We want to understand Xenomai's behaviour. For that we have > some questions we were hoping you could help us with: > > > * Why is the Xenomai system tick running at such a "high" frequency? > Xenomai uses a purely oneshot mode for the core timer, so no useless periodic activity is to be expected on a normally running system. I would see three possibilities with the information at hand: - some activity is actually triggering those events, in which case you should see them by looking at this virtual file: ~ # cat /proc/xenomai/timer/coreclk CPU SCHED/SHOTTIMEOUT INTERVALNAME 0239162/150321 3ms467us- [host-timer/0] 133839/31631 10ms657us - [host-timer/1] 222189/19355 60us- [host-timer/2] 345244/41172 90us- [host-timer/3] 0221555/221554 85us100us timerfd_handler Here we see a periodic thread running at 10Khz, and four per-cpu host timers (see below). - something is wrong in the I-pipe patch, which reprograms the clock chip hw with a wrong decrementer value, in the case of the TWD chip (which should be the one present on your Zynq IIRC). For some reason, early shots are being triggered, getting Xenomai to continuously ask for more delay since the current date is still not past the due one. That might correspond to those micro delays you have been tracing. - something is wrong in the clock source management, also in the I-pipe, which delivers wrong timestamps. If Xenomai's idea of time is off-base, the rest is obviously going to be slightly, ... rough. Options 2 and 3 are unlikely though, because most people running Xenomai on ARM these days have TWD and Global timer devices on their CPU. But 4.4 is fairly old, so a glitch cannot be ruled out. If 1 is ruled out when your application runs, then I would check whether Xenomai's latency test works as expected, and does/does not generate the ticking noise by ftracing it too. > * How is this frequency established and can we modify it? > The only periodic events have to be generated by the application, e.g. using clock_nanosleep() for a trivial example. The Xenomai core (Cobalt) would only generate a single type of periodic event which is a 0.25hz watchdog if CONFIG_XENO_OPT_WATCHDOG is enabled. > * How does Xenomai/ipipe make sure the Linux system tick is delivered > accurately every 1ms? > Xenomai interposes on Linux requests for programming the next tick event on the hw, scheduling one of its own software timers at due date instead. When that timer fires, Xenomai pushes a fake IRQ down to the interrupt pipeline, which Linux interprets as the expected tick event. In the meantime, Xenomai has been able to program the timer hw the way it wanted, any number of times, for serving its own software timers. One of which being the "synthetic" Linux tick event, aka "host timer, or htimer" in the Cobalt code. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [NOTICE] GIT migration completed
Hello Philippe, Is there still a public 'dovetail' repo somewhere? Regards. On Sun, Jun 17, 2018 at 4:54 PM Philippe Gerum wrote: > > > Services are back to normal, with some changes as previously announced. > Please have a look at the web site [1] for details. > > Thanks, > > [1] https://xenomai.org > > -- > Philippe. > > ___ > Xenomai mailing list > Xenomai@xenomai.org > https://xenomai.org/mailman/listinfo/xenomai -- Karim Allah Ahmed. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] Xenomai system tick
Hello, First off, thanks to all the Xenomai community for making it possible to have a real-time framework in Linux. We are a group of engineers at Bosch-Rexroth which use Linux on one of our motion control products. Since we have real-time constraints within the control loops Xenomai is also used. We recently moved from a DSP based design to a more generic CPU/Linux design. We are using a Zynq Z-7020 SoC (2x ARM Cortex-A9 processors (ARM v7)) running Linux 4.4/Xenomai 3.0.6. We patch the linux kernel with ipipe-core-4.4.43-arm-8 patch. Currently we are running Linux on one CPU and Xenomai on the other. Our high-level control loop runs at 8kHz (125us) and we must make sure deadlines are met. We are using ftrace to study the behaviour of our system. Linux is configured with a 1000Hz (1ms) system tick. We were expecting Xenomai to use this same tick. By looking at a recorded trace we can see that for every Linux tick there are 6-7 Xenomai ticks. Each Xenomai ISR tick takes around 15us-20us. This means that for every 1ms we are using around 10% to 15% to handle these interrupts. Find attached a screenshot of the trace using kernelshark. We believe our 8kHz control loop is being impacted by this. If we change the interrupt tick affinity to the Linux CPU we see on average a 20us performance improvement on the loop. When the Xenomai tick takes place on the Linux CPU we experience problems on our Ethernet/PTP network (handled by Linux). At this point we are not looking for a workaround or a change in our system's architecture. We want to understand Xenomai's behaviour. For that we have some questions we were hoping you could help us with: * Why is the Xenomai system tick running at such a "high" frequency? * How is this frequency established and can we modify it? * How does Xenomai/ipipe make sure the Linux system tick is delivered accurately every 1ms? Thanks and best regards, Peter Bradley -- next part -- A non-text attachment was scrubbed... Name: VirtualBox_einx922v_20_06_2018_15_36_05.png Type: image/png Size: 269197 bytes Desc: VirtualBox_einx922v_20_06_2018_15_36_05.png URL: <http://xenomai.org/pipermail/xenomai/attachments/20180620/ad77f920/attachment.png> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed
Interface) Support >>>>>>>>>>>>>>> --> Processor (Disable) >>>>>>>>>>>>>>> --> CPU Frequency scaling >>>>>>>>>>>>>>> --> CPU Frequency scaling (Disable) >>>>>>>>>>>>>>> --> CPU idle >>>>>>>>>>>>>>> --> CPU idle PM support (Disable) >>>>>>>>>>>>>>> * Pocessor type and features >>>>>>>>>>>>>>> --> Processor family >>>>>>>>>>>>>>> --> Core 2/newer Xeon (if \"cat /proc/cpuinfo | grep >>>>>>>>>>>>>>> family\" >>>>>>>>>>>>>>> returns 6, set as Generic otherwise) >>>>>>>>>>>>>>> * Power management and ACPI options >>>>>>>>>>>>>>> --> Memory power savings >>>>>>>>>>>>>>> --> Intel chipset idle memory power saving driver >>>>>>>>>>>>>>> (Disable) >>>>>>>>>>>>>>> and in nucleus I have seleted RTDM drivers, in >>>>>>>>>>>>>>> interfaces,drivers etc >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> and I am using x86_64 processor configuration. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Jun 19, 2018 at 9:12 PM, Greg Gallagher >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Under the Xenomai section of menuconfig, do you have them >>>>>>>>>>>>>>>> selected as >>>>>>>>>>>>>>>> modules you can load or built into the kernel? Also you are >>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>> pretty old version on Xenomai, have you considered using >>>>>>>>>>>>>>>> Xenomai-3 >>>>>>>>>>>>>>>> instead? I haven't used Xenomai 2.6 in a while so my support >>>>>>>>>>>>>>>> may be >>>>>>>>>>>>>>>> rusty. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Jun 19, 2018 at 11:29 AM, Ashok kumar >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am getting xeno_rtdm.o,xeno_hal.o,xeno_nucleus.o. file but >>>>>>>>>>>>>>>>> I am not >>>>>>>>>>>>>>>>> getting xeno_rtdm.ko, xeno_hal.ko, xeno_nucleus.ko >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I should get .ko file to load it in kernel module . >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Jun 19, 2018 at 8:47 PM, Greg Gallagher >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> Are you building the RTDM modules? Do you see them getting >>>>>>>>>>>>>>>>>> built in >>>>>>>>>>>>>>>>>> the kernel output. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please refrain from continuously posting the same question, >>>>>>>>>>>>>>>>>> we will >>>>>>>>>>>>>>>>>> try to help you but it may take some time to respond. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Greg >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Jun 19, 2018 at 5:44 AM, Ashok kumar >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I have turned modules ON, I have attached the enable >>>>>>>>>>>>>>>>>>> modules section >>>>>>>>>>>>>>>>>>> in the kernel configuration >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> thank you >>>>>>>>>>>>>>>>>>> R.Ashokkumar >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Jun 18, 2018 at 7:30 PM, Greg Gallagher >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> Did you turn them on in menuconfig when you built your >>>>>>>>>>>>>>>>>>>> kernel? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -Greg >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Jun 18, 2018 at 1:40 AM, Ashok kumar >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I have patched xenomai -2.6.4 with linux 3.18.20 . >>>>>>>>>>>>>>>>>>>>> and installed the patched kernel, and compiled the >>>>>>>>>>>>>>>>>>>>> xenomai library using below >>>>>>>>>>>>>>>>>>>>> commands >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> cd /usr/src >>>>>>>>>>>>>>>>>>>>> sudo mkdir build_xenomai-2.6.4 >>>>>>>>>>>>>>>>>>>>> cd build_xenomai-2.6.4 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> sudo ../xenomai-2.6.4/configure --enable-shared >>>>>>>>>>>>>>>>>>>>> --enable-smp --enable-x86-sep >>>>>>>>>>>>>>>>>>>>> sudo make -j8 >>>>>>>>>>>>>>>>>>>>> sudo make install >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> in /usr/xenomai/ I am not able to get the modules >>>>>>>>>>>>>>>>>>>>> directory and xenomai modules >>>>>>>>>>>>>>>>>>>>> are not available ,xeno_rtdm,xeno_hal,xeno_nucleus. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I used the below command to load the modules >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> sudo modprobe xeno_rtdm, >>>>>>>>>>>>>>>>>>>>> sudo modprobe xeno_hal >>>>>>>>>>>>>>>>>>>>> sudo modprobe xeno_nucleus >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> but the modules are not getting loaded. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> is there any modification should be done in the make >>>>>>>>>>>>>>>>>>>>> file, or any >>>>>>>>>>>>>>>>>>>>> other options should be enabled in the configure options >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> kindly help me the get the xenomai modules available. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>>>>>>>> R.Ashokkumar >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ___ >>>>>>>>>>>>>>>>>>>>> Xenomai mailing list >>>>>>>>>>>>>>>>>>>>> Xenomai@xenomai.org >>>>>>>>>>>>>>>>>>>>> https://xenomai.org/mailman/listinfo/xenomai -- next part -- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 226468 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20180620/b89ab97a/attachment.png> -- next part -- A non-text attachment was scrubbed... Name: 2.png Type: image/png Size: 177959 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20180620/b89ab97a/attachment-0001.png> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] Can not register into GitLab
Hi, I would like to download an ipipe patch, but the link on the GitLab opens a Sign in page but there is nowhere a Reigster option. How can I create an account to be able to download these patchs please ? Best regards Stéphane ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)
Hi, Can someone help me with this issue. I compared the xenomai-3 next repo (next/kernel/drivers/net/stack/ipv4/udp/udp.c) and the changes are almost same. Now I am stuck with this.. Please help! Is there any test available for rtnet loopback ? Regards, Pintu On Tue, Jun 19, 2018 at 7:18 PM Pintu Kumar wrote: > > Hi, > I upgraded to xenomai-3-next branch for x86, but still rtnet loopback > is crashing for me. > The xenomai kernel is used from 4.9.51 until > commit: 10605b427b1408cdc6926f7c25d4a4eda527da8d > Author: Philippe Gerum > Date: Mon Mar 26 09:17:02 2018 +0200 > > ipipe-core-4.9.51-x86-5 > > Is the rtnet loopback working with 4.9 ? > Please let me know if this issue is fixed already ? > > This is the kernel logs: > -- > [612871.612307] > *** RTnet for Xenomai v3.1-devel *** > > [612871.612310] RTnet: initialising real-time networking > [612906.855980] initializing loopback... > [612906.855998] RTnet: registered rtlo > [613075.162006] BUG: unable to handle kernel paging request at > 7ffc7893b148 > [613075.162009] IP: [] rt_udp_getfrag+0x3e/0x110 [rtudp] > [613075.162013] PGD 744f76067 > [613075.162014] PUD 80e1ae067 > [613075.162015] PMD 6893dd067 > [613075.162015] PTE 800581853867 > > [613075.162018] Oops: 0001 [#1] SMP > [613075.162019] Modules linked in: rt_loopback rtpacket rtudp rtipv4 > rtnet binfmt_misc 8021q garp mrp stp llc rfcomm bnep > snd_hda_codec_hdmi nls_iso8859_1 eeepc_wmi intel_rapl btusb asus_wmi > x86_pkg_temp_thermal btrtl sparse_keymap intel_powerclamp coretemp > ath10k_pci kvm ath10k_core irqbypass ath mac80211 crct10dif_pclmul > crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_realtek > aes_x86_64 snd_hda_codec_generic lrw cfg80211 gf128mul glue_helper > ablk_helper snd_hda_intel cryptd snd_hda_codec snd_hda_core input_leds > snd_hwdep mei_me mei shpchp serio_raw hci_uart btbcm btqca btintel > bluetooth acpi_als kfifo_buf intel_lpss_acpi industrialio intel_lpss > mac_hid acpi_pad autofs4 hid_generic usbhid nouveau mxm_wmi ttm > psmouse e1000e ptp pps_core ahci libahci i2c_hid pinctrl_sunrisepoint > wmi hid video > [613075.162049] pinctrl_intel fjes > [613075.162052] CPU: 0 PID: 12658 Comm: rtnet-client Not tainted > 4.9.51-amd-x86-64-pintu-xeno3-rtdm #4 > [613075.162053] Hardware name: System manufacturer System Product Name/xxx > [613075.162054] I-pipe domain: Linux > [613075.162055] task: 903e8921da00 task.stack: 9e2f03348000 > [613075.162056] RIP: 0010:[] [] > rt_udp_getfrag+0x3e/0x110 [rtudp] > [613075.162058] RSP: 0018:9e2f0334bb70 EFLAGS: 00010202 > [613075.162059] RAX: RBX: 000a RCX: > 7ffc7893b140 > [613075.162060] RDX: RSI: 903e88e431e4 RDI: > 9e2f0334bc40 > [613075.162061] RBP: 9e2f0334bb90 R08: 9e2f0334bdb8 R09: > > [613075.162062] R10: 903e88e43100 R11: 90400c1c8800 R12: > 903e88e431e4 > [613075.162063] R13: 0001 R14: 9e2f0334bc40 R15: > 001e > [613075.162064] FS: 7f310b789740() GS:90401620() > knlGS: > [613075.162065] CS: 0010 DS: ES: CR0: 8005003b > [613075.162066] CR2: 7ffc7893b148 CR3: 000744e5b000 CR4: > 003406f0 > [613075.162067] DR0: DR1: DR2: > > [613075.162067] DR3: DR6: fffe0ff0 DR7: > 0400 > [613075.162068] Stack: > [613075.162069] 9040121bec00 90400e262240 9e2f0334bdb8 > 000a > [613075.162071] 9e2f0334bc00 c0a0f204 903dd1a84500 > 9e2f0334bc10 > [613075.162074] 00033768 9e2f0334bc40 c0a05000 > 000f > [613075.162076] Call Trace: > [613075.162091] [] rt_ip_build_xmit+0x1c4/0x2a0 [rtipv4] > [613075.162093] [] ? 0xc0a05000 > [613075.162094] [] rt_udp_sendmsg+0x37b/0x3d0 [rtudp] > [613075.162097] [] ? update_curr+0x66/0x180 > [613075.162098] [] ? dequeue_entity+0x268/0xc00 > [613075.162100] [] ? ___xnsched_run.part.73+0x3d7/0x400 > [613075.162102] [] ? hrtick_update+0x5/0x70 > [613075.162103] [] ? dequeue_task_fair+0x587/0x900 > [613075.162105] [] ? CoBaLt_recvmmsg+0x30/0x30 > [613075.162106] [] ? CoBaLt_recvmmsg+0x30/0x30 > [613075.162108] [] rtdm_fd_sendmsg+0xcb/0x240 > [613075.162109] [] ? CoBaLt_recvmmsg+0x30/0x30 > [613075.162111] [] CoBaLt_sendmsg+0x4e/0x70 > [613075.162113] [] ipipe_syscall_hook+0x117/0x340 > [613075.162114] [] __ipipe_notify_syscall+0xbf/0x170 > [613075.162116] [] pipeline_syscall+0x8/0x1b > [613075.162118] Code: 54 49 89 f4 53 89 cb 8b 57 20 0f 85 c3 00 00 00 > 85 d2 7e 2f 8b 47 24 45 31 ed 49 63 cd 89 c2 41 83 c5 01 48 c1 e1 04 > 49 03 4e 18 <8b> 71 08 48 8b 39 e8 e7 f4 a0 e6 41 8b 56 20 41 89 46 24 > 44 39 > [613075.162141] RIP [] rt_udp_getfrag+0x3e/0x110 [rtudp] > [613075.162143] RSP > [613075.162144] CR2: 7ffc7893b148 >
