Receiving "Operation Not Permitted" when setting RTCAN_RTIOC_RCV_TIMEOUT and reading from CAN over cobalt pthread

Josh Karch jkarch at
Thu Jul 2 18:49:04 CEST 2020

From: Jan Kiszka <jan.kiszka at>
Sent: Wednesday, July 1, 2020 9:43 PM
To: Josh Karch <jkarch at>; xenomai at <xenomai at>
Subject: Re: Receiving "Operation Not Permitted" when setting RTCAN_RTIOC_RCV_TIMEOUT and reading from CAN over cobalt pthread

On 01.07.20 16:55, Josh Karch via Xenomai wrote:
> Hello,
> So a quick update, I was able to get the CAN drivers working, the issue as was suggested is that Linux did not register the interrupts for the Zynq, and I had to make a fake "generic-uio" module in the device tree to receive a valid IRQ number, and now the CAN core registers properly.
> Now, I'm trying to create an application using the POSIX skin, based on the rtcanrecv.c example.  Rather than using rt_task_shadow, I'm using pthread_create.  My Makefile uses xeno-config with --skin=posix and sets --cflags and --ldflags, while wrap-link uses the POSIX ldflags. We are using libcobalt.
> When I don't set the timeout IOCTL, my application runs, but it blocks indefinitely until messages are received, however when I set the IOCTL (0.1 sec)
> ret = ioctl(can_fd, RTCAN_RTIOC_RCV_TIMEOUT, &timeout);
> then make the read in my pthread
> ret = recvfrom(can_fd, (void *)&can_msg_frame, sizeof(can_frame_t), 0,
>                                   (struct sockaddr *)&can_address, &address_length);
> I receive -EPERM rather than -ETIMEDOUT as a return.  The application is run as root, and works normally unless the TIMEOUT ioctl above is triggered;  thoughts on where to look?
> Here are the lines of interest for the Makefile:
> CFLAGS := $(shell $(DESTDIR)$(XENO_DIR)/$(XENO_CONFIG) --skin=posix --cflags)
> LDFLAGS := $(shell $(DESTDIR)$(XENO_DIR)/$(XENO_CONFIG) --skin=posix --ldflags)
> $(CC) -c  $(PROGNAME).c $(CFLAGS)
> My guess is if I make the application run as an rt_task it would work.
> Are there any special parameters needed to be set for pthread_create in order to run in RT mode?

If wrapping is worked fine (check the symbols that your application is
actually calling: __wrap_ioctl? Also __wrap_socket?), you do not need
special parameters to the thread creation, also SCHED_OTHER threads will
be able to RTDM drivers then.

Besides that offline check, you can also look if that thread shows up
/proc/xenomai/sched/threads while it is existing.


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

Hi Jan,  looks like two things were going on:  (1) I did not set the pthread to operate in the primary domain.  I went back and looked at the xddp example.  (2) this is a fat fingered mistake, I was looking at ret vs errno.  The timeout was actually occuring, but since I looked at ret rather than errno I misinterpreted it as "operation not permitted!"

Thank you!

More information about the Xenomai mailing list