Re: [Xenomai] RT serial cross-link failure

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Mon, Feb 22, 2016 at 01:46:18PM -0600, Michael Welling wrote:
> On Mon, Feb 22, 2016 at 08:22:08PM +0100, Gilles Chanteperdrix wrote:
> > On Mon, Feb 22, 2016 at 08:16:20PM +0100, Jan Kiszka wrote:
> > > On 2016-02-22 20:04, Michael Welling wrote:
> > > > On Mon, Feb 22, 2016 at 07:05:44PM +0100, Jan Kiszka wrote:
> > > >> On 2016-02-22 18:53, Michael Welling wrote:
> > > >>> On Thu, Feb 18, 2016 at 10:10:48AM -0600, Michael Welling wrote:
> > > >>>> On Thu, Feb 18, 2016 at 08:30:40AM +0100, Wolfgang Netbal wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>> Am 2016-02-18 um 08:10 schrieb Michael Welling:
> > > >>>>>> On Thu, Feb 18, 2016 at 08:02:48AM +0100, Wolfgang Netbal wrote:
> > > >>>>>>>
> > > >>>>>>> Am 2016-02-16 um 18:58 schrieb Michael Welling:
> > > >>>>>>>> On Tue, Feb 16, 2016 at 06:39:50AM +0100, Wolfgang Netbal wrote:
> > > >>>>>>>>> Am 2016-02-15 um 18:41 schrieb Michael Welling:
> > > >>>>>>>>>> I took the time to update the IMX UART driver such that it registers with the 3.18 kernel.
> > > >>>>>>>>>>
> > > >>>>>>>>>> The driver appears to register correctly and the /dev/rtdm/rtser* nodes appear.
> > > >>>>>>>>>>
> > > >>>>>>>>>> When I run the cross-link demo the system hangs after an error in read_task.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Here is the output that I get:
> > > >>>>>>>>>> main : write-file opened
> > > >>>>>>>>>> main : write-config written
> > > >>>>>>>>>> main : read-file opened
> > > >>>>>>>>>> main : read-config written
> > > >>>>>>>>>> main : write-task created
> > > >>>>>>>>>> main : read-task created
> > > >>>>>>>>>> main : starting write-task
> > > >>>>>>>>>> main : strating read-task
> > > >>>>>>>>>>  Nr |   write-irq    |    irq->read    |   write->read   |
> > > >>>>>>>>>> ----------------------------------------------------------
> > > >>>>>>>>>> read_task: error on RTSER_RTIOC_WAIT_EVENT, Operation no permitted
> > > >>>>>>>>>> main : /dev/rtdm/rtser1 (read) -> closed
> > > >>>>>>>>>> read_task: exit
> > > >>>>>>>>>>
> > > >>>>>>>>>> Any ideas why this would happen?
> > > >>>>>>>>>>
> > > >>>>>>>>>> I can provide the patch for the driver if necessary. I tried to keep the changes to a minimal.
> > > >>>>>>>>> Dear Michael,
> > > >>>>>>>>>
> > > >>>>>>>>> I added a patch on December where I extended the IMX UART driver to support
> > > >>>>>>>>> open firmware, maybe my patch can help you to find your issue.
> > > >>>>>>>>> I posted the patch in the mailing list, you can find it here
> > > >>>>>>>>> https://xenomai.org/pipermail/xenomai/2015-December/035655.html
> > > >>>>>>>>>
> > > >>>>>>>>> Kind regards
> > > >>>>>>>>> Wolfgang
> > > >>>>>>> Sorry Michael,
> > > >>>>>>>
> > > >>>>>>> My patch working for xenomai 2.6.4 file ksrc/drivers/serial/rt_imx_uart.c
> > > >>>>>> I am pretty sure that there is another patch applied previous.
> > > >>>>>>
> > > >>>>>> If you look at your patch you see German comments and open firmware code that
> > > >>>>>> is obviously not in the v2.6.4 on the git repository.
> > > >>>>>>
> > > >>>>>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/serial/rt_imx_uart.c?h=v2.6.4
> > > >>>>>>
> > > >>>>> I posted my patch, because I thought that Wolfgang Grandegger the author of
> > > >>>>> the driver may check it and include it to the xenomai if it is useable for
> > > >>>>> other users.
> > > >>>>>
> > > >>>>
> > > >>>> Yes but the patch does not apply to the driver in the source tree.
> > > >>>> Please provide the driver that you have after the patch.
> > > >>>
> > > >>> Any ideas out there?
> > > >>>
> > > >>
> > > >> Are you now referring to the incomplete patch or your original problem
> > > >> again?
> > > > 
> > > > The original problem is my primary concern. I would not mind having another
> > > > version of the driver to test against as well.
> > > > 
> > > >>
> > > >> For the latter case, I would recommend debugging the error code, ie.
> > > >> what threw this at you. In Xenomai context, -EPERM often means that the
> > > >> caller is requesting some (potentially) blocking service without being a
> > > >> real-time task. But, of course, also the driver itself may decide to
> > > >> raise this for whatever reasons.
> > > > 
> > > > Here is the snippet of code from the user app that concerns me:
> > > > .
> > > > .
> > > >         printf(" Nr |   write->irq    |    irq->read    |   write->read   |\n");
> > > >         printf("-----------------------------------------------------------\n");
> > > > 
> > > >         /*
> > > >          * We are in secondary mode now due to printf, the next
> > > >          * blocking Xenomai or driver call will switch us back
> > > >          * (here: RTSER_RTIOC_WAIT_EVENT).
> > > >          */
> > > > 
> > > >         while (1) {
> > > >                 /* waiting for event */
> > > >                 err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
> > > > .
> > > > .
> > > > 
> > > > So is the comment no longer true with Xenomai 3?
> > > 
> > > No, that would be a bug.
> > 
> > The part of the comment which says that printf causes a switch to
> > secondary mode has been wrong for some time now. printf is wrapped
> > and stays in primary mode.
> > 
> > Can not the problem be that the thread is not auto-shadowed?
> 
> How would I go about determining if this is the case?

Load the program in gdb, put a breakpoint on __wrap_ioctl, run the
program. When it stops, in another terminal see if your program
appears in /proc/xenomai/sched or /proc/xenomai/stat.

-- 
					    Gilles.
https://click-hack.org