Hello Xenomai group,
We're in the process of moving from Xenomai 3.0.7/4.1.18 to
3.1/4.14.85. Testing one of our apps we found that select() was
returning -1 with errno == EADV. This app was written before we knew
about the recommendation from Philippe contained in this message:
On 4/14/2021 4:50 PM, Greg Gallagher via Xenomai wrote:
On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni <
thomas.petazz...@bootlin.com> wrote:
On Wed, 14 Apr 2021 14:41:29 -0400
Greg Gallagher wrote:
Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake, I’ll fix up
and generate a
RT tasks can create/map standard Linux shared memory using either
mmap(), or shm_open().?0?2 However, if you need dynamic memory management
inside that shared memory, you'd have to add that, along with any
required locking, so in that case you're better off using rt_heap_xxx()
routines.
But,
Greetings Xenomai list,
We are seeing the following stack trace when we 'ifup' the e1000e
adapter. 4.19 exhibits same failure, 4.14.96 also fails but with a
different stack trace. Last working version is 4.14.85.
Thanks in advance for any assist,
Steve
On 2/24/2021 2:52 PM, Greg Gallagher wrote:
On Wed, Feb 24, 2021 at 3:45 PM steve freyder via Xenomai
mailto:xenomai@xenomai.org>> wrote:
Greetings Xenomai list,
I have a Linux OE 4.14.85 build with Xenomai 3.1 -next branch, and am
seeing this:
root@ICB-G3L:~ #
Greetings Xenomai list,
I have a Linux OE 4.14.85 build with Xenomai 3.1 -next branch, and am
seeing this:
root@ICB-G3L:~ # uname -a
Linux ICB-G3L 4.14.85_C01571-15S01A01.000.zimg+35a84af5b7 #1 SMP Mon Feb
22 20:57:38 UTC 2021 armv7l GN
U/Linux
root@ICB-G3L:~ # smokey --run=posix_mutex
[
OK, so then my theory about it having to do with launching a printf
helper must be wrong (maybe that only happens on the original thread).
I don't recall whether you had a flush call after your printf though...
On 1/3/2021 4:22 PM, Leandro Bucci wrote:
I understand, but it's strange because
Might need some help from Philippe on this one but my thinking says that
thread creation happens in secondary mode, so there's gotta be at least
*one* mode switch on the way to becoming a cobalt thread running in
primary mode, perhaps the second one has to do with launching the
background
Each time I would do something like this:
printf(...) ;
fflush(stdout) ;
rt_task_sleep(1e9/5) ;
rt_task_inquire(...) ;
msw incremented by 1, csw would increment by 2.
On 1/3/2021 2:29 PM, Leandro Bucci via Xenomai wrote:
Hi, I have a strange behavior regarding the "mode switch".
In the
Right.
AKA, "mode switch", a switch from "primary mode" to "secondary mode", or
vice versa.
One place you can find that information is in:
/proc/xenomai/sched/acct
there are two fields MSW, and CSW which count mode/context switches
per-process. This requires an open, a read loop to locate
On 5/12/2020 1:37 AM, 孙世龙 wrote:
Hi,Steve:
Thank you for the clarification.
>>Will ADOES wake up the related linux process at once when the head
>>domain write something to the XDDP node?* Or, the linux process
>>has to wait for the schedule of linux kernel, if the processor is
On 5/11/2020 9:16 PM, 孙世龙 via Xenomai wrote:
Hi,
As i am using XDDP to transport messages bettween the head domain and
linux domain(i mean there are two processes, one is rt process, the other
is linux process.),I wonder that when the linux process could recieve the
message？
*Will
On 2/21/2020 10:10 AM, LOCHE Daniel via Xenomai wrote:
On 20/02/2020 à 22:36, steve freyder via Xenomai wrote:
On 2/20/2020 7:29 AM, LOCHE Daniel via Xenomai wrote:
Hello everyone,
I a currently factoring my application to go from a multi-thread one
to a multi-process one (C++11).
I am using
On 2/20/2020 7:29 AM, LOCHE Daniel via Xenomai wrote:
Hello everyone,
I a currently factoring my application to go from a multi-thread one
to a multi-process one (C++11).
I am using Xenomai 3.0.5 on Linux Mint 18.04 (on a Intel 8250U
computer), 90% alchemy library (10% posix).
(either
On 2/19/2020 9:36 AM, Jan Kiszka wrote:
On 19.02.20 15:58, steve freyder via Xenomai wrote:
On 2/19/2020 4:02 AM, Jan Kiszka wrote:
On 19.02.20 09:56, Jan Kiszka via Xenomai wrote:
On 18.02.20 23:33, steve freyder via Xenomai wrote:
Hello again Xenomai group,
Was testing gdb on xenomai 3.1
On 2/19/2020 4:02 AM, Jan Kiszka wrote:
On 19.02.20 09:56, Jan Kiszka via Xenomai wrote:
On 18.02.20 23:33, steve freyder via Xenomai wrote:
Hello again Xenomai group,
Was testing gdb on xenomai 3.1, ran into this (Xenomai 3.1 on
armv7-a, iMX6-dual-lite)
root@g3l-21:~ # gdb /usr/bin
Hello again Xenomai group,
Was testing gdb on xenomai 3.1, ran into this (Xenomai 3.1 on armv7-a,
iMX6-dual-lite)
root@g3l-21:~ # gdb /usr/bin/rtcanrecv
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
Hello Xenomai group.
We appear to have a regression in the rt_imx_uart driver in Xenomai
3.1. The problem didn't exist in 3.0.7, and I believe it did exist in
3.0.10. Between those two I did not try to narrow it down. I
discovered this when connecting a UART on a 3.1 system to a UART on a
On 12/5/2019 1:22 PM, Jan Kiszka via Xenomai wrote:
On 05.12.19 08:50, Electronic Dept. - Vbm Group via Xenomai wrote:
Hello Jan,
thank you for your quick answer. Adding -lalchemy manually, I get the
following:
There is more missing. What does "xeno-config --skin=alchemy --ldflags"
report for
On 11/6/2019 3:04 PM, Pierre FICHEUX via Xenomai wrote:
Hi,
Is there a way to get the Xenomai thread "pid" with POSIX API ? I didn't
see anything in the "thread management" section.
thx
Hi,
This file:
https://xenomai.org/documentation/xenomai-3/pdf/xeno3prm.pdf
makes several references to
On 4/26/2019 4:18 PM, Lowell Gilbert via Xenomai wrote:
Hi.
I have an application working successfully with Xenomai 3.0.8 on a 4.14
kernel. I use Yocto to build the system; when I tried to move to a newer
version of Yocto, my application hung on trying to become a daemon. This
is happening with
On 4/22/2019 5:56 PM, C Smith wrote:
Please don't think the cross-link.c app config has the magic answer.
Changing RX timeouts to prevent TX stalls would be an open loop hack
that might fail the serial traffic jitters differently. The most
suspicious difference between the two apps is that :
On 4/22/2019 2:51 PM, Steve Freyder via Xenomai wrote:
On 4/22/2019 1:45 AM, Jan Kiszka wrote:
On 22.04.19 08:40, C Smith via Xenomai wrote:
Thanks for your insight, Steve. I didn't realize rt_dev_write() doesnt
actually stall until it is called many times and the 4K TX buffer gets
full
On 4/22/2019 1:45 AM, Jan Kiszka wrote:
On 22.04.19 08:40, C Smith via Xenomai wrote:
Thanks for your insight, Steve. I didn't realize rt_dev_write() doesnt
actually stall until it is called many times and the 4K TX buffer gets
full. (is that right Jan?)
It that is the case, sure I could find a
On 4/20/2019 11:33 PM, C Smith via Xenomai wrote:
Per your suggestion, I added code to call this ioctl, right after the
rt_dev_write() :
rt_dev_ioctl(fd_tty[1], RTSER_RTIOC_GET_STATUS, _status);
I let the transmit stall again, then attached with a gdb, which allows me
to step forward to the
On 2/25/2019 11:15 AM, Jan Kiszka wrote:
On 25.02.19 17:53, Steve Freyder via Xenomai wrote:
Greetings again,
Recently I have converted my codebase from using Alchemy-based queues
(rt_queue_xx) to Cobalt (Posix) mqueues for all inter-process
communication, and using rt_queue queues only
Greetings again,
Recently I have converted my codebase from using Alchemy-based queues
(rt_queue_xx) to Cobalt (Posix) mqueues for all inter-process
communication, and using rt_queue queues only for communication between
threads in the same process.
This is running on Xenomai 3.0.7 built
On 2/12/2019 11:53 AM, Wolfgang Grandegger via Xenomai wrote:
Am 12.02.19 um 18:24 schrieb Johannes Holtz:
Am 12.02.19 um 18:05 schrieb Wolfgang Grandegger:
Am 12.02.19 um 16:19 schrieb Johannes Holtz:
Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger:
Hello Johannes,
Am 12.02.19 um 15:38
28 matches
Mail list logo
