Re: [Xenomai] RT serial cross-link failure

[Jan Kiszka <jan.kiszka@siemens.com>]

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.

> 
> Here is the content of the corresponding ioctl in the driver:
> .
> .
>         case RTSER_RTIOC_WAIT_EVENT: {
>                 struct rtser_event ev = { .rxpend_timestamp = 0 };
>                 rtdm_toseq_t timeout_seq;
> 
>                 if (!rtdm_in_rt_context())
>                         return -ENOSYS;
> 
>                 /* Only one waiter allowed, stop any further attempts here. */
>                 if (test_and_set_bit(0, &ctx->ioc_event_lock))
>                         return -EBUSY;
> 
>                 rtdm_toseq_init(&timeout_seq, ctx->config.event_timeout);
> 
>                 rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
> 
>                 while (!ctx->ioc_events) {
>                         /* Only enable error interrupt
>                            when the user waits for it. */
>                         if (ctx->config.event_mask & RTSER_EVENT_ERRPEND) {
>                                 ctx->ier_status |= IER_STAT;
> #ifdef FIXME
>                                 rt_imx_uart_reg_out(mode, base, IER,
>                                                  ctx->ier_status);
> #endif
>                         }
> 
>                         rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> 
>                         err = rtdm_event_timedwait(&ctx->ioc_event,
>                                                    ctx->config.event_timeout,
>                                                    &timeout_seq);
>                         if (err) {
>                                 /* Device has been closed? */
>                                 if (err == -EIDRM)
>                                         err = -EBADF;
>                                 goto wait_unlock_out;
>                         }
> 
>                         rtdm_lock_get_irqsave(&ctx->lock, lock_ctx);
>                 }
> 
>                 ev.events = ctx->ioc_events;
>                 ctx->ioc_events &=
>                     ~(RTSER_EVENT_MODEMHI | RTSER_EVENT_MODEMLO);
> 
>                 ev.last_timestamp = ctx->last_timestamp;
>                 ev.rx_pending = ctx->in_npend;
> 
>                 if (ctx->in_history)
>                         ev.rxpend_timestamp = ctx->in_history[ctx->in_head];
> 
>                 rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx);
> 
>                 if (rtdm_fd_is_user(fd))
>                         err =
>                             rtdm_safe_copy_to_user(fd, arg, &ev,
>                                                    sizeof(struct
>                                                           rtser_event));
>                         else
>                                 memcpy(arg, &ev, sizeof(struct rtser_event));
> 
> wait_unlock_out:
>                 /* release the simple event waiter lock */
>                 clear_bit(0, &ctx->ioc_event_lock);
>                 break;
>         }
> .
> .
> 
> So either rtdm_event_timedwait or rtdm_safe_copy_to_user is returing -EPERM.

Or things terminate earlier / later in the ioctl dispatching path.

> Looking at the documentation rtdm_safe_copy_to_user does not appear to return -EPERM.
> 
> Looking at the documentation rtdm_event_timedwait:
> -EPERM may be returned if an illegal invocation environment is detected.
> 
> So are we stuck in secondary mode?

Probably.

> Ideas?

You will not get around debugging more information out of your setup.
Use tracing, use well-placed printk.

Jan

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