I can confirm that this is not fixed in Xenomai 2.6.5. (I too am on that
branch because of legacy code). I found that certain I5 processors generate
the memory exception during cpy_from_user() calls, and certain I5
processors don't. I successfully worked around the problem, as Henning
Schild
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
kernel driver code, right in the middle of an interrupt handler.
Are those spinlock calls 'wrapped' by Xenomai 2.6.5 such that they work,
and
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
>
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.
I have a Xenomai RT periodic task which outputs a pulse to the PC parallel
port, and this pulse is measured on a frequency counter. This
QT will allocate/destruct memory and its overhead and timing are
unpredictable because of its signal/slot architecture - don't try to run QT
in RT space.
Instead, run your QT (C++,etc) application in userspace. Have your QT
application attach to a static shared memory segment which a xenomai RT
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
I am unable to compile a xenomai-patched kernel. I get this message:
warning: (XENOMAI) selects IPIPE which has unmet direct dependencies
(HAVE_IPIPE_SUPPORT)
kernel sources from kernel.org: 4.14.89
with ipipe-core-4.14.89-x86-2.patch applied
gcc version 4.9.2 20150212
I have attached my .config
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.
My Xenomai periodic routine normally runs for days at a time on most
motherboards, but it is spontaneously getting stuck forever in
rt_dev_write(). This is a write to a xeno_16550A driver serial port.
I must use this brand of motherboard, where the first serial port (rtser0
0x3f8 irq 4) does not
On Tue, Apr 16, 2019 at 1:03 AM Jan Kiszka wrote:
> > The serial device is set up this way:
> > struct rtser_config serial_config = {
> > .config_mask = 0x,
> > .baud_rate = 115200,
> > .parity= RTSER_NO_PARITY,
> > .data_bits
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 ioctl:
serial_status.line_status was 96 decimal,
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 : cross-link.c behaves very
regularly in
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 way to check the TX buffer fill
level to prevent my app from stalling.
I rewrote 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
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
> oscilloscope
> > for quite a long
Thanks very much Jan, I'll try your patch tomorrow.
In the meantime it may confirm your suspicions to hear this :
I hacked the xeno_16550A.c driver to poll the transmit buffer every time
there was an RX interrupt (I have a bidirectional application). If there
was any data waiting just call the TX
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:
I can compile but not link my xenomai app. I get:
/usr/bin/ld: skipping incompatible /usr/xenomai/lib/libtrank.so when
searching for -ltrank
/usr/bin/ld: skipping incompatible /usr/xenomai/lib/libcobalt.so when
searching for -lcobalt
etc.
I am testing xenomai 3.1 with x86-64 bit kernel 4.19.89
at is going wrong with the linkage? Thanks, C Smith
On Sat, Aug 7, 2021 at 8:34 AM Jan Kiszka wrote:
> On 07.08.21 09:43, C Smith via Xenomai wrote:
> > I can compile but not link my xenomai app. I get:
> > /usr/bin/ld: skipping incompatible /usr/xenomai/lib/libtrank.so when
> &
OK, yeah I had mistakenly put --ldflags in the xeno-config line for CFLAGS
=
This was also problem:
LDLIBS= $(shell $(XENOCONFIG) --skin=native --ldflags) \
$(shell $(XENOCONFIG) --skin=rtdm --ldflags) \
$(shell $(XENOCONFIG) --skin=posix --ldflags)
That used to work in Xenomai 2.6 but not in
I recently got a Xenomai 3.1 shared memory .mmap op to work but I don't see
any mmap examples in the Xemomai documentation (please publish one). I have
a question as to why I had to do it a certain way. Here is the
(abbreviated) code I used:
typedef struct { // shared struct
int
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
I have a legacy RTDM driver I am trying to port from Xenomai 2.6 to 3.1. I
am attempting to include the /usr/xenomai/include/trank headers. My app
uses some Alchemy API as well as RTDM API. In particular, rt_timer_read()
seems to require Alchemy. But when my code does
#include
I get this compiler
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
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-locks (no kbd/mouse/ping). Frequently the
kernel Oopses within 4-6 hours. I have tried 2 identical motherboards,
changed RAM, and
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-locks (no kbd/mouse/ping).
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 (and 3.2.1).
> >>> In numerous tests, I can't
Can I call rt_queue_create() and rt_queue_read() from an rtdm kernel module ?
This used to work OK in Xenomai 2 but now in Xeno3.1 when I attempt to
#include in my rtdm code I get this error:
In file included from /usr/xenomai/include/alchemy/queue.h:21,
from
I am debugging a Cobalt userspace real time app (using posix/alchemy
skins) on Xenomai 3.1, X86 platform. I have a problem with my process
blocking when I am single-stepping in gdb (although the process does
not block when it is run full speed). This happens with ioctl(),
write() or read() of a
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 several Xenomai example sources I see :
#include
but when I put that in my rtdm code I must also add to my Makefile:
-I/usr/src/linux/. Is that the right include path?
Even once I do all
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
I ran into a problem wherein my real-time Xenomai 32-bit app
fails on the socket operations of the 64-bit CAN driver.
My real-time userspace app is Cobalt x86, compiled -m32.
When I try the Xenomai rtcansend.c sample app compiled 32-bit, I get the
same error :
[root@pc can]#
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.
> >
Jan Kiszka wrote:
> On 20.10.21 07:49, C Smith via Xenomai wrote:
> > I recently got a Xenomai 3.1 shared memory .mmap op to work but I don't
> see
> > any mmap examples in the Xemomai documentation (please publish one). I
> have
> > a question as to why I had t
Please review and accept this patch, which allows 32 bit apps to send and
receive CAN. It is tested successfully with 32bit and 64bit compiles of
utils/can/rtcansend.c / and rtcanrecv.c. The compat interface is now
implemented, rtdm_get_iovec() is used and the get_sockaddr() methodology
from the
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
Here's an updated patch addressing mentioned issues.
I've noticed ipc/internal.h re-defines COMPAT_CASE(__op) as well.
I don't know what gmail is doing to the inline text (this should be
plain text) so I've also attached a .gz version of the patch.
Subject: [PATCH] 32-bit userspace app support
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:
I'm porting a real time userspace (Cobalt) app from Xenomai 2.6 to
Xeno 3.1 (on x86). The goal is to see how much time has passed since
the last char was received from the 16550A serial driver.
In Xenomai 2, my RT userspace app was able via ioctl to read the
timestamp the 16550A serial driver
It is very important to our project that 3.1 be maintained, as we are
still in the stage of testing our porting effort from 2.6 to 3.1.
Thank you for 3.1! Ideally a stable branch like 3.1 should get
bugfixes (but no new features) for at least the first year of its
successor (3.2) so as to insure
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 Smith wrote:
> > >>> I have been getting kernel Oopses with
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 Smith wrote:
> >> > > On Sun, Jan 2, 2022 at 11:38 PM Jan Kiszka
> >>
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 Fri, May 27, 2022 at 1:34 AM Richard Weinberger wrote:
> - Ursprüngliche Mail -
> > An update:
> > If the 16550A driver is modprobed with no arguments, it apparently
> > probes the PCI subsystem, gets the irq, and interrupts are enabled OK.
> > The serial port can send/receive data.
>
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
>
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 I get :
[Xenomai] xnintr_edge_vec_handler: failed to get the IRQ18 line free
Yet I don't think I am losing any serial packet data (I
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
In my serial_config which I pass to the ioctl() that sets up my
16550A.ko serial port
I have set .rx_timeout = 50
and I am doing non-blocking reads.
This indeed results in a 500us delay when reading a serial port with
no incoming bytes, which I can measure precisely on an oscilloscope (I
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
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)
> >> {
> >>
I am unable to handle interrupts in my RTDM module with Xenomai 3.1,
ipipe kernel 4.19.229.
The interrupt handler code below was ported from Xenomai 2.6 where the
approach worked OK.
This is how I enable the parallel port interrupt in my module:
#define LPPORT 0x378
#define
52 matches
Mail list logo
