The meeting just started.
-Original Message-
From: Xenomai On Behalf Of Meng, Fino via Xenomai
Sent: Wednesday, March 24, 2021 9:51 AM
To: xenomai@xenomai.org
Subject: Xenomai community call on today, March 24th, UTC 7:00
Sorry for the late reminder, as planned, we have the Xenomai
Sorry for the late reminder, as planned, we have the Xenomai community call
Topics may include but not limited to upstream/downstream project plan, status
update, and technical discussion.
It's an open online meeting that anyone can join and ask questions,
Time: March *24th*
Wednesday, UTC 7:00
Cool~ this is really a good idea!
BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling
>
>Hi all,
>
>in order to make central project resources more accessible to
>contributors, I've set up a mirror of the main Xenomai repository on
>gitlab.com:
>
>https://gitlab.com/Xenomai/xenomai-hacker-space
>
Just started.
BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling
>-Original Message-
>From: Xenomai On Behalf Of Meng, Fino via Xenomai
>Sent: Tuesday, March 9, 2021 9:54 PM
>To: xenomai@xenomai.org
>Subject: reminder: Xenomai community call on tomorrow, March 10th, UTC 7:0
As planned, we have the Xenomai community call
Topics may include but not limited to upstream/downstream project plan, status
update, and technical discussion.
It's an open online meeting that anyone can join and ask questions,
Time: March 10th
Wednesday, UTC 7:00
15:00 for China
8:00 for
I did some search but didn't find any detailed paper about use perf with
Xenomai,
Assume on x86_64, in theory, does perf can work on Xenomai out-of-box,
or need adapt for IPIPE and Cobalt scheduler?
BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling
The meeting just started.
BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling
>-Original Message-
>From: Xenomai On Behalf Of Meng, Fino via Xenomai
>Sent: Tuesday, February 23, 2021 7:34 PM
>To: xenomai@xenomai.org
>Subject: Reminder: Xenomai community call on tomorrow, Feb
As planned, we have the Xenomai community call tomorrow,
Topics may include but not limited to upstream/downstream project plan, status
update, and technical discussion.
It's an open online meeting that anyone can join and ask questions,
Time:
Feb 24th (Wednesday), UTC 7:00
15:00 for China
8:00
Sorry for the late reminder, As planned, we have the Xenomai community call
Topics may include but not limited to upstream/downstream project plan, status
update, and technical discussion.
It's an open online meeting that anyone can join and ask questions,
Time:
Feb 10th (Wednesday), UTC 7:00
The meeting just started, welcome to join.
>
>Hi all,
>
>As planned, tomorrow will have Xenomai community call,
>Topics may include but not limited to upstream/downstream project plan, status
>update, and technical discussion.
>It's an open online meeting that anyone can join and ask questions,
Hi all,
As planned, tomorrow will have Xenomai community call,
Topics may include but not limited to upstream/downstream project plan, status
update, and technical discussion.
It's an open online meeting that anyone can join and ask questions,
Time:
Jan 27th (Wednesday), UTC 7:00
15:00 for
>
>The I-pipe and Cobalt ports to x86_32 received neither careful
>maintenance nor testing for ages. In addition, Dovetail does not support
>the 32bit legacy mode, and there is no plan to do so. Therefore I
>recommend to stop supporting the x86_32 architecture starting from
>Xenomai 3.2, which
The meeting just started, welcome to join.
BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling
>-Original Message-
>From: Xenomai On Behalf Of Meng, Fino via Xenomai
>Sent: Tuesday, January 12, 2021 9:52 PM
>To: xenomai@xenomai.org
>Subject: remainder: Xenomai community c
Hi all,
As planned, tomorrow will have the second time of Xenomai community call,
Topics may include but not limited to upstream/downstream project plan, status
update, and technical discussion, etc.
It's an open online meeting that anyone can join and ask questions,
Time:
Jan 13th
On Fri, Sep 18, 2020 at 03:05:28PM +0200, Jan Kiszka wrote:
>
>
> On 18.09.20 08:32, Fino Meng wrote:
> > Signed-off-by: Fino Meng
> > Signed-off-by: Mingliang Hu
> > ---
> > include/cobalt/kernel/stat.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
Hi all & Jan,
I just sent out the 4 patches again by git send-email, I applied them on branch
: next
And the IPIPE part is hosting here for review:
https://github.com/intel/linux-stable-xenomai/tree/review/5.4.59/stable/ipipe-x86
combine these 2 parts, build and boot is OK, latency run OK.
>Sent: Friday, September 18, 2020 12:53 AM
>
>Signed-off-by: Fino Meng
>Signed-off-by: Mingliang Hu
>---
> kernel/cobalt/arch/x86/thread.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
>index
>Sent: Monday, September 14, 2020 11:51 PM
>
>On 14.09.20 17:40, Meng, Fino via Xenomai wrote:
>> Hi all,
>>
>> A updated patchset was updated to this branch:
>> https://github.com/intel/linux-stable-xenomai/tree/review/5.4.59/stabl
>> e/ipipe/xenomai-3.1 t
Hi all,
A updated patchset was updated to this branch:
https://github.com/intel/linux-stable-xenomai/tree/review/5.4.59/stable/ipipe/xenomai-3.1
this version is more clean than previous, only one more patch for IPIPE part,
and one more patch for Xenomai 3.1 part.
System hang usually because of the CPU run into a dead loop.
Most common debug method is enable serial port and enable/add kernel log by
hand.
Intel do offers advanced debug tools(similar with Lauterbach Trace32):
Intel System Debugger ( part of the Intel System Studio suite)
Hi gopi,
It will take time to root cause such a issue, let’s find a WA first then don’t
block your project.
I just tried to remove I2C_I801 driver, re-compile kernel image and it boot
fine on my test board.
--- a/arch/x86/configs/xenomai_test_defconfig
+++
>Sent: Wednesday, September 9, 2020 6:20 PM
>
>Yes, the motherboard manufacturer has shared the bus with other devices too. I
>didn't change any kernel configuration with
>respect to xenomai, but the issue was not there in 4.15.0 which is not RT
>patched where I am not getting this kind of
Hi all,
Today I uploaded a new version that can build and run,
https://github.com/intel/linux-stable-xenomai/commits/review/5.4.58/stable/ipipe/xenomai-3.1
step to build after clone:
cp kernel_config_xenomai .config
make olddefconfig
make bindeb-pkg -j16
if build OK, u can install
Dear all,
We ported IPIPE patch from 4.19.89-x86-9 to Linux stable 5.4.52, temporarily
uploaded to github for review:
https://github.com/intel/linux-stable-xenomai/tree/review/5.4.52/stable/ipipe/xenomai-3.1
pls help to review and check mistakes. I didn't build it yet, due to I am not
>On 7/21/20 7:26 AM, Meng, Fino wrote:
>>
>>> Sent: Tuesday, July 21, 2020 4:47 AM
>>>
>>> FWIW, I'm investigating the opportunity for rebasing Dovetail - and
>>> therefore the EVL core - on the PREEMPT_RT code base, ahead of the
>>> final integration of the latter into the mainline kernel tree.
>Sent: Tuesday, July 21, 2020 4:47 AM
>
>FWIW, I'm investigating the opportunity for rebasing Dovetail - and therefore
>the EVL core - on the PREEMPT_RT code base,
>ahead of the final integration of the latter into the mainline kernel tree. In
>the same move, the goal would be to leverage the
>Sent: Sunday, July 19, 2020 2:27 PM
>
>Hi, list
>
>I build a kernel Deb with Xenomai-v3.1 and Linux-v4.19.84.
>But what confuses is that it works well on one platform whereas it causes the
>kernel failing to boot up(the error message:
>init failed:
>-19).
>Could you please shed some light on
Hi hanlin,
Does it need specific hardware to reproduce this issue? I would like to try,
BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling
>-Original Message-
>From: Xenomai On Behalf Of wuhanlin via Xenomai
>Sent: Thursday, July 16, 2020 11:04 PM
>To: xenomai@xenomai.org
>Subject:
>Sent: Friday, July 17, 2020 6:18 PM
>
>Hi, 孟祥夫
>Thank you for taking the time to respond to my question.
>
>>In my understanding cgroup's design is exclusionary with
>>real-time/deterministic/time coordinate design.
>>The latency/jitter is already down to 20us level, how it can endure
In my understanding cgroup's design is exclusionary with
real-time/deterministic/time coordinate design,
The latency/jitter is already down to 20us level, how it can endure cgroup's
volatility,
Do u really have strong requirement for this scenario? maybe it will work on a
highly fine-tuned
>Sent: Saturday, July 11, 2020 10:26 PM
>
>Hi all!
>
>I am using Xenomai 3.1 with 4.19.124 I-pipe patchon a smp motherboard. For my
>RT task I allocate few CPU cores with
>isolcpus option. However, large latency spikes are noticed due to igb watchdog
>activities (I am using common igb driver,
The steps I have used:
1) add xenomai group
```
sudo addgroup xenomai --gid 1234
sudo addgroup root xenomai
sudo usermod -a -G xenomai $USER
```
2) update kernel cmd
```
sudo vim /etc/default/grub
\\ add xenomai.allowed_group=1234 to kernel cmd line
sudo update-grub
```
3) udpate udev
```
Maybe it's due to RT group scheduling, would u try this:
sysctl -w kernel.sched_rt_runtime_us=-1
//or
echo $$ > /sys/fs/cgroup/cpu/cgroup.procs
https://github.com/systemd/systemd/blob/master/README
We recommend to turn off Real-Time group scheduling in the
kernel when using
>
>I think of 2 benefit by running tsn over rtnet + xenomai network driver
>
>* better performance since xenomai delivering stringent real-time
>guarantee and rtnet is smaller network stack
>
>* xenomai rt application can run on tsn network
>
>Is that right?
>
Yes that's right.
On
>Sent: Tuesday, June 16, 2020 10:39 PM
>
>On 16.06.20 16:00, Peter Wong wrote:
>> Can we compile linuxptp (cobalt POSIX wrap) to run on RTnet + Xenomai
>> I210 driver so that we only need one NIC to run TSN on RTnet?
>>
>
>There is nothing like that upstream so far. Maybe Fino or Florent
>Sent: Monday, June 15, 2020 11:58 PM
>
>On 15.06.20 17:34, Per Oberg via Xenomai wrote:
>> Hi list
>>
>> I thought I'd take the xenomai-images from [1] out for a spin and I think I
>> got it working. However, A few pointers about
>what is what would have been helpful.
>>
>> E.g.
>>
>> Under
>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
>Sent: Wednesday, May 27, 2020 10:00 PM
>
>On 27.05.20 14:07, Meng, Fino via Xenomai wrote:
>> hi Jan:
>>
>> with the x86-64_defconfig in gitlab.denx.de/Xenomai/xenomai-images,
>> the built image cannot boot on our test device (CPU is WHL8665U) after
>> c
>Sent: Thursday, May 14, 2020 12:15 AM
>
>Hi Fino,
>
>On 13.05.20 17:56, Meng, Fino wrote:
>> Hi Jan & Quirin:
>>
>> We have studied ISAR & kas-docker in these 2 weeks and mastered basic
>> knowledges, thanks for the example code
>> gitlab.denx.de/Xenomai/xenomai-images;
>>
>> then we want to
Hi Jan & Quirin:
We have studied ISAR & kas-docker in these 2 weeks and mastered basic
knowledges,
thanks for the example code gitlab.denx.de/Xenomai/xenomai-images;
then we want to make a production BSP for general x86-64 uefi board, including
Xenomai/preempt-rt/vanilla kernel
but currently
>Sent: Monday, May 11, 2020 1:10 PM
>
>Hi,
>Thank you for your response.
>
>>>If Head domain's interrupts & threads occupied CPU, the system may
> deadlock there since nothing can kill them.
>What do you mean? I could not get the idea.When this happen? And how?Does
> it have
>Sent: Sunday, May 10, 2020 1:12 PM
>
>Hi,
>I think mutex lock should not be shared bettween rt thread and nrt thread,
>because if i use the posix mutex api
>implemented by linux,it causes the rt thread switch to the secondary mode.
>
>As per the
hi team,
These days I am working on https://gitlab.denx.de/Xenomai/xenomai-images which
use kas-docker,
I need to customize kernel command line for my build. The 2 ways I found now:
1) directly modify wic/x86-64-efi.wks, update following line:
bootloader --ptable gpt --timeout=5 --append "rw
>Sent: Monday, April 27, 2020 10:17 AM
>
>Hi Meng:
>
>> We use Ftrace to check if Cobalt thread is rightly sched; I can help to
>> setup Ftrace env on your machine, if u interested,
>
>Yes, if you have any guideline to help me setup this?
We plan to add Ftrace guide on:
>Sent: Sunday, April 26, 2020 7:05 PM
>
>Hi all:
>
>i have ported a c based application which is a profinet network stack and it
>was running ok in common x86 linux platform as a
>regular process except some realtime issue.
>
>For the realtime issue,i have to ported to a xenomai application
>
>From: gopi ratnakaram Sent: Friday, April
>24, 2020 3:44 PM
>
>Dear Fino,
>
>After doing all of the steps mentioned in the following link,
>https://github.com/intel/linux-stable-xenomai/wiki/Guide-
>the following error I am getting during testing on my C246P chipset based
>industrial
>
>Thank you for your email response Fino.
>
>Maybe due to 4.9.* is too far away from Ubuntu 1804's original kernel; What
>will be the issue in this case? Due to any hardware
>driver dependency causing this issue?
>
>We make this repo for convenience, Kernel version is 4.19.59 with some Intel
>
>Dear team members,
>
>I tried installing the Xenomai patch on live USB loaded with Ubuntu 18.04.
>I have patched kernel version 4.9.38 and tried to boot the Xenomai patched
>one. When I try to boot my motherboard it is
>unable to boot. Can I install the Xenomai patch on Live USB? What is
>
>dear Xenomai Team:
>
>When we tested on the Intel(r) Celeron(r) processor 1047ue (third
>generation) motherboard (using kernel version: 4.1.18, xenomai version: 2.6.
>5, patch: ipipe-core-4.1.18-x86-3. ), The real-time test results meet the
>requirements.But the 4.1.18 version of the kernel
> From: Xenomai On Behalf Of ??? via
> Xenomai
> Sent: Monday, April 13, 2020 3:21 PM
> To: xenomai
> Subject: How could I allocate a huge memory in rtdm driver?
>
> Hi,
> I am using xenomai 3.1.
>
> How could I allocate a huge memory which may be larger then 50MB in
> rtdm driver?
>
> I'm thinking it's worth as a troubleshooting step to remove the GPU, no
> graphics at all (nor integrated) and do graphics completely over USB and see
> if those spikes come back.
>
> Alec
We have discuss with approach;
but our users usually need to draw 3D when they need GUI; pure CPU 3D
> I have seen latency spikes caused by things in X with all DRM/KMS drivers
> disabled, only using xf86-video-vesa with Mesa software rasterizer. X can
> cause spikes without any GPU involvement, and I'm interested in this subject
> as well.
>
> Alec
If BIOS has the items, you can try set GPU
On 08.04.20 10:39, 孙世龙 via Xenomai wrote:
> Hi,
> Why X11 influences the latency of xenomai？I guess it has some relation to
> GPU.Could you make me more clearly?
> I have solved the latency . I am using QT runing on linux
> framebuffer ,disabled X11 at all.I really hope to why X11
Hello Qianyu,
Would you pls provide more details on the steps how did u do the test,
assume other people not familiar with what u doing and , can repeat your test
from your description easily,
thanks!
BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling
-Original Message-
From: Xenomai
Thanks Jan & Henning, got some ideas.
In 2020 our team's focus is modify UEFI BIOS for real time capability;
Most of OEM's industry PC cannot reach good worst case jitter using out of box
BIOS, these items needed by PnP configs are hidden;
We want to push BIOS vendors and OEMs do real-time,
Hi Jan
Regarding to torture tests, do we have a recommend test suite & working flow
from the community?
I searched xenomai wiki but didn't find a guide for this.
We plan to recommend UP Extreme board (https://up-board.org/up-xtreme/) to
public users since it's easy to buy for anyone
And we
56 matches
Mail list logo
