's other comments, this all only works if the PCI
probe gets things in the same order, but it seems to be consistent on
my system.
-C Smith
On Wed, May 25, 2022 at 10:50 PM Richard Weinberger
wrote:
>
> On Thu, May 26, 2022 at 2:08 AM C Smith wrote:
> >
> > On Wed, May 25, 2022 at 1:07 AM Richard Weinberger
> > wrote:
> > >
> > > On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai
>
On Wed, May 25, 2022 at 1:07 AM Richard Weinberger
wrote:
>
> On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai
> wrote:
> > We are using Xenomai 3.1.2 on kernel 4.19.229, X86 CPU
> > We have a (Moxa CP-104ul) serial card on an isolated PCI bus interrupt 17.
We are using Xenomai 3.1.2 on kernel 4.19.229, X86 CPU
We have a (Moxa CP-104ul) serial card on an isolated PCI bus interrupt 17.
lspci -v confirms that the serial card is isolated and that no other
peripheral uses this interrupt.
We have the 16550A serial driver loaded, and an external serial
On Mon, May 9, 2022 at 7:52 AM Jan Kiszka wrote:
> On 06.05.22 19:32, C Smith via Xenomai wrote:
> > I have three serial devices connected using 16550A.ko driver. The card
> > is a Moxa PCI 4-port card, where all ports share IRQ 18.
> > Several times per minute in dmesg
e free\n",
__FUNCTION__, irq);
Does this message mean serial data can be corrupted, or is it harmless?
Is there something I can test for you on my system?
I'm using Xenomai 3.1.2, ipipe kernel 4.19.229, X86-64.
thanks. -C Smith
On Wed, May 4, 2022 at 11:31 PM Richard Weinberger
wrote:
>
> On Thu, May 5, 2022 at 7:47 AM C Smith via Xenomai
> wrote:
> >
> > In my serial_config which I pass to the ioctl() that sets up my
> > 16550A.ko serial port
> > I have set .rx_timeout = 5
immediately if there is no data in
the device ?
Must I use an ioctl with RTSER_RTIOC_GET_STATUS to inspect the UART
LSR for data available?
(This is a RT userspace app on Xeno 3.1.2, kernel 4.19.229, intel I5,
16550 compat UART)
thanks, -C Smith
On Sun, May 1, 2022 at 11:25 PM Jan Kiszka wrote:
>
> On 29.04.22 21:01, Richard Weinberger via Xenomai wrote:
> > On Fri, Apr 29, 2022 at 9:04 AM C Smith via Xenomai
> > wrote:
> >> int Lp_port_handler(rtdm_irq_t *irq_handle_p)
> >> {
> >>
r routine is incorrect API or "illicit"?
thanks,
-C Smith
On Sun, Jan 9, 2022 at 8:49 AM Philippe Gerum wrote:
>
>
> C Smith writes:
>
> > On Mon, Jan 3, 2022 at 11:44 PM C Smith wrote:
> >>
> >> On Mon, Jan 3, 2022 at 11:05 PM Jan Kiszka wrote:
> >> >
> >> > On 03.01.22 22:12, C Smit
On Mon, Jan 3, 2022 at 11:44 PM C Smith wrote:
>
> On Mon, Jan 3, 2022 at 11:05 PM Jan Kiszka wrote:
> >
> > On 03.01.22 22:12, C Smith wrote:
> > > On Sun, Jan 2, 2022 at 11:38 PM Jan Kiszka wrote:
> > >>
> > >> On 03.01.22 08:29, C Smi
On Mon, Jan 3, 2022 at 11:05 PM Jan Kiszka wrote:
>
> On 03.01.22 22:12, C Smith wrote:
> > On Sun, Jan 2, 2022 at 11:38 PM Jan Kiszka wrote:
> >>
> >> On 03.01.22 08:29, C Smith wrote:
> >>> I have been getting kernel Oopses with x86 Xenomai 3.1 (an
On Sun, Jan 2, 2022 at 11:38 PM Jan Kiszka wrote:
>
> On 03.01.22 08:29, C Smith wrote:
> > I have been getting kernel Oopses with x86 Xenomai 3.1 (and 3.2.1).
> > In numerous tests, I can't keep a computer running for more than a day
> > before the computer hard-
(k4.19.89)?
Thanks. -C Smith
-- next part --
A non-text attachment was scrubbed...
Name: config_4.19.89-20211206
Type: application/octet-stream
Size: 190113 bytes
Desc: not available
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20220102/c6ee52df/attachment.obj>
There are development scenarios where different versions of a driver
are substituted. I can tell you some long stories when one day we meet
over a few beers...
-C Smith
that the successor itself becomes
stable during that period. The most reliable place to develop is on a
stable branch, getting bugfixes. That is crucial to the success of
development, a product using Xenomai, and its users.
-C Smith
On Wed, Dec 15, 2021 at 2:48 AM Jan Kiszka via Xenomai
wrote
().
Is there a way of accessing the RTDM timer and getting a timestamp
from within my realtime userspace app which would match the serial
driver's timestamp?
thanks, -C Smith
PS: I'll respond about the CAN patch and a few other things in other threads.
and their ability to access the Cobalt posix
wrappers? The problem is that I need to step over
read()/write()/ioctl() while in gdb. Is there any way to do so ?
thanks, -C Smith
/trank/native/queue.h:21,
from /home/csmith/src/my_app.c:16:
/usr/lib/gcc/x86_64-redhat-linux/8/include/stdint.h:9:26: error: no
include path in which to search for stdint.h
# include_next
thanks, -C Smith
OK that makes sense.
thanks, -C Smith
On Thu, Nov 11, 2021 at 12:27 AM Jan Kiszka wrote:
>
> On 11.11.21 08:33, C Smith via Xenomai wrote:
> > I can compile a rtdm kernel module OK with Xenomai 3.1 but I can't
> > seem to get my module to see errno.
> >
> > In sev
pps)
What is the proper way to access errno?
thanks, -C Smith
Signed-off-by: C Smith
---
kernel/drivers/can/rtcan_internal.h | 1 +
kernel/drivers/can/rtcan_raw.c | 102 +++-
2 files changed, 67 insertions(+), 36 deletions(-)
diff --git a/kernel/drivers/can/rtcan_internal.h
b/kernel/drivers/can/rtcan_internal.h
for rtcan
Signed-off-by: C Smith
---
kernel/drivers/can/rtcan_internal.h | 1 +
kernel/drivers/can/rtcan_raw.c | 102 +++-
2 files changed, 67 insertions(+), 36 deletions(-)
diff --git a/kernel/drivers/can/rtcan_internal.h
b/kernel/drivers/can/rtcan_internal.h
index
the xddp sockets code was emulated to get the CAN receive to work.
Signed-off-by: C Smith
---
kernel/drivers/can/rtcan_internal.h | 3 +
kernel/drivers/can/rtcan_raw.c | 111
2 files changed, 76 insertions(+), 38 deletions(-)
diff --git a/kernel/drivers/can
27177.480994] rtcan_raw.c, 428: setaddr->addrlen: -6084360
Do you have any idea why addrlen is corrupt ?
Thanks, -C Smith
On Wed, Nov 3, 2021 at 4:09 AM Bezdeka, Florian
wrote:
> On Wed, 2021-11-03 at 11:46 +0100, Jan Kiszka via Xenomai wrote:
> > On 03.11.21 07:59, Jan Kiszka wrote:
g Xenomai 3.1, with kernel 4.19.989 x86_64
-C Smith
On Tue, Nov 2, 2021 at 12:11 PM Jan Kiszka wrote:
> On 02.11.21 19:57, C Smith via Xenomai wrote:
> > I ran into a problem wherein my real-time Xenomai 32-bit app
> > fails on the socket operations of the 64-bit CAN driver.
> >
for 32-bit when I built it:
./configure --host=i686-linux CFLAGS="-m32 -D_FILE_OFFSET_BITS=64"
LDFLAGS=-m32 host_alias=i686-linux
But note that if I compile both Xenomai and rtcansend.c 64-bit, everything
works fine.
So how can 32-bit Xeno apps use the 64-bit CAN driver ?
thanks,
-C Smith
OK thanks. I am attaching a proposed patch for the docs. I've tried to use
the syntax of the Linux Device Drivers book.
I will soon submit a more complete pair of test apps for using mmap(),
which I assume would end up in xenomai-3.x/demo/cobalt/.
thanks,
-C Smith
On Thu, Oct 21, 2021 at 8:23 AM
() does the job then why does rtdm_mmap_to_user()
exist?
thanks, -C Smith
d.
Can you tell me why the headers above seem to conflict?
thanks -C Smith
On Wed, Oct 6, 2021 at 3:25 AM Jan Kiszka wrote:
> On 06.10.21 09:40, C Smith via Xenomai wrote:
> > I have a legacy RTDM driver I am trying to port from Xenomai 2.6 to 3.1.
> I
> > am attempting
/usr/xenomai/include -D__XENO_COMPAT__ -DMODULE
-DKBUILD_BASENAME='"myapp"' -DKBUILD_MODNAME='"myapp"' -c -o
/home/csmith/src/app3-prog/modules/myapp.o
/home/csmith/src/app3-prog/modules/myapp.c
How can I compile with the "trank" to get native/timer.h and
rt_timer_read() ?
thanks, -C Smith
but not in Xenomai 3.1.
All I needed was
LDLIBS= $(shell $(XENOCONFIG) --skin=alchemy --ldflags)
My larger (30K lines) app compiles successfully now.
Thanks. -C Smith
On Wed, Aug 11, 2021 at 11:04 PM Jan Kiszka wrote:
> On 12.08.21 07:50, C Smith wrote:
> > Hi Jan,Thanks for your prompt reply. I r
enomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld
-L/usr/xenomai/lib -lcobalt -lmodechk -lpthread -lrt -m32 -lfuse -pthread
-lxml2 -lz -llzma -lm
-ldl -L"SOEM/lib/linux" -Wl,--start-group -loshw -losal -lsoem
-Wl,--end-group -lm -o myapp
Wh
pers
/usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt
-lmodechk -lpthread -lrt-lfuse -pthread -lz -llzma -lm -ldl
-Wl,--start-group -loshw -losal -Wl,--end-group -lm -o testapp
thanks,
-C Smith
Hi,
I'm having a problem compiling Kernel 4.19.109 with
ipipe-core-4.19.109-cip22-x86-11.patch using Xenomai-3.1.
$ scripts/prepare-kernel.sh --linux=../linux/
--ipipe=../ipipe-core-4.19.109-cip22-x86-11.patch --arch=x86
I'm compiling with:
$ m -j4 bzImage
I'm getting following error:
On Thu, Apr 25, 2019 at 1:23 AM Jan Kiszka wrote:
> On 25.04.19 09:15, C Smith wrote:
> > Hi Jan,
> >
> > Your patch worked somewhat but not completely. It prevents my app from
> stalling
> > forever, but I caugh the serial transmission itself stalling on the
>
Hi Jan,
Your patch worked somewhat but not completely. It prevents my app from
stalling forever, but I caugh the serial transmission itself stalling on
the oscilloscope for quite a long time. My 72 byte TX packet from the
xenomai periodic task gets cut in half and there is no transmission for
seems to confirm that the UART is still functioning OK at the hardware
level during the problem, it just needs to be "reminded" to transmit. Your
patch may be all it needs...
-C Smith
test app.
-C Smith
to fire reliably. So I think I must rewrite that
interrupt handler, as above.
-C Smith
the
bytes in the buffer, and force transmission until the buffer is empty?
thanks,
-C Smith
ying I need to do an ioctl RTSER_RTIOC_SET_CONTROL and clear
control bit *RTSER_MCR_RTS* ?
I have another Xenomai app which has been running fine as a 3-wire serial
connection for about 4 years,
and it does not do an ioctl RTSER_RTIOC_SET_CONFIG either. Doesn't that
mean setting flow control is unnecessary?
-C Smith
e is a bit beyond my understanding).
I'd like to detect the problem early and continue without stalling.
It seems the physical serial ports are misbehaving, sure. But what would
make rt_dev_write() stall forever?
thanks,
C Smith
late and the human viewer doesn't care). We've done this
architecture for years, on uniprocessor systems, it works well.
- C Smith
On Sun, Mar 3, 2019 at 11:56 PM Stéphane Ancelot via Xenomai <
xenomai@xenomai.org> wrote:
> Hi,
>
> I will share some points from my viewpoint :
On Wed, Feb 27, 2019 at 11:30 PM Philippe Gerum wrote:
> On 2/28/19 6:56 AM, C Smith via Xenomai wrote:
> > On Mon, Feb 25, 2019 at 12:09 AM Jan Kiszka
> wrote:
> >
> >> On 24.02.19 07:57, C Smith via Xenomai wrote:
> >>> I am using Xenomai 2.6.5, x
here. My apologies if it gets inlined.
This config came from a working xenomai 2.6.5, 3.18.20 kernel.
thanks,
-C Smith
-- next part --
A non-text attachment was scrubbed...
Name: config_ipipe_20190228
Type: application/octet-stream
Size: 148057 bytes
Desc: not available
URL
On Mon, Feb 25, 2019 at 12:09 AM Jan Kiszka wrote:
> On 24.02.19 07:57, C Smith via Xenomai wrote:
> > I am using Xenomai 2.6.5, x86 32bit SMP kernel 3.18.20, Intel Core
> > i5-4460, and I have found a periodic timing problem on one particular
> type
> > of motherboard.
() to determine what time it is, and my periodic task
sleeps in a while loop, like this:
next += period_ns + adjust_ns;
rt_task_sleep_until(next);
I don't know what to test. Can you suggest anything?
Thanks,
-C Smith
explains, by disabling CONFIG_SMAP in the kernel config. I am on
kernel 3.18.20 and in order to reveal that setting in 'make menuconfig' in
the processor features - you'll need to first enable 'kernel debugging' and
also choose 'Embedded' as well.
-C Smith
On Thu, Sep 29, 2016 at 3:49 AM Henning Schild
On Sun, Nov 18, 2018 at 11:39 PM Jan Kiszka wrote:
> On 19.11.18 07:38, C Smith via Xenomai wrote:
> > I am porting an old Linux kernelspace driver to Xenomai 2.6.5 using RTDM
> > API.
> > I see calls to spinlock_irq_save() and spin_unlock_irqrestore() in the
> old
>
,
and execute in Primary mode? Is calling these a bad thing to do in the
middle of an RTDM interrupt, will it try to switch to Secondary mode ?
thanks,
C Smith
userspace RT app to switch to secondary mode. I'll let you know if it
doesn't work.
-C Smith
On Wed, Jun 13, 2018 at 12:00 PM, Greg Gallagher
wrote:
> If you are looking at creating your own RTDM driver you just need a
> basic driver that has open, read, write, close. There would be
I'd like my Xenomai task to write to both stdout and also to the kernel's
dmesg buffer.
It is a periodic task started with rt_task_create().
When I do rt_vfprintf(stdout, ...)
it prints to stdout OK, but I also want to send the same string to the
dmesg buffer, and
I can't call printk() or
successfully.
So sharing IRQ5 is not working, and there is no way in the BIOS for these
ports to share another interrupt.
-C Smith
PS: Sorry Gmail was hiding your messages so I couldn't Reply to them.
On Mon, May 28, 2018 at 11:39 PM, Jan Kiszka wrote:
> On 2018-05-28 19:21, C Smith wr
Jan wrote:
>Platform UART IRQs are assumed to be edge-triggered (see irqtype
>variable) - maybe your special board is different in this regard as
>well. Try removing RTDM_IRQTYPE_EDGE.
I couldn't find a kernel option called RTDM_IRQTYPE_EDGE, either with 'make
menuconfig' or by grepping the
o work, only one byte can be transmitted or received.
On this same motherboard, a Moxa PCI card can share IRQ17 between 4 ports
OK using xeno_16550A, demonstrating that the kernel/modules are compiled
correctly.
But there seems to be a problem with sharing IRQ
ndler which is already doing an EOI?
Remember lower interrupts like IRQ 5 work fine with the xeno_16550A driver
unless another port is sharing the same IRQ.
-C Smith
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
.
-C Smith
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
in sequence, indicating that my kernel and xeno_16550A module are
compiled correctly for shared interrupts. I'll try simultaneous use of
these ports tomorrow.
The previous problem must have been the actual serial ports I was using,
which are the ones provided by the motherboard.
thanks,
-C Smith
only once.
thanks,
-C Smith
-- next part --
A non-text attachment was scrubbed...
Name: xeno_shirq-help.patch
Type: text/x-patch
Size: 656 bytes
Desc: not available
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20180521/07c8b213/attachment.
eturn -EBUSY if request_region() or mapped_io[] indicate failure, but
nothing printed to dmesg when rt_dev_open() failed.
How else can I analyze why rt_dev_open() thinks a port is unavailable?
thanks,
-C Smith
___
Xenomai mailing list
Xenomai@xenomai.o
The xeno_16550A driver works on my system but I can't get it to use more
than two ports at a time.
'dmesg' after the kernel boots shows this:
[0.538264] 00:05: ttyS1 at I/O 0x2f8 (irq = 5, base_baud = 115200) is a
16550A
[0.559280] 00:06: ttyS3 at I/O 0x2e8 (irq = 5, base_baud = 115200)
ow you are sharing them and then we can see
> if something would cause mode switches. Are you seeing both threads
> drop to secondary mode?
>
> -Greg
>
> On Fri, Apr 6, 2018 at 1:01 PM, C Smith <csmithquesti...@gmail.com> wrote:
> > The tasks manipulate shared
> Do the tasks communicate with each other?
>
> -Greg
>
> On Fri, Apr 6, 2018 at 12:51 PM, C Smith <csmithquesti...@gmail.com>
> wrote:
> > Hi all--
> >
> > Our real time application has a main rt_task which runs concurrently with
> > severa
Hi all--
Our real time application has a main rt_task which runs concurrently with
several other rt_tasks (spawned using rt_task_create) and we are concerned
about a context switch in one of the tasks. The problematic task uses
libxml2 to parse an xml document sent over ethernet which seems to
-
-while (buffers == 0)
-pthread_cond_wait(_wakeup, _lock);
+
+if ((buffer_lock.__data.__lock != 0) &&
(printer_wakeup.__data.__mutex != 0))
+while (buffers == 0)
+pthread_cond_wait(_wakeup, _lock);
print_buffers();
Can you verify that
6 = (pthread_mutex_t *) 0xb76fd9fc
I see now that all variables used in this function are static on the heap,
and thus they are not null pointers, so what could cause a segfault?
Thanks, -C Smith
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
-Wl,@/usr/xenomai/lib/posix.wrappers
-L/usr/xenomai/lib -lpthread_rt -lxenomai -lpthread -lrt -lxml2 -lz -lm
-L"SOEM/lib/linux" -Wl,--start-group -loshw -losal -lsoem
-Wl,--end-group -lm -o app
Thanks, -C. Smith
Original post:
My xenomai application is segfaulting at startup, 1 in 10 ti
My xenomai application is segfaulting at startup, 1 in 10 times I run it.
When I catch it in a debugger or get a core file it says the segfault was
not in my code but in the xenomai sources:
rt_print.c line 685:
pthread_cond_wait(_wakeup, _lock);
(gdb) bt
#O Oxb77120db in
Hi all --
Thanks to your help, I am now using XDDP sockets for communication between
non-RT processes and a single RT process. It is generally working -- I
start the RT task first, and it opens several sockets. It starts doing
non-blocking reads and writes, and since no process is on the other
Thanks -- I'm all for using the most-well-traveled path -- do you mean the
message queue API?
Bob
P.S. I'll be on vacation for a week
On Wed, Aug 16, 2017 at 6:19 AM, Philippe Gerum <r...@xenomai.org> wrote:
> On 08/16/2017 02:14 AM, C Smith wrote:
> > Oops, I ac
running on a not-too powerful system (quad-core Intel Atom
2 GHz) though I wouldn't think it out of the ordinary for embedded.
Bob
On Tue, Aug 15, 2017 at 5:14 PM, C Smith <csmithquesti...@gmail.com> wrote:
> Oops, I accidentally sent this to Philippe instead of the list --
>
>
> -
Hi all --
We have an architecture with 1 realtime task, and several non-realtime
processes (other programs) that communicate with the realtime task over
FIFOs. We have used RTLinux in the past, and are porting to Xenomai. I've
had to do some voodoo to get the FIFOs working, and I wonder if this
Hi all --
I am using the realtime-realtime IPC mechanism with
socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_IDDP)
I have a server process that opens a socket and periodically checks if
anything came in from a client (a separate process on the same machine),
which may or may not be running. If a client
associated with the socket in some way?
Any help or reference to further documentation would be helpful. I know
Xenomai 2 is deprecated, but I have mature, well tested application written
with Xenomai 2.6.4, and don't have time to change it over to Xenomai 3.
Thanks,
C. Smith
behavior and benefits of O_SYNC:
http://man7.org/linux/man-pages/man2/open.2.html
Thanks, Philippe.
On Tue, Jul 21, 2015 at 1:26 AM, Philippe Gerum r...@xenomai.org wrote:
On 07/20/2015 11:31 PM, C Smith wrote:
I found a workaround for this, but I believe it illustrates a bug in
xenomai
to the rt_pipe ?
(Perhaps by checking /proc/xenomai?)
On Thu, Jul 2, 2015 at 4:14 PM, C Smith csmithquesti...@gmail.com wrote:
I have installed Xenomai 3.0rc5 and compiled my test applications (with
minor revisions for the new API).
I modprobed the xeno_rtipc module for this, and my apps run. But I am
-L/usr/xenomai/lib -lcobalt
-lpthread -lrt -lalchemy -lcopperplate -Wl,--wrap=main
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt
-lpthread -lrt-o pipe-read
I have attached the latest 'write' and 'read' test apps here.
Please help. Thanks,
-C Smith
On Wed, Jul 1
I am developing a set of applications which write to and read from a
rt_pipe. The writing app is in plain linux userspace, the reading app is a
periodic Xenomai task. I am using xenomai 2.6.3 on kernel 3.4.6 (32 bit).
The problem I have is that the Xenomai task gets this warning when it tries
to
80 matches
Mail list logo
