Re: 16550A IRQ not enabled

[C Smith via Xenomai]

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.
> > But, if a port= or irq= argument is passed into the 16550A driver,
> > then the driver seems to skip probing the PCI syubsystem, and the
> > driver fails to enable the irq. No data can transmitted or received by
> > the port, even though the driver has done an  rtdm_irq_request() of
> > the correct irq level.
> >
> > This is a problem for my application because I have 6 serial ports and
> > some must have different baud_base args, which is now impossible with
> > this inconsistent driver behavior.
>
> And just passing baud_base=X,Y,..,Z does not work?
> Sure this is still hacky since it depends on the PCI probe order...
>
> We could make baud_base configurable via ioctl, the driver supports already
> plenty of them.
> Or exposing this and other properties as sysfs attributes.
>
> Further I suggest splitting the driver in at at least two kernel modules.
> One for PCI and another one for legacy PIO/PNP.
> The current probe interface is IMHO confusing and error prone.
>
> Thanks,
> //richard

After a 16550A_pci.h driver modification, I got this all to work
finally, with interrupts enabled for all of my 6 serial ports. This is
the modprobe command line:
modprobe xeno_16550A io=0x3f8,0x2f8 irq=4,3
baud_base=115200,115200,460800,460800,460800,460800
Note that those first two ports above are are legacy (ISA) addresses,
not PCI cards. The last four baud_base args above are for the four
ports on the Moxa PCI card. By not specifying an io=,irq= for the PCI
ports we let the driver do a pci_resource_start() and the interrupts
are automagically enabled.

Here is the code I had to hack to get this to work.
static int rt_16550_pci_probe()
...
for (i = 0; i < MAX_DEVICES; i++) {
...
baud_base[i] = board->baud_base;

That last line was clobbering baud_base[] with defaults, even if I put
a new baud_base on the modprobe command line. With that last line
commented out the modprobe baud_base arguments succeed.

But per Richard W'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

Re: 16550A IRQ not enabled

[C Smith via Xenomai]

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  
> > > 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.
> > > > 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 device
> > > > trying to initiate a serial connection, but no interrupts are being
> > > > generated. The interrupt counter in /proc/xenomai/irq stay at 0.
> > > >
> > > > [user@device~]$ cat /proc/xenomai/irq
> > > >   IRQ CPU0CPU1CPU2CPU3
> > > >17:   0   0   0   0 rtser2
> > > > rtser3 rtser4 rtser5
> > > >
> > > > As an experiment: if we enable the Azalia sound chip in the BIOS, and
> > > > load its Alsa sound driver, the Serial card will then share IRQ 17
> > > > with that sound chip, and then the serial card works. The serial
> > > > interrupt counter is incrementing in /proc/xenomai/irq and our serial
> > > > peripheral can utilize the serial port OK.
> > >
> > > I think enabling it in the BIOS is the key. Can you try keeping the sound 
> > > driver
> > > disabled and only enable in the BIOS.
> >
> > We left the Azalia sound chip enabled in the BIOS, and disabled the
> > sound driver.
> > Interrupts in /proc/xenomai/irq are still not incrementing when serial
> > packets come into the po
> >
> > > > We don't want the sound driver enabled, but this test indicates that
> > > > 16550A somehow failed to enable its interrupt, whereas the sound
> > > > driver succeeded in doing so.
> > > >
> > > > How can we check a PIC, etc. to verify that the serial interrupt is
> > > > truly enabled when the 16550A driver is loaded alone?
> > >
> > > You can enable CONFIG_GENERIC_IRQ_DEBUGFS and then poke into
> > > /sys/kernel/debug/irq/.
> > >
> > > --
> > > Thanks,
> > > //richard
> >
> > We rebuilt our kernel with CONFIG_GENERIC_IRQ_DEBUGFS enabled, booted
> > with the sound driver disabled and loaded xeno_16550A:
> >
> > [root@device~]# cat /sys/kernel/debug/irq/irqs/17
> > cat: /sys/kernel/debug/irq/irqs/17: No such file or directory.
> >
> > We noticed that /proc/xenomai/irq is not showing IRQ17 immediately
> > after xeno_16550A is loaded.
> > proc/xenomai/irq only shows IRQ17 after the serial device is opened
> > for the first time.
>
> The driver requests the IRQ only upon open. So that's okay.
>
> > So /sys/kernel/debug/irq/irqs/17 doesn't become available until the
> > sound driver is loaded.
>
> ...or until you use the xeno_16550A driver by opening the device handle?
>
> > We also have a (Peak) CAN card installed in this system, and the
> > corresponding IRQ shows up immediately in
> > /sys/kernel/debug/irq/irqs/18
> > after the xeno_can driver is loaded.
> >
> > Should we expect to see the IRQ show up in /proc/xenomai/irq
> > immediately after loading the xeno_16550A driver?
>
> No. It depends how the driver works. As I wrote, xeno_16550A does
> rtdm_irq_request()
> in the open, not the probe function.
>
> > How can we debug this further, since /sys/kernel/debug/irq/irqs/17
> > does not exist without that sound driver?
>
> I don't really understand, didn't you write a few lines above that the
> IRQ shows also up
> when you open the device? Why do you need the IRQ earlier?
> --
> Thanks,
> //richard

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.
But, if a port= or irq= argument is passed into the 16550A driver,
then the driver seems to skip probing the PCI syubsystem, and the
driver fails to enable the irq. No data can transmitted or received by
the port, even though the driver has done an  rtdm_irq_request() of
the correct irq level.

This is a problem for my application because I have 6 serial ports and
some must have different baud_base args, which is now impossible with
this inconsistent driver behavior.

-C Smith

Re: 16550A IRQ not enabled

[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.
> > 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 device
> > trying to initiate a serial connection, but no interrupts are being
> > generated. The interrupt counter in /proc/xenomai/irq stay at 0.
> >
> > [user@device~]$ cat /proc/xenomai/irq
> >   IRQ CPU0CPU1CPU2CPU3
> >17:   0   0   0   0 rtser2
> > rtser3 rtser4 rtser5
> >
> > As an experiment: if we enable the Azalia sound chip in the BIOS, and
> > load its Alsa sound driver, the Serial card will then share IRQ 17
> > with that sound chip, and then the serial card works. The serial
> > interrupt counter is incrementing in /proc/xenomai/irq and our serial
> > peripheral can utilize the serial port OK.
>
> I think enabling it in the BIOS is the key. Can you try keeping the sound 
> driver
> disabled and only enable in the BIOS.

We left the Azalia sound chip enabled in the BIOS, and disabled the
sound driver.
Interrupts in /proc/xenomai/irq are still not incrementing when serial
packets come into the po

> > We don't want the sound driver enabled, but this test indicates that
> > 16550A somehow failed to enable its interrupt, whereas the sound
> > driver succeeded in doing so.
> >
> > How can we check a PIC, etc. to verify that the serial interrupt is
> > truly enabled when the 16550A driver is loaded alone?
>
> You can enable CONFIG_GENERIC_IRQ_DEBUGFS and then poke into
> /sys/kernel/debug/irq/.
>
> --
> Thanks,
> //richard

We rebuilt our kernel with CONFIG_GENERIC_IRQ_DEBUGFS enabled, booted
with the sound driver disabled and loaded xeno_16550A:

[root@device~]# cat /sys/kernel/debug/irq/irqs/17
cat: /sys/kernel/debug/irq/irqs/17: No such file or directory.

We noticed that /proc/xenomai/irq is not showing IRQ17 immediately
after xeno_16550A is loaded.
proc/xenomai/irq only shows IRQ17 after the serial device is opened
for the first time.
So /sys/kernel/debug/irq/irqs/17 doesn't become available until the
sound driver is loaded.

We also have a (Peak) CAN card installed in this system, and the
corresponding IRQ shows up immediately in
/sys/kernel/debug/irq/irqs/18
after the xeno_can driver is loaded.

Should we expect to see the IRQ show up in /proc/xenomai/irq
immediately after loading the xeno_16550A driver?

How can we debug this further, since /sys/kernel/debug/irq/irqs/17
does not exist without that sound driver?

16550A IRQ not enabled

[C Smith via Xenomai]

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 device
trying to initiate a serial connection, but no interrupts are being
generated. The interrupt counter in /proc/xenomai/irq stay at 0.

[user@device~]$ cat /proc/xenomai/irq
  IRQ CPU0CPU1CPU2CPU3
   17:   0   0   0   0 rtser2
rtser3 rtser4 rtser5

As an experiment: if we enable the Azalia sound chip in the BIOS, and
load its Alsa sound driver, the Serial card will then share IRQ 17
with that sound chip, and then the serial card works. The serial
interrupt counter is incrementing in /proc/xenomai/irq and our serial
peripheral can utilize the serial port OK.

We don't want the sound driver enabled, but this test indicates that
16550A somehow failed to enable its interrupt, whereas the sound
driver succeeded in doing so.

How can we check a PIC, etc. to verify that the serial interrupt is
truly enabled when the 16550A driver is loaded alone?

Re: 16550A: failed to get the IRQ line free

[C Smith via Xenomai]

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 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 check that with 
> > CRCs).
> > This is the code which tries to handle shared interrupts and generates
> > the message:
> > intr.c :
> > static void xnintr_edge_vec_handler(unsigned int irq, void *cookie)
> > ...
> > if (counter > MAX_EDGEIRQ_COUNTER)
> > printk(XENO_ERR "%s: failed to get the IRQ%d line 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
>
> This check is a heuristic to detect whether we have a continuously
> firing IRQ source - or a buggy handler that always claims to have done
> something. If we spent 128 loops in the handler loop without ever seeing
> a single run without any handled IRQ, we terminate and pray that this
> will not cause more harm than stay in the loop.

Which part of the intr.c code terminates the handler if counter is too
high? I only see a warning printed if counter is too high.
I ask because maybe I could hack the code to terminate earlier and
check if I lose any serial bytes.

BTW I added a printk to intr.c but I couldn't see it even after I
rebuilt xenomai and did make install. The only way I could see it is
if I rebuilt and did make install of the whole kernel and its modules.
What exactly is intr.c linked to?

> Granted, the longer the chain of shared handler gets, the more likely it
> becomes that heavy IRQ load can trigger this case.
>
> But maybe your problem has a different reason: Are you sure you have
> edge-triggered IRQs here? Legacy INTx is usually rather level-triggered.
> Checking the driver... we hard-code edge, hmm. Maybe because the
> platform IRQs on x86 are edge. What does lspci -vv tell us about that
> card? What does Linux report (/proc/interrupts) when binding it to a
> normal driver? We likely need to make irqtype a module parameter or
> configure it automatically.
> Jan

I doubt the Moxa card has level sensitive interrupts, I assume it is
edge. But here is the lspci -vv output:
03:02.0 Serial controller: Moxa Technologies Co Ltd CP104U (4-port
RS-232 Universal PCI) (prog-if 02 [16550])
   Subsystem: Moxa Technologies Co Ltd CP104U (4-port RS-232 Universal PCI)
   Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
   Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- SERR- 

16550A: failed to get the IRQ line free

[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 check that with CRCs).
This is the code which tries to handle shared interrupts and generates
the message:
intr.c :
static void xnintr_edge_vec_handler(unsigned int irq, void *cookie)
...
if (counter > MAX_EDGEIRQ_COUNTER)
printk(XENO_ERR "%s: failed to get the IRQ%d line 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

Re: serial 16550A rx_timeout

[C Smith via Xenomai]

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  = 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
> > have a DIO port pulse depicting the duration of the read()).
> >
> > This is wasted time in my (RT userspace) app during the read() when
> > there is no serial traffic on a particular port, and I have many
> > serial ports. But why must I decide how long to stall the RT process
> > with a timeout? Can't read() return 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)
>
> IIRC as soon you configure a timeout, reads are blocking. Configuring -1
> as timeout will cause read to return immediately with -EAGAIN if no
> data is available.

Indeed you were right. I set .rx_timeout = -1 and now the read() is
nonblocking. errno gets set to EAGAIN, and it takes only 54us to read
6 inactive ports.
thanks  -C Smith

serial 16550A rx_timeout

[C Smith via Xenomai]

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
have a DIO port pulse depicting the duration of the read()).

This is wasted time in my (RT userspace) app during the read() when
there is no serial traffic on a particular port, and I have many
serial ports. But why must I decide how long to stall the RT process
with a timeout? Can't read() return 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

Re: Interrupt handler illicit call

[C Smith via Xenomai]

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)
> >> {
> >>static int err;
> >>unsigned long next;
> >>rtdm_irq_t *handle_p;
> >>
> >>handle_p = rtdm_irq_get_arg(irq_handle_p, rtdm_irq_t);
> >>
> >>next = rtdm_clock_read();
> >>// do some timing calculations with 'next' var here ...
> >>err = rtdm_irq_enable(handle_p);   //re-enable this for subsequent 
> >> interrupts
> >
> > You don't need this.
> > Unconditionally enabling the interrupt line will confuse the IRQ subsystem.
> >
>
> ...and it was never supported in primary mode. If it worked, then by
> chance and by disabling related checks. Enable/disable are no masking APIs.
>
> Jan
>
> >>   return 0;
> >
> > Please use RTDM_IRQ_HANDLED here instead of raw values.
> >
> >> }
> >
> > Thanks,
> > //richard

I was thinking the rtdm_irq_enable() was like an STI, but that was a
mistake.  I looked at the 16550A and CAN drivers for examples of
interrupt handlers, and indeed I found I must return RTDM_IRQ_HANDLED
too like Richard says, or Xenomai de-registers the interrupt since no
one appears to handle it. There doesn't seem to be an interrupt
example in Xenomai 3.1 or Xeno3.2 sources. Perhaps I should submit a
demo interrupt handler module as a patch?
-C Smith

Interrupt handler illicit call

[C Smith via Xenomai]

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 LPPORT_CTL (LPPORT+2)
#define LP_IRQ 7
#define IRQ_7_ENAB 0x10

static rtdm_irq_t irq_handle;
rtdm_irq_request(_handle,
   irq_level,
   Lp_port_handler,   /* This is the ISR */
   RTDM_IRQTYPE_EDGE,
   "parallel_port",
   _handle);
status = inb(LPPORT_CTL);
outb(status | IRQ_7_ENAB, LPPORT_CTL);
rtdm_irq_enable(_handle);

Here is the interrupt handler:

int Lp_port_handler(rtdm_irq_t *irq_handle_p)
{
   static int err;
   unsigned long next;
   rtdm_irq_t *handle_p;

   handle_p = rtdm_irq_get_arg(irq_handle_p, rtdm_irq_t);

   next = rtdm_clock_read();
   // do some timing calculations with 'next' var here ...
   err = rtdm_irq_enable(handle_p);   //re-enable this for subsequent interrupts
   if (err)
  rtdm_printk("could not enable parallel port IRQ, error code: %d\n", err);
   return 0;
}

Interrupts are coming in at about 200Hz,
But after about 12000 interrupts, I got this fault in dmesg:

[  592.239842] I-pipe: Detected illicit call from head domain 'Xenomai'
   into a regular Linux service
[  592.239849] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G   OE
  4.19.229xeno3.1-x8664H #4
[  592.239853] BUG: Unhandled exception over domain Xenomai at
0xb413c938 - switching to ROOT
[  592.239856] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G   OE
  4.19.229xeno3.1-x8664H #4
[  592.239859] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./SHARKBAY, BIOS 4.6.5 08/29/2017
[  592.239861] I-pipe domain: Linux
[  592.239864] Call Trace:
[  592.239867]  
[  592.239873]  dump_stack+0x95/0xc4
[  592.239878]  __ipipe_trap_prologue.cold.10+0x27/0x55
[  592.239882]  invalid_op+0x26/0x51
[  592.239886] RIP: 0010:__ipipe_spin_unlock_debug+0x18/0x20
[  592.239890] Code: 77 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f
1f 00 e8 db 53 8c 00 f7 c7 00 02 00 00 74 0f 55 48 89 e5 9c 58 f6 c4
02 75 02 <0f> 0b 5d c3 c3 0f 1f 00 e8 bb 53 8c 00 55 48 89 e5 41 55 41
54 53
[  592.239892] RSP: 0018:921d54d03b40 EFLAGS: 00010046
[  592.239895] RAX: 0006 RBX: c06dfb00 RCX: 001f
[  592.239898] RDX: 0001 RSI: 26e09369 RDI: 0200
[  592.239900] RBP: 921d54d03b40 R08: 921d54d284a0 R09: 
[  592.239902] R10:  R11: 0002 R12: c06dfb40
[  592.239905] R13: 0200 R14: 0007 R15: b55d5340
[  592.239911]  xnintr_enable+0x3b/0xa0
[  592.239916]  Lp_port_handler+0x77/0x80 [myapp]
[  592.239919]  xnintr_irq_handler+0x127/0x450
[  592.239923]  __ipipe_do_sync_stage+0xec/0x1a0
[  592.239926]  ipipe_unstall_root+0x34/0x40
[  592.239930]  ipipe_restore_root+0x24/0x30
[  592.239933]  vprintk_emit+0x138/0x260
[  592.239936]  vprintk_default+0x1f/0x30
[  592.239939]  vprintk_func+0x44/0xd0
[  592.239942]  do_vprintk+0x3d/0xe0
[  592.239947]  printk+0x58/0x6f
[  592.239951]  dump_stack_print_info+0x7c/0xe0
[  592.239955]  dump_stack+0x8c/0xc4
[  592.239958]  ipipe_root_only.cold.18+0x11/0x2c
[  592.239961]  ipipe_stall_root+0x11/0x40
[  592.239965]  _raw_spin_lock_irqsave+0x27/0x50
[  592.239969]  xnintr_enable+0x27/0xa0
[  592.239972]  Lp_port_handler+0x77/0x80 [myapp]
[  592.239975]  xnintr_irq_handler+0x127/0x450
[  592.239979]  dispatch_irq_head+0x9d/0x110
[  592.239983]  __ipipe_dispatch_irq+0x1bc/0x1e0
[  592.239988]  __ipipe_handle_irq+0x93/0x200
[  592.239991]  common_interrupt+0xf/0x2c
[  592.239994]  

What in my handler routine is incorrect API or "illicit"?
thanks,
-C Smith

Re: x86 kernel Oops in Xeno-3.1/3.2

[C Smith via Xenomai]

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  
> >> > > 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). Frequently the
> >> > >>> kernel Oopses within 4-6 hours. I have tried 2 identical 
> >> > >>> motherboards,
> >> > >>> changed RAM, and tried another manufacturer's motherboard on a 3rd
> >> > >>> computer.
> >> > >>>
> >> > >>> * Can someone supply me with a known successful x68 kernel 4.19.89
> >> > >>> config so I can compare and try those settings? I will attach my
> >> > >>> kernel config to this email, in hopes someone can see something wrong
> >> > >>> with them.
> >> > >>>
> >> > >>> Specs:  Intel i5-4590 CPU, Advantech motherboard with Q87 intel
> >> > >>> chipset, 8G RAM, Moxa 4-port PCI card w/ 16750 UARTs, 2 motherboard
> >> > >>> 16550 UARTS (in ISA memory range), Peak PCI CAN card, Xenomai 3.1
> >> > >>> (also xeno 3.2.1), Distro: RHEL8, with xenomai ipipe-patched 4.19.89
> >> > >>> kernel from kernel.org source.
> >> > >>>
> >> > >>> Sometimes onscreen (in a text terminal) I get this Oops:
> >> > >>>
> >> > >>> kernel tried to execute NX-protected page - exploit attempt? (uid: 
> >> > >>> 1000)
> >> > >>> BUG: unable to handle kernel paging request at ...
> >> > >>> PGD ... P4D ... PUD .. PHD ...
> >> > >>> Oops: 0011 [#1] SMP PTI
> >> > >>> CPU: 1 P1D: 3539 Comm: gui Tainted: G OE 4.19.89xeno3.1-i64x3832 #2
> >> > >>> Hardware name: To be filled by O.E.M. To be filled by 
> >> > >>> O.E.M./SHARKBAY,
> >> > >>> BIOS 4.6.5 08/29/2017
> >> > >>> I-pipe domain: Linux
> >> > >>> RIP: ... : ...
> >> > >>> Code: Bad RIP value.
> >> > >>>
> >> > >>> Which means the Instruction Pointer is in a Data area. That is bad,
> >> > >>> and I think it is caused by Cobalt code not restoring the
> >> > >>> stack/registers correctly during a context switch.
> >> > >>> Other times I get :
> >> > >>>
> >> > >>> Kernel Panic - not syncing: stack-protector: Kernel stack is 
> >> > >>> corrupted
> >> > >>> in: __xnsched_run.part.63 h -
> >> > >>> CPU: 1 PID: 2409 Comm: appnrtB Tainted: G OE 4.19.89Nen03.1-i64x8632 
> >> > >>> #2
> >> > >>> Hardware name: To be filled by 0.E.M. To be filled by OEM, BIOS 
> >> > >>> 4.6.5 04/23/2021
> >> > >>> I-pipe domain: Linux
> >> > >>> Call Trace:
> >> > >>> 
> >> > >>> dump_stack+8x95/8xna
> >> > >>> panic+8xe§l8x246
> >> > >>> ? ___xnsched_run.part.63+8x5c4/8x4d0
> >> > >>> __stack_chhk_fail+8x19x8x28
> >> > >>> ___xnsched_run.part.63+8x§c4/Bx§d8
> >> > >>> ? release_ioapic_irq+8x3f/8x58
> >> > >>> ? __ipipe_end_fasteoi_irq+BNZZ/8x38
> >> > >>> xnintr;edge_vec_handler+BXBIA/8x558
> >> > >>> __ipipe_do_sync_pipeline+8xS/ana
> >> > >>> dispatch_irq_head+8xe6/Bx118
> >> > >>> __ipipe_dispatch_irq+ax1bc/Bx1e8
> >> > >>> __ipipe_handle_irq+8x198/x208
> >> > >>> ? common_interrupt+8xf/Bx2c
> >> > >>> 
> >> > >>>
> >> > >>> The accompanying stack trace seems to implicate an ipipe interrupt
> >> > >>> handler as causing the problem. I'm using xeno_16550A.ko interrupts 
> >> > &g

Re: x86 kernel Oops in Xeno-3.1/3.2

[C Smith via Xenomai]

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 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 tried another manufacturer's motherboard on a 3rd
> > >>> computer.
> > >>>
> > >>> * Can someone supply me with a known successful x68 kernel 4.19.89
> > >>> config so I can compare and try those settings? I will attach my
> > >>> kernel config to this email, in hopes someone can see something wrong
> > >>> with them.
> > >>>
> > >>> Specs:  Intel i5-4590 CPU, Advantech motherboard with Q87 intel
> > >>> chipset, 8G RAM, Moxa 4-port PCI card w/ 16750 UARTs, 2 motherboard
> > >>> 16550 UARTS (in ISA memory range), Peak PCI CAN card, Xenomai 3.1
> > >>> (also xeno 3.2.1), Distro: RHEL8, with xenomai ipipe-patched 4.19.89
> > >>> kernel from kernel.org source.
> > >>>
> > >>> Sometimes onscreen (in a text terminal) I get this Oops:
> > >>>
> > >>> kernel tried to execute NX-protected page - exploit attempt? (uid: 1000)
> > >>> BUG: unable to handle kernel paging request at ...
> > >>> PGD ... P4D ... PUD .. PHD ...
> > >>> Oops: 0011 [#1] SMP PTI
> > >>> CPU: 1 P1D: 3539 Comm: gui Tainted: G OE 4.19.89xeno3.1-i64x3832 #2
> > >>> Hardware name: To be filled by O.E.M. To be filled by O.E.M./SHARKBAY,
> > >>> BIOS 4.6.5 08/29/2017
> > >>> I-pipe domain: Linux
> > >>> RIP: ... : ...
> > >>> Code: Bad RIP value.
> > >>>
> > >>> Which means the Instruction Pointer is in a Data area. That is bad,
> > >>> and I think it is caused by Cobalt code not restoring the
> > >>> stack/registers correctly during a context switch.
> > >>> Other times I get :
> > >>>
> > >>> Kernel Panic - not syncing: stack-protector: Kernel stack is corrupted
> > >>> in: __xnsched_run.part.63 h -
> > >>> CPU: 1 PID: 2409 Comm: appnrtB Tainted: G OE 4.19.89Nen03.1-i64x8632 #2
> > >>> Hardware name: To be filled by 0.E.M. To be filled by OEM, BIOS 4.6.5 
> > >>> 04/23/2021
> > >>> I-pipe domain: Linux
> > >>> Call Trace:
> > >>> 
> > >>> dump_stack+8x95/8xna
> > >>> panic+8xe§l8x246
> > >>> ? ___xnsched_run.part.63+8x5c4/8x4d0
> > >>> __stack_chhk_fail+8x19x8x28
> > >>> ___xnsched_run.part.63+8x§c4/Bx§d8
> > >>> ? release_ioapic_irq+8x3f/8x58
> > >>> ? __ipipe_end_fasteoi_irq+BNZZ/8x38
> > >>> xnintr;edge_vec_handler+BXBIA/8x558
> > >>> __ipipe_do_sync_pipeline+8xS/ana
> > >>> dispatch_irq_head+8xe6/Bx118
> > >>> __ipipe_dispatch_irq+ax1bc/Bx1e8
> > >>> __ipipe_handle_irq+8x198/x208
> > >>> ? common_interrupt+8xf/Bx2c
> > >>> 
> > >>>
> > >>> The accompanying stack trace seems to implicate an ipipe interrupt
> > >>> handler as causing the problem. I'm using xeno_16550A.ko interrupts on
> > >>> an isolated interrupt level (IRQ 18).
> > >>>
> > >>> Interestingly, the Cobalt scheduler and my RT userspace app are still
> > >>> running after this, even though the Linux kernel is halted. I proved
> > >>> this on an oscilloscope: I can see serial packets going into and out
> > >>> of the serial ports at the expected periodic time base.
> > >>>
> > >>> (Note that the text of these kernel faults above is reconstructed with
> > >>> OCR so some addresses are not complete. The computer is hard-locked in
> > >>> a text terminal when these happen. I can supply the full JPG pictures
> > >>> or re-type addresses if you like.)
> > >>>
> > >>> The application scenario which causes the above problems:  The primary
> > >>> app, “apprt2”,

Re: x86 kernel Oops in Xeno-3.1/3.2

[C Smith via Xenomai]

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 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 tried another manufacturer's motherboard on a 3rd
> >>> computer.
> >>>
> >>> * Can someone supply me with a known successful x68 kernel 4.19.89
> >>> config so I can compare and try those settings? I will attach my
> >>> kernel config to this email, in hopes someone can see something wrong
> >>> with them.
> >>>
> >>> Specs:  Intel i5-4590 CPU, Advantech motherboard with Q87 intel
> >>> chipset, 8G RAM, Moxa 4-port PCI card w/ 16750 UARTs, 2 motherboard
> >>> 16550 UARTS (in ISA memory range), Peak PCI CAN card, Xenomai 3.1
> >>> (also xeno 3.2.1), Distro: RHEL8, with xenomai ipipe-patched 4.19.89
> >>> kernel from kernel.org source.
> >>>
> >>> Sometimes onscreen (in a text terminal) I get this Oops:
> >>>
> >>> kernel tried to execute NX-protected page - exploit attempt? (uid: 1000)
> >>> BUG: unable to handle kernel paging request at ...
> >>> PGD ... P4D ... PUD .. PHD ...
> >>> Oops: 0011 [#1] SMP PTI
> >>> CPU: 1 P1D: 3539 Comm: gui Tainted: G OE 4.19.89xeno3.1-i64x3832 #2
> >>> Hardware name: To be filled by O.E.M. To be filled by O.E.M./SHARKBAY,
> >>> BIOS 4.6.5 08/29/2017
> >>> I-pipe domain: Linux
> >>> RIP: ... : ...
> >>> Code: Bad RIP value.
> >>>
> >>> Which means the Instruction Pointer is in a Data area. That is bad,
> >>> and I think it is caused by Cobalt code not restoring the
> >>> stack/registers correctly during a context switch.
> >>> Other times I get :
> >>>
> >>> Kernel Panic - not syncing: stack-protector: Kernel stack is corrupted
> >>> in: __xnsched_run.part.63 h -
> >>> CPU: 1 PID: 2409 Comm: appnrtB Tainted: G OE 4.19.89Nen03.1-i64x8632 #2
> >>> Hardware name: To be filled by 0.E.M. To be filled by OEM, BIOS 4.6.5 
> >>> 04/23/2021
> >>> I-pipe domain: Linux
> >>> Call Trace:
> >>> 
> >>> dump_stack+8x95/8xna
> >>> panic+8xe§l8x246
> >>> ? ___xnsched_run.part.63+8x5c4/8x4d0
> >>> __stack_chhk_fail+8x19x8x28
> >>> ___xnsched_run.part.63+8x§c4/Bx§d8
> >>> ? release_ioapic_irq+8x3f/8x58
> >>> ? __ipipe_end_fasteoi_irq+BNZZ/8x38
> >>> xnintr;edge_vec_handler+BXBIA/8x558
> >>> __ipipe_do_sync_pipeline+8xS/ana
> >>> dispatch_irq_head+8xe6/Bx118
> >>> __ipipe_dispatch_irq+ax1bc/Bx1e8
> >>> __ipipe_handle_irq+8x198/x208
> >>> ? common_interrupt+8xf/Bx2c
> >>> 
> >>>
> >>> The accompanying stack trace seems to implicate an ipipe interrupt
> >>> handler as causing the problem. I'm using xeno_16550A.ko interrupts on
> >>> an isolated interrupt level (IRQ 18).
> >>>
> >>> Interestingly, the Cobalt scheduler and my RT userspace app are still
> >>> running after this, even though the Linux kernel is halted. I proved
> >>> this on an oscilloscope: I can see serial packets going into and out
> >>> of the serial ports at the expected periodic time base.
> >>>
> >>> (Note that the text of these kernel faults above is reconstructed with
> >>> OCR so some addresses are not complete. The computer is hard-locked in
> >>> a text terminal when these happen. I can supply the full JPG pictures
> >>> or re-type addresses if you like.)
> >>>
> >>> The application scenario which causes the above problems:  The primary
> >>> app, “apprt2”, is a 32-bit userspace app (compiled -m32) running on
> >>> CPU core 1 (by fixed affinity), on 64 bit Xenomai 3.1 with ipipe patch
> >>> applied for x86 kernel 4.19.89. It has shared memory via mmap() with
> >>> an RTDM module (“modrt1”) but nothing is happening in “modrt1” at
> >>> present, no interrupts etc. There are also two non-RT userspace linux
> >>> apps which have attached to the 

Re: x86 kernel Oops in Xeno-3.1/3.2

[C Smith via Xenomai]

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). Frequently the
> > kernel Oopses within 4-6 hours. I have tried 2 identical motherboards,
> > changed RAM, and tried another manufacturer's motherboard on a 3rd
> > computer.
> >
> > * Can someone supply me with a known successful x68 kernel 4.19.89
> > config so I can compare and try those settings? I will attach my
> > kernel config to this email, in hopes someone can see something wrong
> > with them.
> >
> > Specs:  Intel i5-4590 CPU, Advantech motherboard with Q87 intel
> > chipset, 8G RAM, Moxa 4-port PCI card w/ 16750 UARTs, 2 motherboard
> > 16550 UARTS (in ISA memory range), Peak PCI CAN card, Xenomai 3.1
> > (also xeno 3.2.1), Distro: RHEL8, with xenomai ipipe-patched 4.19.89
> > kernel from kernel.org source.
> >
> > Sometimes onscreen (in a text terminal) I get this Oops:
> >
> > kernel tried to execute NX-protected page - exploit attempt? (uid: 1000)
> > BUG: unable to handle kernel paging request at ...
> > PGD ... P4D ... PUD .. PHD ...
> > Oops: 0011 [#1] SMP PTI
> > CPU: 1 P1D: 3539 Comm: gui Tainted: G OE 4.19.89xeno3.1-i64x3832 #2
> > Hardware name: To be filled by O.E.M. To be filled by O.E.M./SHARKBAY,
> > BIOS 4.6.5 08/29/2017
> > I-pipe domain: Linux
> > RIP: ... : ...
> > Code: Bad RIP value.
> >
> > Which means the Instruction Pointer is in a Data area. That is bad,
> > and I think it is caused by Cobalt code not restoring the
> > stack/registers correctly during a context switch.
> > Other times I get :
> >
> > Kernel Panic - not syncing: stack-protector: Kernel stack is corrupted
> > in: __xnsched_run.part.63 h -
> > CPU: 1 PID: 2409 Comm: appnrtB Tainted: G OE 4.19.89Nen03.1-i64x8632 #2
> > Hardware name: To be filled by 0.E.M. To be filled by OEM, BIOS 4.6.5 
> > 04/23/2021
> > I-pipe domain: Linux
> > Call Trace:
> > 
> > dump_stack+8x95/8xna
> > panic+8xe§l8x246
> > ? ___xnsched_run.part.63+8x5c4/8x4d0
> > __stack_chhk_fail+8x19x8x28
> > ___xnsched_run.part.63+8x§c4/Bx§d8
> > ? release_ioapic_irq+8x3f/8x58
> > ? __ipipe_end_fasteoi_irq+BNZZ/8x38
> > xnintr;edge_vec_handler+BXBIA/8x558
> > __ipipe_do_sync_pipeline+8xS/ana
> > dispatch_irq_head+8xe6/Bx118
> > __ipipe_dispatch_irq+ax1bc/Bx1e8
> > __ipipe_handle_irq+8x198/x208
> > ? common_interrupt+8xf/Bx2c
> > 
> >
> > The accompanying stack trace seems to implicate an ipipe interrupt
> > handler as causing the problem. I'm using xeno_16550A.ko interrupts on
> > an isolated interrupt level (IRQ 18).
> >
> > Interestingly, the Cobalt scheduler and my RT userspace app are still
> > running after this, even though the Linux kernel is halted. I proved
> > this on an oscilloscope: I can see serial packets going into and out
> > of the serial ports at the expected periodic time base.
> >
> > (Note that the text of these kernel faults above is reconstructed with
> > OCR so some addresses are not complete. The computer is hard-locked in
> > a text terminal when these happen. I can supply the full JPG pictures
> > or re-type addresses if you like.)
> >
> > The application scenario which causes the above problems:  The primary
> > app, “apprt2”, is a 32-bit userspace app (compiled -m32) running on
> > CPU core 1 (by fixed affinity), on 64 bit Xenomai 3.1 with ipipe patch
> > applied for x86 kernel 4.19.89. It has shared memory via mmap() with
> > an RTDM module (“modrt1”) but nothing is happening in “modrt1” at
> > present, no interrupts etc. There are also two non-RT userspace linux
> > apps which have attached to the same shared memory via mmap() but
> > those are doing nothing much during these tests. I have attached
> > several (1-6) RS232 serial devices and one CAN device all
> > communicating with “apprt2”.
> >
> > The system does not fault (for 48+ hours) when no peripheral
> > connections are present (Serial/CAN). The faults happen with Serial
> > traffic, whether the CAN device is attached or not. The CAN device
> > alone with no Serial does not cause the fault (tested for 48+ hours),
> > and the fault has also happened when the motherboard serial ports were
> > used, so the PCI Moxa code is not implicated.
> >
> > Note that in order to get 32-bit userspace support to fully work I had
> 

x86 kernel Oops in Xeno-3.1/3.2

[C Smith via Xenomai]

/2017
I-pipe domain: Linux
RIP: … : ...
Code: Bad RIP value.
…

* Is there some way to instrument the Cobalt kernel to debug this ? It
seems impossible to get any debug data from /proc/xenomai because the
Linux kernel is Oopsed.

A debugging problem:  occasionally with my apps compiled 64 bit on
Xeno 3.1 or 3.2 the tests run 24+ hours OK (but would fault
eventually, or in another test). So I get 'false positives' and it
takes weeks to make progress.  It is easiest to generate a kernel Oops
rapidly on Xeno 3.1 with my apps compiled 32 bit. So to expedite the
testing process may I propose to keep compiling 32 bit and we
instrument Xeno-3.1 (k4.19.89), and ultimately port the fix to
xeno-3.2 (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>

Re: [PATCH 2/2] Added verbosity to 16550A serial driver.

[C Smith via Xenomai]

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

Re: stable/v3.2.x started, future of other stable branches

[C Smith via Xenomai]

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 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:
>
> Hi all,
>
> in order to permit ABI/API breaking changes in next/master, I've just
> started the stable/v3.2.x based on current master. On xenomai-images
> side, CI/CT has been updated as well to account for that [1].
>
> As already indicated in [1], one change planed for master is to drop
> I-pipe support, thus kernels < 5.10. Therefore, CI for master is already
> limited to that scope.
>
> Now the question is how to continue with stable maintenance. I do have
> users on 3.0.x, thus I plan to keep that alive (though it is definitely
> calming down now). For 3.1.x, I'm lacking a feeling how the userbase is
> and how motivated that base is to consume stable updates vs. to move
> forward to 3.2.x. Any indications on that will help to decide about that
> branch. Without any feedback, I would push out yet another 3.2 release
> early next year and then close the branch.
>
> With that, I wish you already happy vacations (those who plan to) - I'll
> be offline from next week on and will be back in January.
>
> Jan
>
> [1]
> https://source.denx.de/Xenomai/xenomai-images/-/commit/beea63dd69ab6cf762f8d52748677d8e6be30be3
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>

common clocks RTDM/user-RT

[C Smith via Xenomai]

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 provides
(rx_event.rxpend_timestamp) and compare it to a timestamp from
rt_timer_read() in the userspace app.

In Xenomai 3 however, this comparison is no longer valid. They are
both nanosecond timers but can't be directly compared because the RTDM
timer has a large offset compared to rt_timer_read().

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.

posix blocking in gdb

[C Smith via Xenomai]

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 rtdm device.

If the code does an ioctl() for instance, this is invoked:
in rtdm.c
COBALT_IMPL(int, ioctl, (int fd, unsigned int request, ...))
   ret = do_ioctl(fd, request, arg);
which calls
 static int do_ioctl(int fd, unsigned int request, void *arg)
   ret = XENOMAI_SYSCALL3(sc_cobalt_ioctl, fd, request, arg);

 and my process blocks on the call to XENOMAI_SYSCALL3() so I cannot
step over this code. If I interrupt gdb, it says:
  0xf7fceb69 in __kernel_vsyscall ()Which basically means my process
was blocked.

I imagine the problem is caused by a difference between
primary/secondary modes 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

native message queue API in rtdm

[C Smith via Xenomai]

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 /usr/xenomai/include/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

Re: access errno in Xeno 3.1

[C Smith via Xenomai]

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 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 that, when I compile I get:
> > error: ‘errno’ undeclared (first use in this function)
> >   rtdm_printk("warning, munmap returned errno: %d\n", errno);
> >
>
> The kernel has no errno variable. That is a user space concept. In the
> kernel, you usually get errors via the return code of the function you
> invoked.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux

access errno in Xeno 3.1

[C Smith via Xenomai]

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 that, when I compile I get:
error: ‘errno’ undeclared (first use in this function)
  rtdm_printk("warning, munmap returned errno: %d\n", errno);

This is what I get when I do xeno-config:
/usr/xenomai/bin/xeno-config --skin=rtdm --cflags --ldflags
-I/usr/xenomai/include/cobalt -I/usr/xenomai/include -m32
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT
-fasynchronous-unwind-tables -D__COBA$
-Wl,--no-as-needed -Wl,@/usr/xenomai/lib/cobalt.wrappers
-Wl,@/usr/xenomai/lib/modechk.wrappers
/usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=$
(yes I built xenomai for 32 bit userspace apps)

What is the proper way to access errno?

thanks, -C Smith

[PATCH 1/1] drivers/can: 32-bit userspace app support for rtcan

[C Smith via Xenomai]

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 b290005..d1f9d31 100644
--- a/kernel/drivers/can/rtcan_internal.h
+++ b/kernel/drivers/can/rtcan_internal.h
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_XENO_DRIVERS_CAN_DEBUG
 #define RTCAN_ASSERT(expr, func) \
diff --git a/kernel/drivers/can/rtcan_raw.c b/kernel/drivers/can/rtcan_raw.c
index 693b927..88a179f 100644
--- a/kernel/drivers/can/rtcan_raw.c
+++ b/kernel/drivers/can/rtcan_raw.c
@@ -215,6 +215,53 @@ EXPORT_SYMBOL_GPL(rtcan_loopback);
 #endif /* CONFIG_XENO_DRIVERS_CAN_LOOPBACK */
 
 
+int rtcan_get_sockaddr(struct rtdm_fd *fd, struct sockaddr_can **saddrp,
+  const void *arg)
+{
+struct _rtdm_setsockaddr_args *setaddr, setaddr_buf;
+int ret = 0;
+
+if (!rtdm_fd_is_user(fd)) {
+setaddr = (struct _rtdm_setsockaddr_args *)arg;
+*saddrp = (struct sockaddr_can *)setaddr->addr;
+}
+
+#ifdef CONFIG_XENO_ARCH_SYS3264
+if (rtdm_fd_is_compat(fd)) {
+struct compat_rtdm_setsockaddr_args csetaddr_buff;
+
+/* Copy argument structure from userspace */
+ret = rtdm_safe_copy_from_user(fd, _buff,
+arg, sizeof(csetaddr_buff));
+if (ret)
+return ret;
+
+/* Check size */
+if (csetaddr_buff.addrlen != sizeof(struct sockaddr_can))
+return -EINVAL;
+
+return rtdm_safe_copy_from_user(fd, *saddrp,
+compat_ptr(csetaddr_buff.addr),
+sizeof(struct sockaddr_can));
+}
+#endif
+
+if (rtdm_safe_copy_from_user(fd, _buf, arg,
+sizeof(struct _rtdm_setsockaddr_args)))
+return -EFAULT;
+
+setaddr = _buf;
+
+/* Check size */
+if (setaddr->addrlen != sizeof(struct sockaddr_can))
+return -EINVAL;
+
+return rtdm_safe_copy_from_user(fd, *saddrp,
+setaddr->addr,
+sizeof(struct sockaddr_can));
+}
+
+
 int rtcan_raw_socket(struct rtdm_fd *fd, int protocol)
 {
 /* Only protocol CAN_RAW is supported */
@@ -408,46 +455,21 @@ static int rtcan_raw_setsockopt(struct rtdm_fd *fd,
 int rtcan_raw_ioctl(struct rtdm_fd *fd,
unsigned int request, void *arg)
 {
+struct sockaddr_can saddr, *saddrp = 
 int ret = 0;
 
 switch (request) {
-case _RTIOC_BIND: {
-   struct _rtdm_setsockaddr_args *setaddr, setaddr_buf;
-   struct sockaddr_can *sockaddr, sockaddr_buf;
-
-   if (rtdm_fd_is_user(fd)) {
-   /* Copy argument structure from userspace */
-   if (!rtdm_read_user_ok(fd, arg,
-  sizeof(struct _rtdm_setsockaddr_args)) ||
-   rtdm_copy_from_user(fd, _buf, arg,
-   sizeof(struct _rtdm_setsockaddr_args)))
-   return -EFAULT;
-
-   setaddr = _buf;
-
-   /* Check size */
-   if (setaddr->addrlen != sizeof(struct sockaddr_can))
-   return -EINVAL;
-
-   /* Copy argument structure from userspace */
-   if (!rtdm_read_user_ok(fd, arg,
-  sizeof(struct sockaddr_can)) ||
-   rtdm_copy_from_user(fd, _buf, setaddr->addr,
-   sizeof(struct sockaddr_can)))
-   return -EFAULT;
-   sockaddr = _buf;
-   } else {
-   setaddr = (struct _rtdm_setsockaddr_args *)arg;
-   sockaddr = (struct sockaddr_can *)setaddr->addr;
-   }
-
-   /* Now, all required data are in kernel space */
-   ret = rtcan_raw_bind(fd, sockaddr);
 
+COMPAT_CASE(_RTIOC_BIND):
+ret = rtcan_get_sockaddr(fd, , arg);
+   if (ret)
+   return ret;
+if (saddrp == NULL)
+   return -EFAULT;
+   ret = rtcan_raw_bind(fd, saddrp);
break;
-}
 
-case _RTIOC_SETSOCKOPT: {
+COMPAT_CASE(_RTIOC_SETSOCKOPT): {
struct _rtdm_setsockopt_args *setopt;
struct _rtdm_setsockopt_args setopt_buf;
 
@@ -532,7 +554,7 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_fd *fd,
 struct rtcan_socket *sock = rtdm_fd_to_private(fd);
 struct sockaddr_can scan;
 nanosecs_rel_t timeout;
-struct iovec *iov = (struct iovec *)msg->msg_iov;
+struct iovec iov_fast[RTDM_IOV_FASTMAX], *iov;
 struct iovec iov_buf;
 can_frame_t frame;
 nanosecs_abs_t timestamp = 0;
@@ -584,6 +606,10 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_fd *fd,
iov = _buf;
 }
 
+ret = rtdm_get_iovec(fd, , msg, iov_fast);
+if (ret)
+return ret;
+
 /* Check size of buffer */
 if (iov->iov_len < sizeof(can_frame_t))
return -EMSGSIZE;
@@ -768,7 +794,7 @@ ssize_t rtcan

Re: rtcansend 32-bit

[C Smith via Xenomai]

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 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 b290005..d1f9d31 100644
--- a/kernel/drivers/can/rtcan_internal.h
+++ b/kernel/drivers/can/rtcan_internal.h
@@ -28,6 +28,7 @@
#include 
#include 
+#include 
#ifdef CONFIG_XENO_DRIVERS_CAN_DEBUG
#define RTCAN_ASSERT(expr, func) \
diff --git a/kernel/drivers/can/rtcan_raw.c b/kernel/drivers/can/rtcan_raw.c
index 693b927..88a179f 100644
--- a/kernel/drivers/can/rtcan_raw.c
+++ b/kernel/drivers/can/rtcan_raw.c
@@ -215,6 +215,53 @@ EXPORT_SYMBOL_GPL(rtcan_loopback);
#endif /* CONFIG_XENO_DRIVERS_CAN_LOOPBACK */
+int rtcan_get_sockaddr(struct rtdm_fd *fd, struct sockaddr_can **saddrp,
+const void *arg)
+{
+ struct _rtdm_setsockaddr_args *setaddr, setaddr_buf;
+ int ret = 0;
+
+ if (!rtdm_fd_is_user(fd)) {
+ setaddr = (struct _rtdm_setsockaddr_args *)arg;
+ *saddrp = (struct sockaddr_can *)setaddr->addr;
+ }
+
+#ifdef CONFIG_XENO_ARCH_SYS3264
+ if (rtdm_fd_is_compat(fd)) {
+ struct compat_rtdm_setsockaddr_args csetaddr_buff;
+
+ /* Copy argument structure from userspace */
+ ret = rtdm_safe_copy_from_user(fd, _buff,
+ arg, sizeof(csetaddr_buff));
+ if (ret)
+ return ret;
+
+ /* Check size */
+ if (csetaddr_buff.addrlen != sizeof(struct sockaddr_can))
+ return -EINVAL;
+
+ return rtdm_safe_copy_from_user(fd, *saddrp,
+ compat_ptr(csetaddr_buff.addr),
+ sizeof(struct sockaddr_can));
+ }
+#endif
+
+ if (rtdm_safe_copy_from_user(fd, _buf, arg,
+ sizeof(struct _rtdm_setsockaddr_args)))
+ return -EFAULT;
+
+ setaddr = _buf;
+
+ /* Check size */
+ if (setaddr->addrlen != sizeof(struct sockaddr_can))
+ return -EINVAL;
+
+ return rtdm_safe_copy_from_user(fd, *saddrp,
+ setaddr->addr,
+ sizeof(struct sockaddr_can));
+}
+
+
int rtcan_raw_socket(struct rtdm_fd *fd, int protocol)
{
/* Only protocol CAN_RAW is supported */
@@ -408,46 +455,21 @@ static int rtcan_raw_setsockopt(struct rtdm_fd *fd,
int rtcan_raw_ioctl(struct rtdm_fd *fd,
unsigned int request, void *arg)
{
+ struct sockaddr_can saddr, *saddrp = 
int ret = 0;
switch (request) {
- case _RTIOC_BIND: {
-   struct _rtdm_setsockaddr_args *setaddr, setaddr_buf;
-   struct sockaddr_can *sockaddr, sockaddr_buf;
-
-   if (rtdm_fd_is_user(fd)) {
-/* Copy argument structure from userspace */
-if (!rtdm_read_user_ok(fd, arg,
-sizeof(struct _rtdm_setsockaddr_args)) ||
-   rtdm_copy_from_user(fd, _buf, arg,
-sizeof(struct _rtdm_setsockaddr_args)))
-   return -EFAULT;
-
-setaddr = _buf;
-
-/* Check size */
-if (setaddr->addrlen != sizeof(struct sockaddr_can))
-   return -EINVAL;
-
-/* Copy argument structure from userspace */
-if (!rtdm_read_user_ok(fd, arg,
-sizeof(struct sockaddr_can)) ||
-   rtdm_copy_from_user(fd, _buf, setaddr->addr,
-sizeof(struct sockaddr_can)))
-   return -EFAULT;
-sockaddr = _buf;
-   } else {
-setaddr = (struct _rtdm_setsockaddr_args *)arg;
-sockaddr = (struct sockaddr_can *)setaddr->addr;
-   }
-
-   /* Now, all required data are in kernel space */
-   ret = rtcan_raw_bind(fd, sockaddr);
+ COMPAT_CASE(_RTIOC_BIND):
+ ret = rtcan_get_sockaddr(fd, , arg);
+   if (ret)
+return ret;
+ if (saddrp == NULL)
+return -EFAULT;
+   ret = rtcan_raw_bind(fd, saddrp);
   break;
- }
- case _RTIOC_SETSOCKOPT: {
+ COMPAT_CASE(_RTIOC_SETSOCKOPT): {
   struct _rtdm_setsockopt_args *setopt;
   struct _rtdm_setsockopt_args setopt_buf;
@@ -532,7 +554,7 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_fd *fd,
struct rtcan_socket *sock = rtdm_fd_to_private(fd);
struct sockaddr_can scan;
nanosecs_rel_t timeout;
- struct iovec *iov = (struct iovec *)msg->msg_iov;
+ struct iovec iov_fast[RTDM_IOV_FASTMAX], *iov;
struct iovec iov_buf;
can_frame_t frame;
nanosecs_abs_t timestamp = 0;
@@ -584,6 +606,10 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_fd *fd,
   iov = _buf;
}
+ ret = rtdm_get_iovec(fd, , msg, iov_fast);
+ if (ret)
+ return ret;
+
/* Check size of buffer */
if (iov->iov_len < sizeof(can_frame_t))
   return -EMSGSIZE;
@@ -768,7 +794,7 @@ ssize_t rtcan_raw_sendmsg(struct rtdm_fd *fd,
struct rtcan_socket *sock = rtdm_fd_to_private(fd);
struct sockaddr_can *scan = (struct sockaddr_can *)msg->msg_name;
struct sockaddr_can scan_buf;
- struct iovec *iov = (struct iovec *)msg->msg_iov;
+ struct iovec iov_fast[RTDM_IOV_FASTMAX], *iov;
struct iovec iov_buf;
can_frame_t *frame;
can_frame_t frame_buf;
@@ -841,6 +867,10 @@ ssize_t

Re: rtcansend 32-bit

[C Smith via Xenomai]

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 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/rtcan_internal.h
b/kernel/drivers/can/rtcan_internal.h
index b290005..03febef 100644
--- a/kernel/drivers/can/rtcan_internal.h
+++ b/kernel/drivers/can/rtcan_internal.h
@@ -28,6 +28,7 @@

 #include 
 #include 
+#include 

 #ifdef CONFIG_XENO_DRIVERS_CAN_DEBUG
 #define RTCAN_ASSERT(expr, func) \
@@ -58,4 +59,6 @@
 #define rtcandev_err(dev, fmt, args...) \
  printk(KERN_ERR "%s: " fmt, (dev)->name, ##args)

+#define COMPAT_CASE(__op) case __op __COMPAT_CASE(__op  ## _COMPAT)
+
 #endif /* __RTCAN_INTERNAL_H_ */
diff --git a/kernel/drivers/can/rtcan_raw.c b/kernel/drivers/can/rtcan_raw.c
index 693b927..6e8ebe6 100644
--- a/kernel/drivers/can/rtcan_raw.c
+++ b/kernel/drivers/can/rtcan_raw.c
@@ -215,6 +215,58 @@ EXPORT_SYMBOL_GPL(rtcan_loopback);
 #endif /* CONFIG_XENO_DRIVERS_CAN_LOOPBACK */


+int rtcan_get_sockaddr(struct rtdm_fd *fd, struct sockaddr_can **saddrp,
+   const void *arg)
+{
+struct _rtdm_setsockaddr_args *setaddr, setaddr_buf;
+int ret = 0;
+
+if (!rtdm_fd_is_user(fd)) {
+setaddr = (struct _rtdm_setsockaddr_args *)arg;
+*saddrp = (struct sockaddr_can *)setaddr->addr;
+}
+
+#ifdef CONFIG_XENO_ARCH_SYS3264
+if (rtdm_fd_is_compat(fd)) {
+struct compat_rtdm_setsockaddr_args csetaddr_buff;
+
+/* Copy argument structure from userspace */
+ret = rtdm_safe_copy_from_user(fd, _buff,
+arg, sizeof(csetaddr_buff));
+if (ret)
+return ret;
+
+/* Check size */
+if (csetaddr_buff.addrlen != sizeof(**saddrp))
+return -EINVAL;
+
+return rtdm_safe_copy_from_user(fd, *saddrp,
+compat_ptr(csetaddr_buff.addr),
+sizeof(struct sockaddr_can));
+*saddrp = NULL;
+return 0;
+}
+#endif
+
+if (rtdm_safe_copy_from_user(fd, _buf, arg,
+sizeof(struct _rtdm_setsockaddr_args)))
+return -EFAULT;
+
+setaddr = _buf;
+
+/* Check size */
+if (setaddr->addrlen != sizeof(struct sockaddr_can))
+return -EINVAL;
+
+return rtdm_safe_copy_from_user(fd, *saddrp,
+setaddr->addr,
+sizeof(struct sockaddr_can));
+
+*saddrp = NULL;
+return 0;
+}
+
+
 int rtcan_raw_socket(struct rtdm_fd *fd, int protocol)
 {
 /* Only protocol CAN_RAW is supported */
@@ -408,46 +460,21 @@ static int rtcan_raw_setsockopt(struct rtdm_fd *fd,
 int rtcan_raw_ioctl(struct rtdm_fd *fd,
 unsigned int request, void *arg)
 {
+struct sockaddr_can saddr, *saddrp = 
 int ret = 0;

 switch (request) {
-case _RTIOC_BIND: {
- struct _rtdm_setsockaddr_args *setaddr, setaddr_buf;
- struct sockaddr_can *sockaddr, sockaddr_buf;
-
- if (rtdm_fd_is_user(fd)) {
-/* Copy argument structure from userspace */
-if (!rtdm_read_user_ok(fd, arg,
-   sizeof(struct _rtdm_setsockaddr_args)) ||
- rtdm_copy_from_user(fd, _buf, arg,
-sizeof(struct _rtdm_setsockaddr_args)))
- return -EFAULT;

-setaddr = _buf;
+COMPAT_CASE(_RTIOC_BIND):
+ret = rtcan_get_sockaddr(fd, , arg);
+ if (ret)
+ return ret;
+if (saddrp == NULL)
+ return -EFAULT;
+ret = rtcan_raw_bind(fd, saddrp);
+break;

-/* Check size */
-if (setaddr->addrlen != sizeof(struct sockaddr_can))
- return -EINVAL;
-
-/* Copy argument structure from userspace */
-if (!rtdm_read_user_ok(fd, arg,
-   sizeof(struct sockaddr_can)) ||
- rtdm_copy_from_user(fd, _buf, setaddr->addr,
-sizeof(struct sockaddr_can)))
- return -EFAULT;
-sockaddr = _buf;
- } else {
-setaddr = (struct _rtdm_setsockaddr_args *)arg;
-sockaddr = (struct sockaddr_can *)setaddr->addr;
- }
-
- /* Now, all required data are in kernel space */
- ret = rtcan_raw_bind(fd, sockaddr);
-
- break;
-}
-
-case _RTIOC_SETSOCKOPT: {
+COMPAT_CASE(_RTIOC_SETSOCKOPT): {
  struct _rtdm_setsockopt_args *setopt;
  struct _rtdm_setsockopt_args setopt_buf;

@@ -532,7 +559,7 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_fd *fd,
 struct rtcan_socket *sock = rtdm_fd_to_private(fd);
 struct sockaddr_can scan;
 nanosecs_rel_t timeout;
-struct iovec *iov = (struct iovec *)msg->msg_iov;
+ struct iovec iov_fast[RTDM_IOV_FASTMAX], *iov;
 struct iovec iov_buf;
 can_frame_t frame;
 nanosecs_abs_t timestamp = 0;
@@ -584,6 +611,10 @@ ssize_t rtcan_raw_recvms

Re: rtcansend 32-bit

[C Smith via Xenomai]

I was able to make the CAN transmit work successfully from my 32 bit
compile of rtcansend.c, by adding rtdm_get_iovec() to the code. I'll submit
a patch once both transmit  and receive are working, but I'm still having
trouble receiving data in the rtcanrecv app. I added rtdm_get_iovec() to
rtcan_raw_recvmsg() so that may ultimately work but the driver is already
giving up during the bind. I get this error:

[root@pc can]# /usr/xenomai/bin/rtcanrecv rtcan0 -v
interface rtcan0
s=3, ifr_name=rtcan0
bind: Invalid argument
Cleaning up...

Here's the ioctl with extra printk()s, which executes during the bind:

int rtcan_raw_ioctl(struct rtdm_fd *fd,unsigned int request, void *arg)
{
int ret = 0;

switch (request) {
COMPAT_CASE(_RTIOC_BIND): {
struct _rtdm_setsockaddr_args *setaddr, setaddr_buf;
struct sockaddr_can *sockaddr, sockaddr_buf;

if (rtdm_fd_is_user(fd)) {
   /* Copy argument structure from userspace */
printk("rtcan_raw.c, 421: rtcan_raw_ioctl\n");

if (rtdm_safe_copy_from_user(fd, _buf, arg,
   sizeof(struct _rtdm_setsockaddr_args)))
return -EFAULT;

   setaddr = _buf;
printk("rtcan_raw.c, 427: rtcan_raw_ioctl\n");
printk("rtcan_raw.c, 428: setaddr->addrlen: %d\n", setaddr->addrlen);

   /* Check size */
   if (setaddr->addrlen != sizeof(struct sockaddr_can))
return -EINVAL;

The resultant print statements in dmesg :
[27177.480980] rtcan_raw.c, 421: rtcan_raw_ioctl
[27177.480987] rtcan_raw.c, 427: rtcan_raw_ioctl
[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:
> > > On 02.11.21 23:57, C Smith via Xenomai wrote:
> > > > I added some printf/printk to rtcansend.c as well as rtcan_raw.c:
> > > >
> > > > rtcan_raw.c:
> > > > /* Check size of buffer */
> > > > if (iov->iov_len != sizeof(can_frame_t)) {
> > > > printk("rtcan_raw.c, 850: sizeof(can_frame_t): %ld\n",
> > > >sizeof(can_frame_t));
> > > > printk("rtcan_raw.c, 852: iov->iov_len: %ld\n",
> > > > iov->iov_len);
> > > > return -EMSGSIZE;
> > > > }
> > > >
> > > > when running rtcansend (32-bit compile, which fails with EMSGSIZE):
> > > > [root@pc can]# /usr/xenomai/bin/rtcansend rtcan0 -s 0xde
> 0xad
> > > > sizeof(can_frame_t): 16
> > > > send: Message too long
> > > >
> > > > [root@pc can]# dmesg
> > > > [11275.197125] rtcan_raw.c, 850: sizeof(can_frame_t): 16
> > > > [11275.197133] rtcan_raw.c, 852: iov->iov_len: 34494267600
> > > >
> > > > when running rtcansend (64-bit compile, sends out can msg OK):
> > > > [root@pc can]# /usr/xenomai/bin/rtcansend rtcan0 -s 0xde
> 0xad
> > > > sizeof(can_frame_t): 16
> > > >
> > > > [root@pc can]# dmesg
> > > > [12476.571032] rtcan_raw.c, 850: sizeof(can_frame_t): 16
> > > > [12476.571040] rtcan_raw.c, 852: iov->iov_len: 16
> > > >
> > > > It looks like the struct user_msghdr *msg passed into
> rtcan_raw_sendmsg()
> > > > is corrupt.
> > > > I'm using Xenomai 3.1, with kernel 4.19.989 x86_64
> > > > -C Smith
> > >
> > > OK, my guess was wrong. Let me see where we corrupt this.
> > >
> > > Brings https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/21
> into
> > > memory...
> > >
> >
> > Found it: We are lacking use of rtdm_get_iovec in rtcan - in contrast to
> > RTnet (see e.g. rt_packet_sendmsg). Would you feel like looking into
> > such a change?
>
> Just a note: rtcan_raw_sendmsg() and rtcan_raw_recvmsg() are both
> affected. Both should be using rtdm_get_iovec().
>
> >
> > Jan
> >
>
>

Re: rtcansend 32-bit

[C Smith via Xenomai]

I added some printf/printk to rtcansend.c as well as rtcan_raw.c:

rtcan_raw.c:
/* Check size of buffer */
if (iov->iov_len != sizeof(can_frame_t)) {
printk("rtcan_raw.c, 850: sizeof(can_frame_t): %ld\n",
   sizeof(can_frame_t));
printk("rtcan_raw.c, 852: iov->iov_len: %ld\n",
iov->iov_len);
return -EMSGSIZE;
}

when running rtcansend (32-bit compile, which fails with EMSGSIZE):
[root@pc can]# /usr/xenomai/bin/rtcansend rtcan0 -s 0xde 0xad
sizeof(can_frame_t): 16
send: Message too long

[root@pc can]# dmesg
[11275.197125] rtcan_raw.c, 850: sizeof(can_frame_t): 16
[11275.197133] rtcan_raw.c, 852: iov->iov_len: 34494267600

when running rtcansend (64-bit compile, sends out can msg OK):
[root@pc can]# /usr/xenomai/bin/rtcansend rtcan0 -s 0xde 0xad
sizeof(can_frame_t): 16

[root@pc can]# dmesg
[12476.571032] rtcan_raw.c, 850: sizeof(can_frame_t): 16
[12476.571040] rtcan_raw.c, 852: iov->iov_len: 16

It looks like the struct user_msghdr *msg passed into rtcan_raw_sendmsg()
is corrupt.
I'm using 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.
> > 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]# /usr/xenomai/bin/rtcansend rtcan0 --verbose
> > --identifier=0x123 0xde 0xad
> > send: Message too long
> >
> > Looking at rtcansend.c. The call to sendto is failing and returns
> 'Message
> > too long' here:
> > ret = sendto(s, (void *), sizeof(can_frame_t), 0,
> > (struct sockaddr *)_addr, sizeof(to_addr));
> >
> > Here is how I configured Xenomai 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 ?
> >
>
> We possibly have compat ABI issue here: The Xenomai core can handle
> 32-bit calls of sendto (sendmsg internally) into 64-bit kernel, but
> maybe there is something beyond that interpreted by the CAN driver that
> is not aware of 32 vs. 64 bit userland.
>
> I suspect sizeof(can_frame_t) varies, though I don't see why yet. Could
> you debug that, instrument kernel/drivers/can/rtcan_raw.c as well as the
> userspace code?
>
> The other reason for EMSGSIZE would be msg_iovlen != 1, but that would
> mean we have an issue in the generic compat sendmsg code, and that is
> less likely.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>

rtcansend 32-bit

[C Smith via Xenomai]

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]# /usr/xenomai/bin/rtcansend rtcan0 --verbose
--identifier=0x123 0xde 0xad
send: Message too long

Looking at rtcansend.c. The call to sendto is failing and returns 'Message
too long' here:
ret = sendto(s, (void *), sizeof(can_frame_t), 0,
(struct sockaddr *)_addr, sizeof(to_addr));

Here is how I configured Xenomai 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

Re: which mmap API

[C Smith via Xenomai]

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 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 to do it a certain way. Here is the
> > (abbreviated) code I used:
> >
> > typedef struct { // shared struct
> >int data[PAGE_SIZE*4];
> > } shm_test_t;
> >
> > shm_test_t *shm_test_p = 0;// create a driver struct to share
> > shm_test_p = kmalloc(sizeof(shm_test_t) + RTDM_MAX_DEVNAME_LEN,
> > GFP_KERNEL);
> >
> > static struct rtdm_driver device_tmpl = {
> >.profile_info=
> > RTDM_PROFILE_INFO(mydev_,RTDM_CLASS_EXPERIMENTAL,0,999),
> >.device_flags = RTDM_NAMED_DEVICE | RTDM_EXCLUSIVE,
> >.device_count= MAX_DEVICES,
> >.context_size = sizeof(struct mydev_context),
> >.ops = {
> >   .open = mydev_open,
> >   .close= mydev_close,
> >   .read_nrt = mydev_read,
> >   .ioctl_rt   = mydev_ioctl,
> >   .ioctl_nrt = mydev_ioctl,
> >   .mmap = mydev_mmap,
> >},
> > };
> >
> > // device initialization
> > dev = kmalloc(sizeof(struct rtdm_device) + RTDM_MAX_DEVNAME_LEN,
> > GFP_KERNEL);
> > dev->driver = _tmpl;
> > dev->label = "mydev%d";
> > name = (char *)(dev + 1);
> > ksformat(name, RTDM_MAX_DEVNAME_LEN, dev->label, i);
> > err = rtdm_dev_register(dev);
> >
> > // .mmap op handler
> > int mydev_mmap(struct rtdm_fd *fd, struct vm_area_struct *vma)
> > {
> > rtdm_mmap_kmem(vma, shm_test_p);   // do the address conversion
> > }
> >
> > That works.  I can share the shm_test_t struct between my rtdm driver and
> > userspace.
> > In userspace I do:
> > mydev_fd = open("/dev/rtdm/mydev0", O_RDWR);  // linked against Xeno3.1
> > posix wrappers
> > shmem_data_p = (shm_test_t *)
> > mmap(0,sizeof(shm_test_t),PROT_READ|PROT_WRITE,MAP_SHARED,mydev_fd,0);
> >
> > That works, but why don't I need rtdm_mmap_to_user() in the .mmap op
> > handler? If rtdm_mmap_kmem() does the job then why does
> rtdm_mmap_to_user()
> > exist?
>
> rtdm_mmap_to_user is only foreseen for cases outside of an mmap handler,
> typically in some specific ioctl (see e.g.
> kernel/drivers/analogy/buffer.c). Most cases a better and more
> consistently handled via mmap handler and, thus, mmap() syscalls. We can
> improve the documentation on this cases. For rtdm_mmap_{k,v,io}mem, the
> situation should be better already.
>
> In any case, patches welcome.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>
-- next part --
A non-text attachment was scrubbed...
Name: mmap-doc-patch-xeno3.1.1.patch
Type: text/x-patch
Size: 2098 bytes
Desc: not available
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20211028/7cda0ef5/attachment.bin>

which mmap API

[C Smith via Xenomai]

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 data[PAGE_SIZE*4];
} shm_test_t;

shm_test_t *shm_test_p = 0;// create a driver struct to share
shm_test_p = kmalloc(sizeof(shm_test_t) + RTDM_MAX_DEVNAME_LEN,
GFP_KERNEL);

static struct rtdm_driver device_tmpl = {
   .profile_info=
RTDM_PROFILE_INFO(mydev_,RTDM_CLASS_EXPERIMENTAL,0,999),
   .device_flags = RTDM_NAMED_DEVICE | RTDM_EXCLUSIVE,
   .device_count= MAX_DEVICES,
   .context_size = sizeof(struct mydev_context),
   .ops = {
  .open = mydev_open,
  .close= mydev_close,
  .read_nrt = mydev_read,
  .ioctl_rt   = mydev_ioctl,
  .ioctl_nrt = mydev_ioctl,
  .mmap = mydev_mmap,
   },
};

// device initialization
dev = kmalloc(sizeof(struct rtdm_device) + RTDM_MAX_DEVNAME_LEN,
GFP_KERNEL);
dev->driver = _tmpl;
dev->label = "mydev%d";
name = (char *)(dev + 1);
ksformat(name, RTDM_MAX_DEVNAME_LEN, dev->label, i);
err = rtdm_dev_register(dev);

// .mmap op handler
int mydev_mmap(struct rtdm_fd *fd, struct vm_area_struct *vma)
{
rtdm_mmap_kmem(vma, shm_test_p);   // do the address conversion
}

That works.  I can share the shm_test_t struct between my rtdm driver and
userspace.
In userspace I do:
mydev_fd = open("/dev/rtdm/mydev0", O_RDWR);  // linked against Xeno3.1
posix wrappers
shmem_data_p = (shm_test_t *)
mmap(0,sizeof(shm_test_t),PROT_READ|PROT_WRITE,MAP_SHARED,mydev_fd,0);

That works, but why don't I need rtdm_mmap_to_user() in the .mmap op
handler? If rtdm_mmap_kmem() does the job then why does rtdm_mmap_to_user()
exist?

thanks, -C Smith

Re: timer.h in rtdm module

[C Smith via Xenomai]

Thanks for the insight. I removed the -isystem line, I don't know where it
came from, I have legacy xeno 2.6 Makefiles. I added a few more paths to
system headers. I am now getting a lot of redefined symbols errors.  Here
is current attempt to compile: (this is compiled while standing in
/usr/src/linux/ BTW)

gcc -Wp,-MD,/home/appuser/src/codebase/ecl/modules/.myapp.o.d -nostdinc
-I./arch/x86/include -I./arch/x86/include/generated  -I./include
-I./include/linux -I/usr/lib/gcc/x86_64-redhat-linux/8/include
 -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi
-I./include/uapi -I./include/generated/uapi -include
./include/linux/kconfig.h -include ./include/linux/compiler_types.h
-I/usr/xenomai/include/cobalt -I/usr/include -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-fshort-wchar -Werror-implicit-function-declaration -Wno-format-security
-std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64
-falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone
-mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
-DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern
-mindirect-branch-register -fno-jump-tables -Iarch/x86/xenomai/include
-Iinclude/xenomai -fno-delete-null-pointer-checks -Wno-frame-address
-Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -O2
--param=allow-store-data-races=0 -Wframe-larger-than=2048
-fstack-protector-strong -Wno-unused-but-set-variable
-Wno-unused-const-variable -fno-omit-frame-pointer
-fno-optimize-sibling-calls -fno-var-tracking-assignments -g -pg -mfentry
-DCC_USING_FENTRY -Wdeclaration-after-statement -Wno-pointer-sign
-Wno-stringop-truncation -fno-strict-overflow -fno-merge-all-constants
-fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init
-fmacro-prefix-map=./= -fcf-protection=none -Wno-packed-not-aligned
-I/lib/modules/4.19.89xeno3.1-i64x8632/build/include/xenomai
-I/lib/modules/4.19.89xeno3.1-i64x8632/build/include/xenomai/posix
-I/home/appuser/src/codebase -I/usr/xenomai/include/trank
-I/usr/xenomai/include -D__XENO_COMPAT__  -DMODULE
 -DKBUILD_BASENAME='"myapp"' -DKBUILD_MODNAME='"myapp"' -c -o
/home/appuser/src/codebase/ecl/modules/myapp.o
/home/appuser/src/codebase/ecl/modules/myapp.c
In file included from /usr/xenomai/include/trank/trank.h:21,
 from /usr/xenomai/include/trank/native/timer.h:22,
 from /home/appuser/src/codebase/ecl/modules/myapp.c:19:
/usr/xenomai/include/boilerplate/compiler.h:23: warning: "container_of"
redefined
 #define container_of(ptr, type, member) \

In file included from ./include/linux/list.h:9,
 from ./include/linux/module.h:9,
 from /home/appuser/src/codebase/ecl/modules/myapp.c:7:
./include/linux/kernel.h:1000: note: this is the location of the previous
definition
 #define container_of(ptr, type, member) ({\

In file included from /usr/xenomai/include/copperplate/clockobj.h:22,
 from /usr/xenomai/include/alchemy/timer.h:22,
 from /usr/xenomai/include/trank/native/timer.h:23,
 from /home/appuser/src/codebase/ecl/modules/myapp.c:19:
/usr/xenomai/include/cobalt/pthread.h:33:25: error: field sched_param has
incomplete type
   struct sched_param_ex sched_param;
 ^~~
In file included from /usr/xenomai/include/copperplate/clockobj.h:23,
 from /usr/xenomai/include/alchemy/timer.h:22,
 from /usr/xenomai/include/trank/native/timer.h:23,
 from /home/appuser/src/codebase/ecl/modules/myapp.c:19:
/usr/xenomai/include/xeno_config.h:74: warning:
"CONFIG_XENO_REVISION_LEVEL" redefined
 #define CONFIG_XENO_REVISION_LEVEL

In file included from ././include/linux/kconfig.h:5,
 from :
./include/generated/autoconf.h:1916: note: this is the location of the
previous definition
 #define CONFIG_XENO_REVISION_LEVEL 0

I really don't have a tutorial as to how a RTDM module should be compiled.
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 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
> &

timer.h in rtdm module

[C Smith via Xenomai]

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 error:
In file included from /home/csmith/src/app3-prog/modules/myapp.c:19:
/usr/xenomai/include/trank/native/timer.h:21:10: fatal error: errno.h: No
such file or directory

I compiled with make V=1 and I will show you the whole gcc command line
(sorry it's long):

gcc -Wp,-MD,/home/csmith/src/app3-prog/ecl/modules/.myapp.o.d  -nostdinc
-isystem /usr/lib/gcc/x86_64-redhat-linux/8/include -I./arch/x86/include
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/kconfig.h -include
./include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-fshort-wchar -Werror-implicit-function-declaration -Wno-format-security
-std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64
-falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone
-mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
-DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern
-mindirect-branch-register -fno-jump-tables -Iarch/x86/xenomai/include
-Iinclude/xenomai -fno-delete-null-pointer-checks -Wno-frame-address
-Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -O2
--param=allow-store-data-races=0 -Wframe-larger-than=2048
-fstack-protector-strong -Wno-unused-but-set-variable
-Wno-unused-const-variable -fno-omit-frame-pointer
-fno-optimize-sibling-calls -fno-var-tracking-assignments -g -pg -mfentry
-DCC_USING_FENTRY -Wdeclaration-after-statement -Wno-pointer-sign
-Wno-stringop-truncation -fno-strict-overflow -fno-merge-all-constants
-fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init
-fmacro-prefix-map=./= -fcf-protection=none -Wno-packed-not-aligned
-I/lib/modules/4.19.89xeno3.1-i64x8632/build/include/xenomai
-I/lib/modules/4.19.89xeno3.1-i64x8632/build/include/xenomai/posix
-I/home/csmith/src/app3-prog -I/usr/xenomai/include/trank
-I/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

Re: cannot link 32 bit app

[C Smith via Xenomai]

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 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 reduced my very large app to
> > about 200 lines, it only starts one periodic process. but I still get
> > this error during linkage:
> >
> > /usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main':
> > /usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple
> > definition of `xenomai_main'
> >
> /usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94:
> > first defined here
> > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition
> > of `xenomai_auto_bootstrap'
> > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here
> > /usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main':
> > /usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple
> > definition of `xenomai_main'
> >
> /usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94:
> > first defined here
> > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition
> > of `xenomai_auto_bootstrap'
> > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here
> > /usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main':
> > /usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple
> > definition of `xenomai_main'
> >
> /usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94:
> > first defined here
> > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition
> > of `xenomai_auto_bootstrap'
> > /usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here
> > collect2: error: ld returned 1 exit status
> > make[1]: *** [: myapp] Error 1
> >
> > I had used your advice to get the compiler args in my Makefile with:
> > /usr/xenomai/bin/xeno-config --skin=native --cflags --ldflags
> > The resulting command line is:
> >
> > gcc -g3 -m32 -I/usr/xenomai/include/trank -D__XENO_COMPAT__
> > -I/usr/xenomai/include/cobalt
> > -I/usr/xenomai/include -m32 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
> > -D_REENTRANT -fasynchronous-unwind-tables
> > -D__COBALT__ -I/usr/xenomai/include/alchemy -I/usr/xenomai/include/rtdm
> > -Wl,--no-as-needed -ltrank
> > -Wl,@/usr/xenomai/lib/modechk.wrappers -lalchemy -lcopperplate
> > /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 -m32   -lfuse -pthread -I/usr/include/libxml2 -I"SOEM/"
> > -I"SOEM/osal" -I"SOEM/oshw/linux"
> > -I"SOEM/soem" -I"../include/nanopb"-Xlinker -rpath -Xlinker
> > /usr/xenomai/lib  myapp.c ../include/myapp.h
> > ../include/dia_dev_myapp.h ../include/crc_table.h ../include/dacdefs.h
> > ../include/version.h
> > ../include/canopen_drives.h ../include/adcdefs.h
> > ../include/myapp_version.h ../include/canodefs.h
> > ../include/preproc_myapp.h ../include/myapp_mem_manager_data.h
> > ../include/comm_dta_myapp.h ../include/comproto.h
> > ../modules/rtdinsync.h quad.o dac.o adc.o SOEM/lib/linux/liboshw.a
> > SOEM/lib/linux/libosal.a SOEM/lib/linux/libsoem.a
> > ../include/nanopb/nanopb.a  -Wl,--no-as-needed -ltrank
> > -Wl,@/usr/xenomai/lib/modechk.wrappers -lalchemy -lcopperplate
> > /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 -m32   -lfuse
> > -pthread  -Wl,--no-as-needed
> > -Wl,@/usr/xenomai/lib/cobalt.wrappers
> -Wl,@/usr/xenomai/lib/modechk.wrappers
> > /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 -m32   -lfuse
> > -pthread  -Wl,--no-as-needed
> > -Wl,@/usr/xenomai/lib/cobalt.wrappers
> -Wl,@/usr/xenomai/lib/modechk.wrappers
> > /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
> > -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld
> > -L/usr/xenomai/l

Re: cannot link 32 bit app

[C Smith via Xenomai]

Hi Jan,Thanks for your prompt reply.  I reduced my very large app to about
200 lines, it only starts one periodic process. but I still get this error
during linkage:

/usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main':
/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple
definition of `xenomai_main'
/usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94:
first defined here
/usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition of
`xenomai_auto_bootstrap'
/usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here
/usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main':
/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple
definition of `xenomai_main'
/usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94:
first defined here
/usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition of
`xenomai_auto_bootstrap'
/usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here
/usr/xenomai/lib/xenomai/bootstrap.o: In function `xenomai_main':
/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94: multiple
definition of `xenomai_main'
/usr/xenomai/lib/xenomai/bootstrap.o:/usr/src/xenomai-3.1/lib/boilerplate/init/bootstrap.c:94:
first defined here
/usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): multiple definition of
`xenomai_auto_bootstrap'
/usr/xenomai/lib/xenomai/bootstrap.o:(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [: myapp] Error 1

I had used your advice to get the compiler args in my Makefile with:
/usr/xenomai/bin/xeno-config --skin=native --cflags --ldflags
The resulting command line is:

gcc -g3 -m32 -I/usr/xenomai/include/trank -D__XENO_COMPAT__
-I/usr/xenomai/include/cobalt
-I/usr/xenomai/include -m32 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-D_REENTRANT -fasynchronous-unwind-tables
-D__COBALT__ -I/usr/xenomai/include/alchemy -I/usr/xenomai/include/rtdm
-Wl,--no-as-needed -ltrank
-Wl,@/usr/xenomai/lib/modechk.wrappers -lalchemy -lcopperplate
/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 -m32   -lfuse -pthread -I/usr/include/libxml2 -I"SOEM/"
-I"SOEM/osal" -I"SOEM/oshw/linux"
-I"SOEM/soem" -I"../include/nanopb"-Xlinker -rpath -Xlinker
/usr/xenomai/lib  myapp.c ../include/myapp.h
../include/dia_dev_myapp.h ../include/crc_table.h ../include/dacdefs.h
../include/version.h
../include/canopen_drives.h ../include/adcdefs.h ../include/myapp_version.h
../include/canodefs.h
../include/preproc_myapp.h ../include/myapp_mem_manager_data.h
../include/comm_dta_myapp.h ../include/comproto.h
../modules/rtdinsync.h quad.o dac.o adc.o SOEM/lib/linux/liboshw.a
SOEM/lib/linux/libosal.a SOEM/lib/linux/libsoem.a
../include/nanopb/nanopb.a  -Wl,--no-as-needed -ltrank
-Wl,@/usr/xenomai/lib/modechk.wrappers -lalchemy -lcopperplate
/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 -m32   -lfuse -pthread
 -Wl,--no-as-needed
-Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers
/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 -m32   -lfuse -pthread
 -Wl,--no-as-needed
-Wl,@/usr/xenomai/lib/cobalt.wrappers -Wl,@/usr/xenomai/lib/modechk.wrappers
/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 -m32   -lfuse -pthread
 -lxml2 -lz -llzma -lm
-ldl -L"SOEM/lib/linux" -Wl,--start-group -loshw -losal -lsoem
-Wl,--end-group -lm -o myapp

What 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
> > 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 (I am porting my
> > xenomai 2.6 codebase to xeno 3.1). I have compiled the kernel OK with 32
> > bit emulation support (CONFIG_IA32_EMULATION=y), as I must run my very
> > large legacy xenomai 2.6 codebase as 32 bit.  The xenomai testsuite
> > latency, clocktest, switchtest apps run fine, BTW.
> >
> > Is the problem that the xenomai libs like cobalt are 64 bit only? Did I
> > omit some xenomai configure option to support 32 bit xenomai apps ?
> >
> > Here is an example of the kind of gcc command line my Makef

cannot link 32 bit app

[C Smith via Xenomai]

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 (I am porting my
xenomai 2.6 codebase to xeno 3.1). I have compiled the kernel OK with 32
bit emulation support (CONFIG_IA32_EMULATION=y), as I must run my very
large legacy xenomai 2.6 codebase as 32 bit.  The xenomai testsuite
latency, clocktest, switchtest apps run fine, BTW.

Is the problem that the xenomai libs like cobalt are 64 bit only? Did I
omit some xenomai configure option to support 32 bit xenomai apps ?

Here is an example of the kind of gcc command line my Makefile puts out:
gcc -g3 -m32 -I/usr/xenomai/include/trank -D__XENO_COMPAT__
-I/usr/xenomai/include/cobalt -I/usr/xenomai/include -D_GNU_SOURCE
-D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__
-I/usr/xenomai/include/alchemy -I/usr/include/libxml2
-I/usr/xenomai/include/rtdm  -I"../include/nanopb"-Xlinker -rpath
-Xlinker /usr/xenomai/lib  testapp.c  ../modules/rtdinsync.h
-Wl,--no-as-needed -ltrank -Wl,@/usr/xenomai/lib/modechk.wrappers -lalchemy
-lcopperplate /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  -Wl,--no-as-needed
-Wl,@/usr/xenomai/lib/cobalt.wrappers
-Wl,@/usr/xenomai/lib/modechk.wrappers
 /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  -Wl,--no-as-needed
-Wl,@/usr/xenomai/lib/cobalt.wrappers
-Wl,@/usr/xenomai/lib/modechk.wrappers
 /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

ipipe kernel image compile error

[C Smith via Xenomai]

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:

arch/x86/kernel/apb_timer.c: In function ‘apbt_set_mapping’:
arch/x86/kernel/apb_timer.c:122:21: error: too few arguments to function
‘dw_apb_clocksource_init’
  clocksource_apbt = dw_apb_clocksource_init(APBT_CLOCKSOURCE_RATING,
 ^~~
In file included from arch/x86/kernel/apb_timer.c:31:
./include/linux/dw_apb_timer.h:50:1: note: declared here
 dw_apb_clocksource_init(unsigned rating, const char *name, void __iomem
*base,
 ^~~
make[2]: *** [scripts/Makefile.build:303: arch/x86/kernel/apb_timer.o]
Error 1
make[1]: *** [scripts/Makefile.build:544: arch/x86/kernel] Error 2
make[1]: *** Waiting for unfinished jobs


 config_20200331



Thank you
-- next part --
A non-text attachment was scrubbed...
Name: config_20200331
Type: application/octet-stream
Size: 208519 bytes
Desc: not available
URL: 

Re: rt_dev_send() stalls periodic task

[C Smith via Xenomai]

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 time. My 72 byte TX packet from the xenomai periodic
> task gets
> > cut in half and there is no transmission for 7msec, then the
> transmission
> > resumes. (I'll send you a screenshot)
>
> What is driver and application state during that phase? Who is waiting on
> what?
> This will be the key to resolve that issue as I'm not yet seeing another
> mistake
> in the driver.
>

I don't think there is a bug in the serial driver, per se, but my strange
UART requires more from a driver to prevent stalls.
This is a BCM corp 'BCM87Q' industrial motherboard. They are still sold,
not yet EOL.

We do know a lot about the state the serial driver is in: It is just
waiting, thinking it doesn't have any more bytes to transmit. Remember in
previous tests the IIR indicated no pending bytes in the THR. I've
demonstrated how to get past this state with my TX "polling patch".  I ran
my latest test for 12+ hours where I was using your patch plus my polling
patch and there were no stalls whatsoever of the serial driver, as verified
by an Oscilloscope which triggers on a TX stall. The maximum inter-packet
jitter of my TX packet was also fairly low, at <= 450us. In my polling
patch, during a RX interrupt, the code redundantly checks the high level
transmit buffer to see if rt_16550_tx_fill() should be called. Sure, this
workaround only helps when you have full-duplex communications, it would
not help during simplex communications.

Since a device driver can't be reliably polled, I'd prefer some
self-correcting mechanism in the driver which set a callback when it thinks
it has transmitted the last byte, and wakes up and checks one more time
about 100us later to see if it needs to transmit anything else.

> Also, I made the /.rx_timeout/.tx_timeout /change Jeff found, and it had
> the
> > obvious effect. I can make a patch for xeno 2.6.5 if you want. But I'll
> point
> > out that this fix may break peoples code functionally, so it may be a
> bad idea
> > to fix it on 2.x. Older code was written with a dependence on a truly
> different
> > timeout. It broke my app to fix this because there was suddenly a new
> unexpected
> > timeout. What's your policy on this issue?
>
> The 2.6 repo won't be touched anymore, it's officially dead. If course,
> you can
> share your patch on the list in case there are other remaining users.
>

Oh your fine work in 2.6 is very much alive!
But I can agree that adding fixes to it is not appropriate.

-C Smith

Re: rt_dev_send() stalls periodic task

[C Smith via Xenomai]

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
7msec, then the transmission resumes. (I'll send you a screenshot)
(Note that I am on xeno 2.6.5 so I merged your 3.x patch above into
16550A.c manually.)

I'm currently doing a 12 hour test of your patch plus mine. In my patch I
check during every RX interrupt to see if I need to call rt_16550_tx_fill()
too. I know that doesn't work for others but my traffic is full duplex so
this test will tell us something if it works and maybe we can ultimately
get the same behavior without my hack.

Also, I made the *.rx_timeout/.tx_timeout *change Jeff found, and it had
the obvious effect. I can make a patch for xeno 2.6.5 if you want. But I'll
point out that this fix may break peoples code functionally, so it may be a
bad idea to fix it on 2.x. Older code was written with a dependence on a
truly different timeout. It broke my app to fix this because there was
suddenly a new unexpected timeout. What's your policy on this issue?

Re: rt_dev_send() stalls periodic task

[C Smith via Xenomai]

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 interrupt routine again. Essentially:
if (ctx->out_npend > 0)
   rt_16550_tx_interrupt(ctx)
With this modified driver I was able to stream data successfully without
any stalls for 8+ hours. An oscilloscope showed there were only occasional
delays in sending the data, like an extra 800us.
That 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

Re: rt_dev_send() stalls periodic task

[C Smith via Xenomai]

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 terms of timing, because it receives its own transmissions.
My app receives packets from another computer asynchronously (full duplex).
So there is likely a random timing anomaly causing the problem.  Any
properly working UART and driver should be able to handle this, National
Semiconductor would say. But I have a strange serial port, and it is
tricking the xeno_16550A driver.

Jan alluded to a buffer-filling race condition in his comment.
I also fear that Receive interrupt handlers are somehow clearing Transmit
interrupts?

I didn't look at the stack trace when my app hung at startup due to that
infinite RX config. BTW there was no serial traffic whatsover during this
hang. I could try it again and look at the stack...
Also, it would be too hard to rewrite my apps to send single bytes. Its two
computers, rigid packet protocols & CRCs etc. Lots and lots of code. Thats
why I did that test app.

-C Smith

Re: rt_dev_send() stalls periodic task

[C Smith via Xenomai]

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 xeno_16550A driver RTSER_RTIOC_GET_STATUS ioctl to return to
userspace the contents of the IIR and the IER too.
I'm getting IIR = 0b 0001 0100, so the source of the latest interrupt is a
RX (not surprising, as I'm doing full duplex) and there is no THRE
interrupt pending.
So regardless of the ultimate cause, this state will never empty the TX
buffer.

I think my only choice is to try something I had to do once before on a
similarly misbehaving serial port: I'll rewrite the xeno_16550A interrupt
handlers to redundantly check for data pending in the TX buffer whenever
any interrupt like an RX interrupt happens. I do have bidirectional traffic
after all, so the driver will wake up frequently and keep the TX data
transmitting.

Interesting enough, the stall problem did not occur when I used the sample
serial code provided by xenomai: cross-link.c . I also rewrote cross-link.c
to send a 72 byte packet and receive on the same port (I installed a
physical loopback device on the serial port). No stalls for 12+ hours with
packets streaming at 100 Hz.
The only difference in the serial configuration between that cross-link.c
app and my app was :
struct rtser_config :
.rx_timeout= RTSER_DEF_TIMEOUT  // infinite ,  no stall for
many hours in cross-link.c
versus:
.rx_timeout= 50   // 500us, stalls within an hour in my
app
I don't know why an RX setting affects TX behavior. I also can't use
RTSER_DEF_TIMEOUT in my application or it dies when it starts up - no clue
why.  But I did try setting
  .rx_timeout= 500   // 5 ms. my app doesnt stall for several
hours
and though that did not cause the serial to stall in my app for several
hours of testing, it is just open-loop finger-crossing, and not a real
solution.
I need the TX interrupts to fire reliably. So I think I must rewrite that
interrupt handler, as above.

-C Smith

Re: rt_dev_send() stalls periodic task

[C Smith via Xenomai]

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, or  0110  binary
which means both transmit holding and transmit shift registers were empty,
thus nothing was queued up in the UART for transmission.
The return value of rt_dev_write() was only 8, after a 72 byte packet was
submitted to rt_dev_write().
So your theory that the TX interrupt got lost seems correct.

First, why does rt_dev_write() wait until all bytes are transmitted ?
Shouldn't it be effectively "non blocking" ?

Second, how might l generate another UART TX interrupt to keep the
transmission going?
Can we modify the serial driver at a low level to check the LSR vs the
bytes in the buffer, and force transmission until the buffer is empty?

thanks,
-C Smith

Re: rt_dev_send() stalls periodic task

[C Smith via Xenomai]

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 = RTSER_8_BITS,
> >  .stop_bits = RTSER_1_STOPB,
> >  .handshake = RTSER_NO_HAND,
> >  .fifo_depth= RTSER_DEF_FIFO_DEPTH, //RTSER_FIFO_DEPTH_8,
> >  .reserved  = 0,
> >  .rx_timeout= 50,
> >  .tx_timeout= RTSER_DEF_TIMEOUT,
> >  .event_timeout = 500,
> >  .timestamp_history = RTSER_RX_TIMESTAMP_HISTORY,
> >  .event_mask= RTSER_EVENT_RXPEND,
> > };
> > fd_tty[0] = rt_dev_open("rtser1", O_RDWR | O_NONBLOCK);
> > sret = rt_dev_ioctl(fd_tty[0], RTSER_RTIOC_SET_CONFIG, _config);
> >
> > The application transmits a packet of about 75 bytes repeatedly from a
> > xenomai periodic task that wakes up at 125Hz repeatedly. Note that there
> is
> > also a small RX serial packet arriving so there is some full-duplex
> > overlap.  On rtser0 this works fine, on the other serial ports the stall
> > happens after a few hours and my periodic xenomai task stops. There is no
> > xenomai watchdog message in dmesg. The code is repeatedly checking the
> > serial port status ioctl and there are no errors like framing errors etc.
> >
> > The periodic task is just a typical xenomai while() loop:
> >next += period_ns + adjust_ns;
> >  rt_task_sleep_until(next);
> >
> > When my periodic task stops the kernel says the stack trace is:
> > [root@oyx ~]# cd /proc/1066/task/1075/
> > [root@oyx 1075]# cat stack
> > [] xnpod_suspend_thread+0x3d8/0x650
> > [] xnsynch_sleep_on+0x139/0x320
> > [] rtdm_event_timedwait+0x2e4/0x390
> > [] rt_16550_write+0x35b/0x540 [xeno_16550A]
>
> This means the driver is stuck while writing because there are no more
> free
> entries in the hardware TX FIFO. Do you have hardware flow control
> enabled? Are
> you sure the that the receiving side is playing nicely?
> Jan
>

Well I'm not trying to use hardware flow control. Is hardware flow control
the xeno_16550A driver default?
I am using a 3-wire serial cable, no RTS/CTS wires at all, they are
floating.

At present my app only ever calls the ioctl RTSER_RTIOC_SET_CONFIG as
detailed above.
Are you saying 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

rt_dev_send() stalls periodic task

[C Smith via Xenomai]

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 have a problem, but the other two serial ports have
the stalling problem (rtser1 0x2f8 irq 5, rtser2 0x2e8 irq 3). Three
motherboards of this brand have been tried with the same results. There are
no shared interrupts in this scenario.

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 = RTSER_8_BITS,
.stop_bits = RTSER_1_STOPB,
.handshake = RTSER_NO_HAND,
.fifo_depth= RTSER_DEF_FIFO_DEPTH, //RTSER_FIFO_DEPTH_8,
.reserved  = 0,
.rx_timeout= 50,
.tx_timeout= RTSER_DEF_TIMEOUT,
.event_timeout = 500,
.timestamp_history = RTSER_RX_TIMESTAMP_HISTORY,
.event_mask= RTSER_EVENT_RXPEND,
};
fd_tty[0] = rt_dev_open("rtser1", O_RDWR | O_NONBLOCK);
sret = rt_dev_ioctl(fd_tty[0], RTSER_RTIOC_SET_CONFIG, _config);

The application transmits a packet of about 75 bytes repeatedly from a
xenomai periodic task that wakes up at 125Hz repeatedly. Note that there is
also a small RX serial packet arriving so there is some full-duplex
overlap.  On rtser0 this works fine, on the other serial ports the stall
happens after a few hours and my periodic xenomai task stops. There is no
xenomai watchdog message in dmesg. The code is repeatedly checking the
serial port status ioctl and there are no errors like framing errors etc.

The periodic task is just a typical xenomai while() loop:
  next += period_ns + adjust_ns;
rt_task_sleep_until(next);

When my periodic task stops the kernel says the stack trace is:
[root@oyx ~]# cd /proc/1066/task/1075/
[root@oyx 1075]# cat stack
[] xnpod_suspend_thread+0x3d8/0x650
[] xnsynch_sleep_on+0x139/0x320
[] rtdm_event_timedwait+0x2e4/0x390
[] rt_16550_write+0x35b/0x540 [xeno_16550A]
[] __rt_dev_write+0x63/0x110
[] sys_rtdm_write+0x24/0x30
[] hisyscall_event+0x1ec/0x380
[] ipipe_syscall_hook+0x3a/0x50
[] __ipipe_notify_syscall+0xb0/0x160
[] pipeline_syscall+0x7/0x18
[] 0x

I can attach with a debugger, and when I do I think the debugger gets us
out of the stall, so can actually single step the code for a little while.
I can't see any suspicious variable values, only that the serial port
transmitted 40 of my 75 bytes, which is unusual. But I can only single step
until my task sleeps one more time. At the next wakeup if I step into the
rt_dev_write() the task stalls forever and I can no longer debug.

(gdb) thread 2
[Switching to thread 2 (Thread 0xb7797b40 (LWP 1336))]
#0  0xb77caa92 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) where
#0  0xb77caa92 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xb775d872 in rt_dev_write (fd=12, buf=0xa8eda001, nbyte=72) at
core.c:72
#2  0x08056515 in Process_serial (comm_p=0x810e644 ,
portnum=1 '\001') at periodic_app.cpp:5404
#3  0x0804e0e4 in Periodic_routine (cookie=0x0) at periodic_app.cpp:1654
#4  0xb7764acd in rt_task_trampoline (cookie=0x0) at task.c:113
#5  0xb777a313 in start_thread () from /lib/libpthread.so.0
#6  0xb7528f2e in clone () from /lib/libc.so.6

I'm using an Intel I5 CPU, 32 bit kernel 3.18.20, Xenomai 2.6.5. I must be
on this Xenomai/kernel version to support tens of thousands of lines of
legacy code. I diffed the driver sources and the rtl_16550 driver did not
functionally change between Xenomai 2.6.5 and Xenomai 3.0.8.

I looked at the rt_dev_write() source code, but I don't see an obvious
infinite loop (though the assembly code 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

Re: Qt application on Xenomai

[C Smith via Xenomai]

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
thread creates, and put any time-critical code into the RT thread. Send
messages on XDDP sockets (or similar fifos) between the two processes if
necessary. Your UI and multimedia graphics don't really need determinism,
they have only 'soft real time' timing requirements (they can drop frames
or finish 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 :
>
> The Xenomai impact will depend on the processor architecture selected
> (uniprocessor or multiprocessor).
>
> In uniprocessor context, while your rt application will consume cpu
> time, meanwhile the other scheduled application will be waiting for
> their time slice.
>
> And thus GUI application is interrupted and may be slow in some cases
> (that really depends on the impact of the RT process). In multiprocessor
> context, this becomes no more a problem.
>
> Performance is then dependant on the cpu architecture (x86/x64/arm...)
> and their graphics chip device.
>
> Depending on the graphics chip, the performance needed to drive a 19inch
> size display is not the same as driving a 7inch size display.
>
> There are two kinds of Qt applications these days : Native Qt and QML
> applications.
>
> * Qt is native and can use 2D OpenGL or display framebuffer,
>
> * QML is no more than a javascript application layer running in a
> javascript web engine , in this case you will be performance mainly
> impacted by the QML architecture.
>
> If your GUI application fits only few buttons in a display, then, that's
> not a problem.
>
> Regards.
>
> Stéphane ANCELOT
>
>
> Le 02/03/2019 à 06:57, Sumitabh Ghosh via Xenomai a écrit :
> > Hi Henning,
> >
> > Thanks for your confirmation. Just to understand your set up further,
> does
> > the POSIX layer used by QT is of the Xenomai skin ? Is This the way Qt is
> > leveraging the rt features ?
> >
> > I guess the rendering of graphics is handled through non rt Linux
> > framebuffer /opengl apis.
> >
> > Let me know if my above understanding is correct.
> >
> > Thanks,
> > Sumit
> >
> >
> >
> >
> > On Fri, Mar 1, 2019, 18:02 Henning Schild 
> > wrote:
> >
> >> Hi,
> >>
> >> i am not sure i fully understand the question. In case you are worried
> >> about combining Xenomai and Qt, i can assure you that it is possible.
> >> We do have big c++/Qt applications running both rt and non-rt on
> >> xenomai.
> >>
> >> regards,
> >> Henning
> >>
> >> Am Fri, 1 Mar 2019 14:10:42 +0530
> >> schrieb Sumitabh Ghosh via Xenomai :
> >>
> >>> Hi,
> >>>
> >>> I have a generic question not specific to any platform. If I want to
> >>> run a small graphics application on Xenomai 3.x what would be the
> >>> correct approach. e.g. Qt application framework which needs POSIX
> >>> apis and a linux frame buffer to be able to render 2D applications.
> >>>
> >>> Kindly provide me some pointers.
> >>>
> >>> Thanks in advance.
> >>>
> >>> Cheers!
> >>> Sumit
> >>
>

Re: Periodic timing varies across boots

[C Smith via Xenomai]

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, 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 has been
> >>> working fine for years on several motherboards. I am able to adjust the
> >>> period of my task to within +/-10nsec, according to the frequency
> >> counter.
> >>> I can calibrate the periodic timing down to a period +/-10nsec on this
> >>> motherboard, and I cna restart my xenomai process many times and the
> >> timing
> >>> is fine. But if I cold-reboot the machine the measured period is wrong
> by
> >>> up to  +/-300nsec. Thus I cannot get consistent periodic timing from
> day
> >> to
> >>> day without recalibrating, which is unacceptable in my application.
> >>>
> >>> In my kernel config, I am using the TSC: CONFIG_X86_TSC=y
> >>> I use rt_timer_read() 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?
> >> Stéphane Ancelot said:
> >> Your problem seems being related to SMI interrupts rising.
> >> According to your chipset , Program xenomai  kernel SMI registers in
> >> boot options ,  in order to avoid this problem.
> >> Regards,
> >> S.Ancelot
> >>
> >
> >> Can you reproduce the issue with a supported Xenomai and kernel version?
> >>
> >> Jan
> >>
> >>
> > We have tens of thousands of legacy code so I must use Xenomai 2.6.5 - we
> > will endeavor to got to Xenomai 3.x next year.
> > Per your suggestion I could try writing a stripped-down periodic app and
> > booting into Xenomai 3 for a test though... I'll do that soon and let you
> > know how it goes.
> > I doubt there is anything wrong with Xenomai 2.6.5 though. My periodic
> > timing worked fine with 3 other motherboards and this same
> > Xeno kernel, but I must use this motherboard because of its form factor
> > (and we spent months qualifying it).
> >
> > First, I am exploring what Stephane A. said above, where he suspects SMI
> > interference.
> > I did try adding xeno_hal.smi=1 to my kernel boot options, but I get this
> > in dmesg at boot:
> >   Xenomai: SMI-enabled chipset found
> >   Xenomai: SMI workaround failed!
> > So I guess I can't solve the problem that way.
>
> It looks so. At the very least, this motherboard denied global disabling
> of SMIs to the Xenomai core (which current motherboards do anyway).
> Maybe disabling of specific SMI sources could be achieved, but finding
> which ones should and could be masked would be required.
>
> > My periodic timing is not fixed by this attempt either.
> > Note that during boot I see: "CPU0: Thermal monitoring handled by SMI"
> >
>
> This may be a hint. Thermal monitoring in BIOS is a known source of
> latency on x86.
>
> > I also ran the 'latency' regression test and it does not show large
> > latencies, they are <= 2.6 usec.
> > * Does that indicate SMI is not interrupting my process?
>
> How long did it run? You may need to run this test for an hour to be
> sure, while the system is stressed by some other workload. switchtest -s
> 200 for instance. And/or a kernel build on all of your 4 cores if
> possible, to lower the odds of involving thermal events.
>
> If there is no sign of latency, then you might rule out some SMI sources
> like thermal monitoring. However, this would not exclude other sources
> like USB for instance.
>
> > * Is there anything I should disable in the BIOS or kernel, like ACPI ?
> >
>
> ACPI is required with SMP at the very least. There could be other
> issues, such as NMI-based perf sampling. The NMI handler attached to
> this event may have to run through pretty heavyweight ACPI code in the
> kernel causing such latency (300 us clearly is in the ballpark for such
> events). You can't disable perf event monitoring in the x86 kernel, b

kernel compile problem

[C Smith via Xenomai]

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 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: 
<http://xenomai.org/pipermail/xenomai/attachments/20190228/b79a99dc/attachment.obj>

Re: Periodic timing varies across boots

[C Smith via Xenomai]

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.
> >
> > 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 has been
> > working fine for years on several motherboards. I am able to adjust the
> > period of my task to within +/-10nsec, according to the frequency
> counter.
> > I can calibrate the periodic timing down to a period +/-10nsec on this
> > motherboard, and I cna restart my xenomai process many times and the
> timing
> > is fine. But if I cold-reboot the machine the measured period is wrong by
> > up to  +/-300nsec. Thus I cannot get consistent periodic timing from day
> to
> > day without recalibrating, which is unacceptable in my application.
> >
> > In my kernel config, I am using the TSC: CONFIG_X86_TSC=y
> > I use rt_timer_read() 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?
> Stéphane Ancelot said:
> Your problem seems being related to SMI interrupts rising.
> According to your chipset , Program xenomai  kernel SMI registers in
> boot options ,  in order to avoid this problem.
> Regards,
> S.Ancelot
>


> Can you reproduce the issue with a supported Xenomai and kernel version?
>
> Jan
>
>
We have tens of thousands of legacy code so I must use Xenomai 2.6.5 - we
will endeavor to got to Xenomai 3.x next year.
Per your suggestion I could try writing a stripped-down periodic app and
booting into Xenomai 3 for a test though... I'll do that soon and let you
know how it goes.
I doubt there is anything wrong with Xenomai 2.6.5 though. My periodic
timing worked fine with 3 other motherboards and this same
Xeno kernel, but I must use this motherboard because of its form factor
(and we spent months qualifying it).

First, I am exploring what Stephane A. said above, where he suspects SMI
interference.
I did try adding xeno_hal.smi=1 to my kernel boot options, but I get this
in dmesg at boot:
  Xenomai: SMI-enabled chipset found
  Xenomai: SMI workaround failed!
So I guess I can't solve the problem that way.
My periodic timing is not fixed by this attempt either.
Note that during boot I see: "CPU0: Thermal monitoring handled by SMI"

I also ran the 'latency' regression test and it does not show large
latencies, they are <= 2.6 usec.
* Does that indicate SMI is not interrupting my process?
* Is there anything I should disable in the BIOS or kernel, like ACPI ?

Periodic timing varies across boots

[C Smith via Xenomai]

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 has been
working fine for years on several motherboards. I am able to adjust the
period of my task to within +/-10nsec, according to the frequency counter.
I can calibrate the periodic timing down to a period +/-10nsec on this
motherboard, and I cna restart my xenomai process many times and the timing
is fine. But if I cold-reboot the machine the measured period is wrong by
up to  +/-300nsec. Thus I cannot get consistent periodic timing from day to
day without recalibrating, which is unacceptable in my application.

In my kernel config, I am using the TSC: CONFIG_X86_TSC=y
I use rt_timer_read() 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

Re: [Xenomai] rthal_strncpy_from_user bug

[C Smith via Xenomai]

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 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 
wrote:

> Am Wed, 28 Sep 2016 13:12:12 +0200
> schrieb Leopold Palomo-Avellaneda :
>
> > Hi,
> >
> >
> > I'm trapped between 2.6.x and 3.x versions. The question to not
> > boring you is that I'm having a lot of problems with this soft 3.x so
> > I try to go back again to 2.6.
> >
> > However, I need to use a modern hardware (new development) and 2.6
> > have some issues especially rtnet that doesn't work without some
> > patch with kernels greater than 3.17 (or at least I'm not able to).
> >
> > After solving some other issues my tests fails with some ugly message
> > (killed)
> >
> > [ 5761.024502] RIP  []
> > rthal_strncpy_from_user+0xd/0x20 [ 5761.027017]  RSP
> >  [ 5761.029456] CR2: 0040445d
> > [ 5761.031859] ---[ end trace f092b4db2a9a9654 ]---
> > [ 5773.810428] BUG: unable to handle kernel paging request at
> > 0040445d [ 5773.812909] IP: []
> > rthal_strncpy_from_user+0xd/0x20 [ 5773.815389] PGD 45a00c067 PUD
> > 456d4e067 PMD 45aa42067 PTE 4517f5025 [ 5773.817864] Oops: 0001 [#16]
> > SMP [ 5773.820293] Modules linked in: rt_igb(O) rt_e1000e(O)
> > rt_loopback(O) rtcfg(O) rtudp(O) rtipv4(O) rtmac(O) rtpacket(O)
> > rtnet(O) ctr ccm binfmt_misc nfsd auth_rpcgss nfs_acl nfs lockd
> > fscache sunrpc nls_utf8 nls_cp437 vfat fat xeno_can_peak_pci
> > xeno_can_sja1000 xeno_can x86_pkg_temp_thermal coretemp kvm_intel kvm
> > peak_pci sja1000 joydev crc32_pclmul hid_generic usbhid
> > ghash_clmulni_intel aesni_intel ppdev aes_x86_64 lrw can_dev gf128mul
> > glue_helper xeno_rtdm snd_pcm snd_timer ablk_help
> >
> >
> > looking on the web, I have found that his issue was solved:
> >
> >
> http://git.xenomai.org/xenomai-jki.git/commit/?h=maintenance-2.6=2eceef4c62bc8d6b3713787c26882fdcd9b87842
> >
> > However, although it was on December 2015, 2.6.5 (July 2016) doesn't
> > have it.
> >
> > So, there's any reason why this patch was not pushed to 2.6.5?
>
> I guess the reason is that 2.6 is not officially maintained anymore, so
> patches like this one do not get backported. You should see if you can
> switch to 3.0 and solve your issues there!
>
> If that really is not an option, this particular problem can be
> addressed by disabling CONFIG_SMAP in your kernel. Or you could port
> the patch back to 2.6. If you do that post it here, might get accepted
> after all.
>
> Henning
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

Re: spinlock_irq...() supported in Xenomai 2.6.5 ?

[C Smith via Xenomai]

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
> > 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 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 ?
> >
>
> Neither the obsolete 2.6 (don't use it anymore!) nor current Xenomai 3 can
> perform any magic here. If your driver's IRQ routine shall run in primary
> mode,
> you need to migrate it explicitly to the RTDM API.
>
> OK, that's what I suspected. Yes my interrupts must be Primary mode (hard
RT), so should I use rtdm_lock_irqsave () and  rtdm_lock_irqrestore () as a
substitute?

Also, the old kernel driver used writel(), is that magically wrapped so it
would just become a Xenomai Primary mode call ?

We will port to Xenomai 3 in the coming year. In the meantime there are
tens of thousands of lines of code to so I must maintain our 2.6.5 code for
now. Please don't abandon discussions of 2.6, it's the stable and debugged
pinnacle of your excellent work, after all.

thanks,
-C Smith

Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

spinlock_irq...() supported in Xenomai 2.6.5 ?

[C Smith via Xenomai]

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 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

Re: [Xenomai] How to print to dmesg buffer from an RT task

[C Smith]

XDDP sockets seemed like overkill, so to work around this: I'm creating a
new message queue (RT_QUEUE) for the string transfer from the userspace RT
process to a kernelspace module (which was already running anyway). The
Xenomai API seems to say that use of this message queue will not cause my
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 no IPC
> needed.  If you'd rather send the logs to a non-RT thread and have
> that open /dev/kmsg then you can use xddp to do the IPC calls
>
> On Wed, Jun 13, 2018 at 2:57 PM, C Smith 
> wrote:
> >
> >
> > On Wed, Jun 13, 2018 at 10:35 AM, Greg Gallagher 
> > wrote:
> >>
> >> You can try to write to /dev/kmsg, but this is a Linux resource so it
> >> will impact which domain your thread is running on.
> >
> >
> > Yeah, I can't allow this task to switch to secondary mode, it is a
> > time-critical RT task.
> >
> >> AFAIK user space
> >> tasks shouldn't be logging to the kernel log for the most part.
> >
> > Well, in the past this same task used to run as a RT module in
> kernelspace,
> > so architecturally I still need that dmesg log,
> > (log files on disk are vulnerable to media problems etc).
> >
> >> One
> >> solution I've seen is to create a driver (in your case RTDM driver) to
> >> take in log messages and log them to the kernel log.
> >
> > What IPC method can I use between my RT task and the RTDM logging driver
> in
> > order to avoid a switch to secondary mode?
> > Must I use IDDP sockets ?
>
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] How to print to dmesg buffer from an RT task

[C Smith]

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 rtdm_printk() because this task isn't a kernel
module.

(I'm using Xenomai 2.6.5 on x86.)

Thanks
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

I configured BIOS so two ports shared IRQ5, and gave Linux kernel thoase
two ports with setserial:
/dev/ttyS0, UART: unknown, Port: 0x02e0, IRQ: 10
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 5
/dev/ttyS2, UART: unknown, Port: 0x03f8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 5

Using Minicom to send some bytes (sucessfully) out of port 0x02f8, IRQ5
/proc/interrupts shows one more interrupt every time I send a byte out the
port:
   CPU0   CPU1   CPU2   CPU3
  5: 26 13  1  0   IO-APIC-edge  serial

But if I subsequently take those ports away from kernel with setserial
(with no changes to BIOS) and load xeno_16550A like this:
modprobe xeno_16550A io=0x02e0,0x02f8,0x03f8,0x02e8 irq=10,5,4,5
baud_base=115200,115200,115200,115200

I get file descriptors when the ports are initialized:
successfully initialized serial device rtser1 (fd=12)   [OK]
successfully initialized serial device rtser0 (fd=13)   [OK]
successfully initialized serial device rtser2 (fd=14)   [OK]
successfully initialized serial device rtser3 (fd=15)   [OK]

But the ports which share IRQ5 can't communicate.
While the port on 0x03f8 IRQ4 can communicate 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 wrote:
> > 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 Xenomai sources.
> >
> > So I assumed you meant do do this in include/rtdm_driver.h ?
> > /* #define RTDM_IRQTYPE_EDGEXN_ISR_EDGE */   // just a test
> > #define RTDM_IRQTYPE_EDGE 0
> >
> > I  recompiled the xeno_16550A driver this way and it behaved no better. I
> > still can't get an interrupt if two serial ports share an IRQ.
> >
>
> How does /proc/interrupts look like when you have Linux driving all UARTs?
>
> Jan
>
> PS: You mail program is constantly breaking the topic threading - or you
> are not replying to the previous answers but writing new emails.
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

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 Xenomai sources.

So I assumed you meant do do this in include/rtdm_driver.h ?
/* #define RTDM_IRQTYPE_EDGEXN_ISR_EDGE */   // just a test
#define RTDM_IRQTYPE_EDGE 0

I  recompiled the xeno_16550A driver this way and it behaved no better. I
still can't get an interrupt if two serial ports share an IRQ.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

Jan Kiska wrote:
>Just like under Linux, the driver does not have to worry about that
>details. Xenomai will EOI the IRQ when needed. The driver handler just
>need to tell if a particular invocation was (also) triggered by the
>device it drives.

I trust the EOI is taken care of automatically, as you say.

However I am on a special industrial motherboard whose BIOS allows the use
of IRQ 5 for certain serial ports. There is no mistake, I chose IRQ 5 in
the BIOS (only choices are 5 and 10, but 10 conflicts with a PCI card).
Here is the kernel's dmesg at boot:
[0.536089] 00:05: ttyS1 at I/O 0x2f8 (irq = 5, base_baud = 115200) is a
16550A
Here is setserial /dev/ttyS1 after boot:
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 5

When xeno_16550A module is invoked with one of the ports on IRQ 5 like this:
xeno_16550A io=0x02e0,0x02f8,0x3f8 irq=10,5,4 baud_base=115200,115200,115200
The port at 0x02f8 IRQ 5 behaves fine and transmits and receives OK.

But when the xeno_16550A module is invoked with more than one of the ports
set to IRQ 5 in the BIOS like this:
xeno_16550A io=0x02e0,0x02f8,0x03e8,0x02e8 irq=5,5,5,5
baud_base=115200,115200,115200,115200
All those ports fail to 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 5.

-C Smith
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

I'm not familiar with the chaining of shared interrupts in the RTDM
architecture. I think the EOI should somehow be done in the very last
invocation of rt_16550_interrupt() by the last peripheral needing service.


I read this from an old interrupt handler:
(assuming IBM PC (Intel) architecture)
An interrupt handler issues an EOI by writing the value 0x20 to the PIC at
address 0x20. If the interrupt was number 8-15, do the same thing again,
write 0x20 to address 0x20.

So perhaps something like this at the end of rt_16550_interrupt() ?

if (ctx->irq_handle.irq <= 7)/* non-specific EOI to 8259 */
  rt_16550_reg_out(mode, 0, 0x20, 0x20);
if (ctx->irq_handle.irq <= 15)  /* extra EOI for upper ISA IRQs */
  rt_16550_reg_out(mode, 0, 0x20, 0x20);

But again I don't know if that will work with shared interrupts. Surely
RTDM implements some "master" handler 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

[Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

I think I may have found a bug in the rtl_16550A driver when using shared
interrupts. (I am on Xenomai 2.6.5. Kernel 3.18.20.)

I think the interrupt handler is not sending an EOI to the lower (ISA 8259)
interrupt controller, though it certainly is doing the right thing for
higher IRQs above 16.

I used a Moxa 4-port serial card in the PCI bus which has all 4 ports
sharing IRQ 17. The rtl_16550A driver can use all 4 ports OK.

But the rtl_16550A driver stalls after one interrupt when I use multiple
serial ports on my motherboard where all the serial ports share IRQ 5. This
is indicated by the fact that I can send one byte out the port, or I can
get a single byte into the port, before the port can no longer send or
receive anything further.

I diffed the Xenomai 3.0.5 source versus the 2.6.5 rtl_16550A.c source and
the code is very similar so the liability is in both branches I assume.

-C Smith
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

Update:
I installed a Moxa 4 port PCI serial card, which has a shared interrupt for
all 4 ports.
I did this:
modprobe xeno_16550A io=0xd040,0xd048,0xd050,0xd058 irq=17,17,17,17
baud_base=921600,921600,921600,921600

This worked fine, I was able to communicate bidirectionally on all four
ports 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
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

Ah OK, I recompiled the kernel so xenomai has shared interrupts now. I
thought that flag was for level-sensitive interrupts. The attached patch
may clarify this for people in the future.

But although rt_dev_open() now successfully returns a file descriptor when
opening the two serial ports (which share IRQ 5), neither of those serial
ports can communicate.
I got only a single byte into my xenomai app from one of those ports.
This seems like the kind of behavior one would get if, in the handler,
there is no re-enable of of the interrupt at the controller level. It seems
the IRQ is firing 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.bin>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

An update:
In the modprobe, I tried putting first the two ports which share IRQ 5:
modprobe xeno_16550A io=0x02f8,0x2e8,0x3f8 irq=5,5,4
results:
"successfully initialized serial device rtser1 (fd=12)
Problem setting up serial port 0 on rtser0, got: -16
successfully initialized serial device rtser2 (fd=13)"

So rt_dev_open() returns -EBUSY on the first port which shared IRQ 5

Then I tried initializing only the two ports which share IRQ 5:
modprobe xeno_16550A io=0x02f8,0x2e8 irq=5,5
results:
"successfully initialized serial device rtser1 (fd=12)
Problem setting up serial port 0 on rtser0, got: -16"

So rt_dev_open() returns -EBUSY on the first port which shared IRQ 5

I reversed the order of the two ports which share IRQ 5:
 modprobe xeno_16550A io=0x02e8,0x2f8 irq=5,5
results:
"successfully initialized serial device rtser1 (fd=12)
Problem setting up serial port 0 on rtser0, got: -16"

So again rt_dev_open() returns -EBUSY on the first port which shared IRQ 5,
even though it is a different port address now.

I recompiled the xeno_16550A driver with some printk()s in function
rt_16550_init_io() of 16550A_io.h. That function has the potential to
return -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.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[C Smith]

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) is a
16550A
[0.580306] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a
16550A
[0.601275] :00:16.3: ttyS2 at I/O 0xf0a0 (irq = 19, base_baud =
115200) is a 16550A

If I load xeno_16550A in either of these two ways below my code can use
both serial ports listed, so we know that all three ports work OK:
[root@neon ~]# modprobe xeno_16550A io=0x3f8,0x02f8 irq=4,5
[root@neon ~]# modprobe xeno_16550A io=0x3f8,0x02e8 irq=4,5

But this always fails to allow 3 ports to work:
modprobe xeno_16550A io=0x3f8,0x02f8,0x02e8  irq=4,5,5
Only the first two ports can be initialized, the third gets a "device or
resource busy", rt_dev_open() returns -16.

My code snippet is:

struct rtser_config serial_config = {
.config_mask   = 0x,
.baud_rate = 115200,
.parity= RTSER_NO_PARITY,
.data_bits = RTSER_8_BITS,
.stop_bits = RTSER_1_STOPB,
.handshake = RTSER_NO_HAND,
.fifo_depth= RTSER_DEF_FIFO_DEPTH, //RTSER_FIFO_DEPTH_8,
// I'd rather not initialize this, but compiler error if not
.reserved  = 0,
.rx_timeout= 50, /* 500 us */
.tx_timeout= RTSER_DEF_TIMEOUT,
.event_timeout = 500, /* 5 ms */
.timestamp_history = RTSER_RX_TIMESTAMP_HISTORY,
.event_mask= RTSER_EVENT_RXPEND,
};

static int fd_tty[MAX_NUM_SERIAL_PORT];   /* file descriptors for serial
ports */

/* a for() loop on port_num is here. ports are not initialized in order,
BTW. */
fd_tty[port_num] = rt_dev_open(tmpstr, O_RDWR | O_NONBLOCK);
if (fd_tty[port_num] < 0)
{
   printf("Problem setting up serial port %d on %s, got: %d\n", port_num,
tmpstr, fd_tty[port_num]);
}
else
{
   int ser_return;
   ser_return = rt_dev_ioctl(fd_tty[port_num], RTSER_RTIOC_SET_CONFIG,
_config);
   if (ser_return < 0)
   {
  printf("serial device %s initialization failed with: (%d)\n",tmpstr,
ser_return);
   }
   else if (ser_return >= 0)
   {
  printf("successfully initialized serial device rtser%d
(fd=%d)\n",port_num,fd_tty[port_num]);
   }
}

This is the output as ports get initialized:
successfully initialized serial device rtser1 (fd=12)
successfully initialized serial device rtser0 (fd=13)
Problem setting up serial port 2 on rtser2, got: -16

I tried this with serial compiled into the kernel and I took the ports away
from the kernel with 'setserial /dev/ttyS_ uart none', and also I tried
with serial as kernel modules and I removed the modules - so there was no
possibility of the kernel using the serial ports.

Is there somehow a limit of 2 ports compiled into the xeno_16550A driver ?
Or is the driver having trouble with the shared interrupt 5?

I am using Xenomai 2.6.5 on kernel 3.18.20
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Context switch to secondary mode in xenomai tasks

[C Smith]

How can we verify which tasks are switching to secondary mode? We know the
xml parser definitely is switching to secondary mode, setting T_WARNSW,
causing the application to send the SIGXCPU signal, but we don't know if
it's affecting the other tasks.

On Fri, Apr 6, 2018 at 10:17 AM, Greg Gallagher <g...@embeddedgreg.com>
wrote:

> If a tasks switches to secondary mode it would act like a normal Linux
> thread. I haven't used Xenomai 2.6 in a while but if you are seeing
> both tasks drop to secondary mode you may want to list the resources
> that they are sharing and how 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 data however they do not communicate
> directly.
> > The rt_task which parses the xml document and the main rt_task are
> running
> > periodically at different rates using rt_task_set_periodic.
> >
> > On Fri, Apr 6, 2018 at 9:54 AM, Greg Gallagher <g...@embeddedgreg.com>
> > wrote:
> >>
> >> 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
> >> > 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
> cause
> >> > a
> >> > switch to secondary mode. Would this also switch the other tasks we
> are
> >> > running to secondary mode, or is it isolated?
> >> >
> >> > We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
> >> > ___
> >> > Xenomai mailing list
> >> > Xenomai@xenomai.org
> >> > https://xenomai.org/mailman/listinfo/xenomai
> >
> >
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Context switch to secondary mode in xenomai tasks

[C Smith]

The tasks manipulate shared data however they do not communicate directly.
The rt_task which parses the xml document and the main rt_task are running
periodically at different rates using rt_task_set_periodic.

On Fri, Apr 6, 2018 at 9:54 AM, Greg Gallagher <g...@embeddedgreg.com>
wrote:

> 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
> > 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 cause
> a
> > switch to secondary mode. Would this also switch the other tasks we are
> > running to secondary mode, or is it isolated?
> >
> > We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
> > ___
> > Xenomai mailing list
> > Xenomai@xenomai.org
> > https://xenomai.org/mailman/listinfo/xenomai
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Context switch to secondary mode in xenomai tasks

[C Smith]

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 cause a
switch to secondary mode. Would this also switch the other tasks we are
running to secondary mode, or is it isolated?

We are running Xenomai 2.6.2 and Xenomai 2.6.5 in our application.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] segfault in printer_loop()

[C Smith]

Hi Jan,

I have found a workaround for the problem. Instead of the startup segfault
happening 10% of the time, I have now started my RT app 90 times with a
single RT thread, and 80 times with its original three RT threads - with no
segfaults.

Per your question: I don't think the problem is that __rt_print_init() is
getting called twice. The normal order of execution is like this:

. printer_loop() gets called first when a xenomai RT app starts up

. pthread_mutex_lock() sets the buffer_lock struct so __lock and __owner
are nonzero:
(gdb) p buffer_lock
$4 = {__data = {__lock = 1, __count = 0, __owner = 18681, __kind = 0,
__nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size =
"\001\000\000\000\000\000\000\000\371H\000\000\000\000\000\000\001\000\000\000\000\000\000",
__align = 1}

. then pthread_cond_wait() calls __rt_print_init()

. inside  __rt_print_init(), printer_wakeup has a valid __mutex:
(gdb) print printer_wakeup
$5 = {__data = {__lock = 0, __futex = 1, __total_seq = 1, __wakeup_seq = 0,
__woken_seq = 0, __mutex = 0xb7fd4a1c, __nwaiters = 2, __broadcast_seq =
0}, __size = "\000\000\000\000\001\000\000\000\001", '\000' , "\034J\375\267\002\000\000\000\000\000\000\000\000\000\000",
__align = 4294967296}

. Then continuing, we get to first line of main() OK with no segfault.

You had advised to watch for corruption of the vars pthread_cond_wait()
uses.
In contrast to the above, when the segfault occurs, the vars buffer_lock
and printer_wakeup, which get passed into pthread_cond_wait(), contain all
zeros:

(gdb) print buffer_lock
$6 = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers
= 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' , __align = 0}
(gdb) print printer_wakeup
$7 = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0,
__woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0},
__size = '\000' , __align = 0}

There is one pointer in the pthread_cond_t structure:
printer_wakeup.__data.__mutex
So perhaps pthread_cond_wait() dereferences this null mutex pointer ? The
segfault always happens on access of address 0xC.

This segfault first appeared when I compiled my app for SMP, and it goes
away if I use kernel arg maxcpus=1. Perhaps some SMP race condition is
occasionally preventing the data structures (buffer_lock,printer_wakeup)
from being ready for pthread_cond_wait()?

As a protection against this I have patched the rt_print.c printer_loop()
code, skipping the call to pthread_cond_wait() if those two structures
(buffer_lock,printer_wakeup) are not ready. There is no reason to wait on a
thread which is not locked and where the mutex is nonexistent, right?

This is the patch:

--- rt_print_A.c2014-09-24 13:57:49.0 -0700
+++ rt_print_B.c2017-11-11 23:24:34.309832301 -0800
@@ -680,9 +680,10 @@
 while (1) {
 pthread_cleanup_push(unlock, _lock);
 pthread_mutex_lock(_lock);
-
-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 this patch is safe?

thanks,
-C Smith
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] segfault in printer_loop()

[C Smith]

I finally caught all the variables in a corefile in gdb:
(gdb) bt
#0  0xb76d70db in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1  0xb76f97f4 in printer_loop (arg=0x0) at rt_print.c:685
#2  0xb76d3adf in start_thread () from /lib/libpthread.so.0
#3  0xb746444e in clone () from /lib/libc.so.6
(gdb) print printer_wakeup
$1 = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0,
__woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0},
__size = '\000' , __align = 0}
(gdb) print buffer_lock
$2 = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers
= 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' , __align = 0}
(gdb) print buffers
$3 = 4
(gdb) print arg
No symbol "arg" in current context.
(gdb) print mask
No symbol "mask" in current context.
(gdb) print unlock
$4 = {void (void *)} 0xb76f96f9 
(gdb) info threads
  Id   Target Id Frame
  2Thread 0xb73686c0 (LWP 20462) 0xe424 in ?? ()
* 1Thread 0xb76f5b40 (LWP 20464) 0xb76d70db in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib/libpthread.so.0
(gdb) print _wakeup
$5 = (pthread_cond_t *) 0xb76fda20
(gdb) print _lock
$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

Re: [Xenomai] segfault in printer_loop()

[C Smith]

One update for clarification:

The gcc command line is identical between the old xeno 2.6.2 machine
which produces a stable app,
and this new xeno 2.6.4 machine which produces segfaults in my app.
You'll notice some redundancy
in the gcc command line below, as I am using more than one skin and
calling xeno-config more than
once in the Makefile (but that has never been a problem in years of
using 2.6.2):

gcc -g3 -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__
-I/usr/include/libxml2 -I/usr/local/rtnet/include -I"SOEM/" -I"SOEM/osal"
-I"SOEM/oshw/linux" -I"SOEM/soem"-Xlinker -rpath -Xlinker /usr/xenomai/lib
app.c ../include/dia_dev_app.h ../include/crc_table.h ../include/dacdefs.h
../include/ov_version.h ../include/adcdefs.h ../include/app_version.h
../include/app.h ../include/canodefs.h ../include/preproc_app.h
../include/app_mem_manager_data.h ../include/comm_dta_app.h
../include/comproto.h
../modules/rtdinsync.h quad.o dac.o adc.o
SOEM/lib/linux/liboshw.a SOEM/lib/linux/libosal.a SOEM/lib/linux/libsoem.a
-L../lib -lapp -lnative -L/usr/xenomai/lib -lxenomai -lpthread -lrt -lrtdm
-L/usr/xenomai/lib -lxenomai -lpthread -lrt
-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 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 pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.O
#1  Oxb77347de in printer_loop (arg=Ox0) at rt_print.c:685
#2  Oxb770eadf in start thread () from /lib/libpthread.so.O
#3  Oxb749f44e in clone () from /lib/libc.so.6
(gdb) info threads
 Id  Target Id Frame
 2   Thread Oxb73a36cO (LWP 7235) Oxe424 in ?? ()
*1   Thread Oxb7730b40 (LWP 7238) Oxb77120db in pthread_cond_wait@
@GLZBC_2.3.2
() from /lib/libpthread.so.O

Note that there is no printing whatsover in my code. This is a mature
application which has been running sucessfully on xenomai 2.6.2 for a few
years - but now I am running it on xenomai 2.6.4 on kernel 3.14.17.
Another difference is that I am now using a faster motherboard. I have a
suspicion that there is a race condition which is causing uninitialized
thread variables. I believe this is during the creation of a thread where
xenomai prints the new thread info to stdout.

Could _wakeup, _lock be invalid?
I was unable to evaluate them in the debugger, I think their values are
gone from the stack/heap by the time I get to them.

There are no differences in rt_print.c between xenomai 2.6.4 and 2.6.5.

Can you provide a way to modify the code of printer_loop() to detect and
work around the problem?
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] segfault in printer_loop()

[C Smith]

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 pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.O
#1  Oxb77347de in printer_loop (arg=Ox0) at rt_print.c:685
#2  Oxb770eadf in start thread () from /lib/libpthread.so.O
#3  Oxb749f44e in clone () from /lib/libc.so.6
(gdb) info threads
 Id  Target Id Frame
 2   Thread Oxb73a36cO (LWP 7235) Oxe424 in ?? ()
*1   Thread Oxb7730b40 (LWP 7238) Oxb77120db in pthread_cond_wait@
@GLZBC_2.3.2
() from /lib/libpthread.so.O

Note that there is no printing whatsover in my code. This is a mature
application which has been running sucessfully on xenomai 2.6.2 for a few
years - but now I am running it on xenomai 2.6.4 on kernel 3.14.17.
Another difference is that I am now using a faster motherboard. I have a
suspicion that there is a race condition which is causing uninitialized
thread variables. I believe this is during the creation of a thread where
xenomai prints the new thread info to stdout.

Could _wakeup, _lock be invalid?
I was unable to evaluate them in the debugger, I think their values are
gone from the stack/heap by the time I get to them.

There are no differences in rt_print.c between xenomai 2.6.4 and 2.6.5.

Can you provide a way to modify the code of printer_loop() to detect and
work around the problem?
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] RT->nonRT communication (Xenomai 2.6.4)

[C Smith]

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 end,
they return immediately.

Then I start one or more non-RT processes that connect, either O_RDONLY or
O_WRONLY, to several of the non-RT ends of the sockets (via /dev/rtpXX).
That works well, now the RT and non-RT processes are exchanging data.

The problem comes if I run one of the non-RT processes in a debugger and
halt it (after it has connected).  The evidence is ambiguous, but usually
it seems the RT task just hangs.  Then if I continue the non-RT process,
everything becomes healthy again and messages flow.  Or, if I kill the
non-RT process, at least the RT task doesn't hang.

I haven't been able to figure out anything about the RT process when it is
"hung".  The first time I saw this today, it appeared that a socket
sendto() operation in the RT process was returning errno = ENOMEM, but I
wasn't able to reproduce it.  If I attach to the RT process in a debugger
while it is hung, I'm not able to get it to continue.  And if I start the
RT process in a debugger, then break when it hangs, I can single step
through the entire infinite loop of the RT process without problem; but
then when I continue it goes back to the hang behavior.  (One thing the
infinite loop does is increment a counter in shared memory -- I can see
this happen when I'm single stepping, but then when I continue I see from
non-RT processes that the counter in shared memory stops incrementing.)

Any ideas, either what is expected when the process on one end of an XDDP
socket is suspended, or how I could figure out what's going on in the RT
process?

Thanks for all you help so far!
Bob
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Fwd: rt_pipe_* - must link xenomai and flush the pipe

[C Smith]

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 accidentally sent this to Philippe instead of the list --
> >
> > -- Forwarded message --
> > From: C Smith <csmithquesti...@gmail.com>
> > Date: Mon, Aug 14, 2017 at 3:48 PM
> > Subject: Re: [Xenomai] rt_pipe_* - must link xenomai and flush the pipe
> > To: Philippe Gerum <r...@xenomai.org>
> >
> >
> > Thanks -- sorry I was sparse with details --
>
> - what are the parameters passed to rt_pipe_create(), rt_pipe_read() in
> the failing case? (sizes, flags etc).
>
> - what is the exact return value of write() on the non-rt side, which
> does not trigger any receipt from rt_pipe_read()?
>
> - what is the _exact_ Xenomai 2.6 release you have been using so far?
> Several bug fixes have been applied to the message pipes along the 2.6.x
> lifetime, only 2.6.5 includes them all.
>
> >
> > I am using xenomai 2.6.
>
> I would strongly recommend to use Xenomai 3.0.x instead of 2.6. The
> Xenomai 2.6.x series is not maintained anymore (EOL since January last
> year).
>
> I would also recommend to go for the POSIX interface instead of the
> so-called native/alchemy API: less overhead, more users, better
> maintenance. With Xenomai 3.x, the POSIX API is truly the "native" one,
> compared to all other APIs - include alchemy - which have to go through
> the "Copperplate" mediation layer for reaching the core real-time services.
>
> Xenomai's "alchemy" API should be seen as a compatibility layer for
> people who want to port Xenomai 2.6 applications originally implemented
> with the "native" API to Xenomai 3.x. I would NOT recommend it for new
> projects.
>
>   I am observing this behavior when a non-RT task
> > writes to the pipe using write(), and an RT task reads the pipe with
> > rt_pipe_read.  The RT task is not a kernel module, just started from an
> ELF
> > executable I run from the command line.
> >
> > BTW, linking in xenomai libraries makes a huge difference -- according to
> > gdb, when I leave xenomai libraries out (of a program with no xenomai
> calls
> > and no threading calls), the process is single-threaded; but when I link
> it
> > with -lxenomai -lpthread_rt then gdb shows two threads, even if I stop it
> > immediately by typing 'break main' before 'run'.  One of the threads
> always
> > has this call stack:
> >
> > #0  0xe424 in __kernel_vsyscall ()
> > #1  0xb7e90966 in nanosleep () from /lib/libpthread.so.0
> > #2  0xb7ea0819 in printer_loop (arg=0x0) at rt_print.c:691
> > #3  0xb7e89adf in start_thread () from /lib/libpthread.so.0
> > #4  0xb720d55e in clone () from /lib/libc.so.6
> >
>
> That is expected; this is a helper thread started from a Xenomai library
> constructor, dealing with deferred printf() output.
>
> --
> Philippe.
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] rt_pipe_* - must link xenomai and flush the pipe

[C Smith]

Today I tried to make a minimal example, but the example did not behave as
I described above.  However it did give an (important?) clue.

In the non-realtime process, I had

write(pipe_fd, "Hello", sizeof("Hello"));
write(pipe_fd, "World", sizeof("World"));

When I linked the user program with no xenomai libraries, the realtime task
that was repeatedly reading with rt_pipe_read() only saw the "Hello".  If I
let that task keep running, and ran the user task again, the realtime task
saw "Hello" again.  It never saw "World".

However, when I linked the user program with the xenomai libraries
(-lnative -L/usr/xenomai/include -lxenomai -lpthread -lrt), the realtime
task saw both "Hello" and "World".

So probably my somewhat-more-severe symptoms are due to some kind of race
condition.  I am 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 --
>
>
> -- Forwarded message --
> From: C Smith <csmithquesti...@gmail.com>
> Date: Mon, Aug 14, 2017 at 3:48 PM
> Subject: Re: [Xenomai] rt_pipe_* - must link xenomai and flush the pipe
> To: Philippe Gerum <r...@xenomai.org>
>
>
> Thanks -- sorry I was sparse with details --
>
> I am using xenomai 2.6.  I am observing this behavior when a non-RT task
> writes to the pipe using write(), and an RT task reads the pipe with
> rt_pipe_read.  The RT task is not a kernel module, just started from an ELF
> executable I run from the command line.
>
> BTW, linking in xenomai libraries makes a huge difference -- according to
> gdb, when I leave xenomai libraries out (of a program with no xenomai calls
> and no threading calls), the process is single-threaded; but when I link it
> with -lxenomai -lpthread_rt then gdb shows two threads, even if I stop it
> immediately by typing 'break main' before 'run'.  One of the threads always
> has this call stack:
>
> #0  0xe424 in __kernel_vsyscall ()
> #1  0xb7e90966 in nanosleep () from /lib/libpthread.so.0
> #2  0xb7ea0819 in printer_loop (arg=0x0) at rt_print.c:691
> #3  0xb7e89adf in start_thread () from /lib/libpthread.so.0
> #4  0xb720d55e in clone () from /lib/libc.so.6
>
> Thanks,
> Bob
>
>
> On Sun, Aug 13, 2017 at 4:11 AM, Philippe Gerum <r...@xenomai.org> wrote:
>
>> On 08/11/2017 11:59 PM, C Smith wrote:
>>
>>> 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
>>> sounds
>>> right to you folks:
>>>
>>> We are using the rt_pipe_* API.  The process that creates the realtime
>>> task
>>> creates the pipes with rt_pipe_create(), before starting the realtime
>>> task.  The names show up in /proc/xenomai/registry/native/pipes/. The
>>> non-realtime processes just use open() and write() to put data into the
>>> pipe.  The non-realtime processes can compile and run without linking
>>> against xenomai libraries.
>>>
>>> The two weird things I find are that:
>>>
>>>1) If I don't link the non-realtime processes against xenomai
>>> libraries,
>>> the non-realtime process can write to the pipe without error, but the
>>> realtime process never sees anything that it wrote; and
>>>
>>>
>> Strange indeed. Linking is not expected to make any difference; using
>> pipes on the non-rt side only depends on regular Linux I/O services tapping
>> into a pseudo-device the real-time core exposes (just like RTLinux).
>>
>>2) Even with xenomai linked in, the non-realtime task must flush the
>>> pipe
>>> (ioctl(fd, XNPIPEIOC_IFLUSH, 0); or else the realtime task never sees
>>> anything they wrote.
>>>
>>> I've tried this with both blocking and non-blocking rt_pipe_read().
>>>
>>>
>> - Which Xenomai version are you using?
>> - Is the reader in userland?
>> - How does the reader pull data from the pipe, using which call and
>> syntax precisely?
>>
>> PS: although this should not be related to the issue, it is worth
>> mentioning that RTLinux fifos were a byte-oriented mechanism; Xenomai pipes
>> keep message boundaries on both sides by default, which means that each
>> write() is normally paired with one read() on the remote side, with all
>> data conveyed as a single bulk. There is a way to switch to byte-oriented
>> mode in the rt -> non-rt direction though.
>>
>> --
>> Philippe.
>>
>
>
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] rt_pipe_* - must link xenomai and flush the pipe

[C Smith]

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 sounds
right to you folks:

We are using the rt_pipe_* API.  The process that creates the realtime task
creates the pipes with rt_pipe_create(), before starting the realtime
task.  The names show up in /proc/xenomai/registry/native/pipes/. The
non-realtime processes just use open() and write() to put data into the
pipe.  The non-realtime processes can compile and run without linking
against xenomai libraries.

The two weird things I find are that:

  1) If I don't link the non-realtime processes against xenomai libraries,
the non-realtime process can write to the pipe without error, but the
realtime process never sees anything that it wrote; and

  2) Even with xenomai linked in, the non-realtime task must flush the pipe
(ioctl(fd, XNPIPEIOC_IFLUSH, 0); or else the realtime task never sees
anything they wrote.

I've tried this with both blocking and non-blocking rt_pipe_read().

I'd appreciate your thoughts,
Bob
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] non-blocking IDDP (xenomai 2.6.4)

[C Smith]

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 is running, the server
successfully receives the packet from the client; but if no client is
running, the server's call to recvfrom() blocks forever.

I'm confused among the various ways of making connections non-blocking -- I
have tried the following:

 . According to the linux manpage for socket(), this should work:
   s = socket(...,type|SOCK_NONBLOCK,...)
   but with AF_RTIPC,SOCK_DGRAM socket() throws error "Address family not
supported by protocol"

 . fcntl:
   int flags = fcntl(s,F_GETFL,0);
   fcntl(s, F_SETFL, flags | O_NONBLOCK);
   However, the first call to fcntl throws an error, "Bad file descriptor"
(the file descriptor returned from socket() is 896, which is unusual).

 . setsockopt:
   I have seen some examples on the internet (with other socket types) of
calling:
   setsockopt(s,level,SO_NONBLOCK,,sizeof(int))
   however, I think this is non-standard -- I cannot find a definition of
SO_NONBLOCK on my linux 3.4.6/xenomai 2.6.4 machine.

Can anyone tell me how to make recvfrom non-blocking on an IDDP socket?

Thanks!
csmith
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Question regarding rt_dev_socket()

[C Smith]

Hello,

I have an existing Xenomai 2.6.4 application. I'm now developing a second
Xenomai application that is to run at the same time as the existing one.
They need to communicate, so I'm investigating IPC mechanisms:

I added the following lines to the existing application. However, the
return value of the call to rt_dev_socket() always fails (returns -97,
address family not supported).

 #include 
 #include 
 err = rt_dev_socket(PF_RTIPC, SOCK_DGRAM, IPCPROTO_BUFP);

Is the return value indicative of a kernel that needs to be reconfigured?
Must there be a device driver 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
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Unable to Read from Pipe

[C Smith]

That code snippet explains it well, and my tests confirm the principle. I
no longer lose bytes when I open() with O_SYNC flag, write(),  and close()
shortly thereafter.I don't think you need to make the close() call wait
until the rt input is fully consumed.

This man page is clear on the expected 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 3.0rc5, which is also present in in xenomai 2.6.4.
 
  The problem is that if the userspace writer of a pipe closes the pipe
  immediately after writing, the data does not get into the pipe reliably
 and
  the real-time reader process usually doesn't get the data. This is true
  even though the write() returns the expected number of bytes indicating
  success.
 

 This is intended. We must allow the regular side to force a shutdown on
 the pipe since this is a valid use case, which would not be possible if
 waiting for the rt input to drain was the only option before the kernel
 actually closes the channel.

 O_SYNC can be passed to open() to have the writer wait for the rt side
 to start consuming the messages on the other end. In addition, we could
 make the close() call wait until the rt input is fully consumed with
 O_SYNC too, which is not the case so far (we currently sync on write()
 only). This patch has been scrupulously untested.

 diff --git a/ksrc/nucleus/pipe.c b/ksrc/nucleus/pipe.c
 index df587ab..5367c4c 100644
 --- a/ksrc/nucleus/pipe.c
 +++ b/ksrc/nucleus/pipe.c
 @@ -697,6 +697,14 @@ static int xnpipe_release(struct inode *inode,
 struct file *file)

 xnlock_get_irqsave(nklock, s);

 +   if ((file-f_flags  O_SYNC) != 0  !emptyq_p(state-inq)) {
 +   if (xnpipe_wait(state, XNPIPE_USER_WSYNC, s,
 +   emptyq_p(state-inq))) {
 +   xnlock_put_irqrestore(nklock, s);
 +   return -ERESTARTSYS;
 +   }
 +   }
 +
 xnpipe_dequeue_all(state, XNPIPE_USER_WREAD);
 xnpipe_dequeue_all(state, XNPIPE_USER_WSYNC);

 --
 Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
http://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Unable to Read from Pipe

[C Smith]

I found a workaround for this, but I believe it illustrates a bug in
xenomai 3.0rc5, which is also present in in xenomai 2.6.4.

The problem is that if the userspace writer of a pipe closes the pipe
immediately after writing, the data does not get into the pipe reliably and
the real-time reader process usually doesn't get the data. This is true
even though the write() returns the expected number of bytes indicating
success.

The workaround is to add a usleep in the writer process and wait until the
data gets into the pipe before closing the pipe. The critical time period
in my tests seems to be about .5 seconds, if less than that there is often
data loss.

Here is my new userspace pipe-write.c :

 fd = open(/dev/rtp0, O_WRONLY);
printf(open returned file descriptor: %d\n, fd);

wr = write(fd, Debug, sizeof(Debug));
printf(Write call retuned: %d\n, wr);

usleep(50);   //This sleep makes the write reliable
//usleep(125000);   //This one is very unreliable

if (fd  0)
   close(fd);

This code succeeds but the usleep() is just an open-loop guess as to how
long to wait before close().

Is there any way to verify that bytes have been written 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
 getting the exact same error in the periodic task which attempts a
 nonblocking read of a pipe: errno 11 -EWOULDBLOCK, and no bytes are ever
 transferred across the pipe.

 It seems unlikely that the Pipe API has been broken across Xenomai 2.6.2,
 2.6.4 and 3.0rc5.
 So perhaps there is something wrong with my code or the way I compile the
 apps?

 The gcc command line for the periodic task is this:
 gcc -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -D_GNU_SOURCE
 -D_REENTRANT -D__COBALT__ -I/usr/xenomai/include/alchemy -Xlinker
 -rpath -Xlinker /usr/xenomai/lib  pipe-read.c
 -Wl,@/usr/xenomai/lib/cobalt.wrappers
 /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
 -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -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, 2015 at 10:54 AM, Gilles Chanteperdrix 
 gilles.chanteperd...@xenomai.org wrote:

 On Wed, Jul 01, 2015 at 10:44:53AM -0700, C Smith wrote:
  I tried xenomai stable 2.6.4 on a 3.14.17 kernel today. I get the same
  result,

 What about the other tests? Xenomai testing? and XDDP sockets?

  the rt task pipe read results in errno 11 -EWOULDBLOCK.  Here is a clue:
  a blocking read in the periodic task works OK and reads the bytes from
 the
  pipe - but I can't allow my periodic thread to block.
 
  The nonblocking pipe API should work in xenomai 2.6.4, right? Perhaps
 there
  is something I'm doing wrong in my code or my compile?
  I have attached my test code for you to look at, in case I am doing
  something wrong.

 There is no doubt that it should be working. But maybe it does not,
 and understanding why would be a waste of time if it has been fixed
 in Xenomai testing.

 Please stay on the lit.
 --
 Gilles.
 https://click-hack.org



___
Xenomai mailing list
Xenomai@xenomai.org
http://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Unable to Read from Pipe

[C Smith]

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
getting the exact same error in the periodic task which attempts a
nonblocking read of a pipe: errno 11 -EWOULDBLOCK, and no bytes are ever
transferred across the pipe.

It seems unlikely that the Pipe API has been broken across Xenomai 2.6.2,
2.6.4 and 3.0rc5.
So perhaps there is something wrong with my code or the way I compile the
apps?

The gcc command line for the periodic task is this:
gcc -I/usr/xenomai/include/cobalt -I/usr/xenomai/include -D_GNU_SOURCE
-D_REENTRANT -D__COBALT__ -I/usr/xenomai/include/alchemy -Xlinker
-rpath -Xlinker /usr/xenomai/lib  pipe-read.c
-Wl,@/usr/xenomai/lib/cobalt.wrappers
/usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -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, 2015 at 10:54 AM, Gilles Chanteperdrix 
gilles.chanteperd...@xenomai.org wrote:

 On Wed, Jul 01, 2015 at 10:44:53AM -0700, C Smith wrote:
  I tried xenomai stable 2.6.4 on a 3.14.17 kernel today. I get the same
  result,

 What about the other tests? Xenomai testing? and XDDP sockets?

  the rt task pipe read results in errno 11 -EWOULDBLOCK.  Here is a clue:
  a blocking read in the periodic task works OK and reads the bytes from
 the
  pipe - but I can't allow my periodic thread to block.
 
  The nonblocking pipe API should work in xenomai 2.6.4, right? Perhaps
 there
  is something I'm doing wrong in my code or my compile?
  I have attached my test code for you to look at, in case I am doing
  something wrong.

 There is no doubt that it should be working. But maybe it does not,
 and understanding why would be a waste of time if it has been fixed
 in Xenomai testing.

 Please stay on the lit.
 --
 Gilles.
 https://click-hack.org

-- next part --
A non-text attachment was scrubbed...
Name: pipe-write.c
Type: text/x-csrc
Size: 395 bytes
Desc: not available
URL: 
http://xenomai.org/pipermail/xenomai/attachments/20150702/60eda063/attachment.c
-- next part --
A non-text attachment was scrubbed...
Name: pipe-read.c
Type: text/x-csrc
Size: 3254 bytes
Desc: not available
URL: 
http://xenomai.org/pipermail/xenomai/attachments/20150702/60eda063/attachment-0001.c
___
Xenomai mailing list
Xenomai@xenomai.org
http://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Unable to Read from Pipe

[C Smith]

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 read the pipe:
errno 11 -EWOULDBLOCK and the bytes the userspace app sent never arrive
at the Xenomai task.

The Xenomai task creates the pipe this way:

ret = rt_pipe_create(cmd_fifo_fd, cmd_fifo, 0, 30);

The userspace app opens and writes to the pipe this way:

fd = open(/dev/rtp0, O_RDWR);
wr = write(fd, Debug, sizeof(Debug));

The Xenomai task becomes periodic like this:

 ret = rt_task_create(main_task, mytask, 0, 99, T_FPU | T_JOINABLE);
 ret = rt_task_start(main_task, Periodic_routine, NULL);

Each time the Xenomai periodic task 'wakes', it checks the pipe in a
non-blocking fashion (this is a requirement).
Here is most of the periodic code which reads the pipe:

void Periodic_routine(void *cookie) {
   RTIME next;
   rt_task_set_mode(0, T_WARNSW, NULL);
   next = rt_timer_read();
   while (1)   {
  next += 20;
  retval = rt_task_sleep_until(next);
  retval = rt_pipe_read(cmd_fifo_fd, msg, 6, TM_NONBLOCK);
   }
}

Yet the rt_pipe_read() above always returns errno 11 -EWOULDBLOCK and never
gets any bytes from the pipe, no matter how many times the periodic task
wakes up.

-CSmith
___
Xenomai mailing list
Xenomai@xenomai.org
http://xenomai.org/mailman/listinfo/xenomai