Re: RTAI 3.8.1 - BUG: scheduling while atomic

I'm unable to realize a picture of your framework.
For example, when you say kthread do you mean a linux kthread or an RTAI 
one, or how can a soft rtai task in user space call down()?

Moreover, at as far as I know, but it can be not so much, down/up is for 
semaphores and mutexes are exactly not the same. So if a linux kernel 
sem has to be substituted it should through an RTAI sem.

In any case if the problem is related to an inappropriate interaction of 
soft RTAI enabled tasks I'd try to see what happen by making the low 
prio RTAI task using linux hard, letting it switch back and forth Linux 
as needed.

Paolo

On 02/08/2018 11:22 PM, Graeme Foot wrote:
>
> Hi,
>
> I'm adding some functionality to an old system (yes it's old but I'm 
> not updating it yet):
>
> - Linux 2.6.32.11
>
> - RTAI 3.8.1
>
> - Beckhoff CX2020 PC (single core Celeron)
>
> I have a third party kernel module (Etherlab's EtherCAT master) which 
> runs a kthread with "struct semaphore" locking.  My application is 
> running in user space using LXRT and an RTDM interface to access the 
> EtherCAT functions.  My application has a hard rtai task thread and a 
> soft rtai task thread.
>
> - The hard rtai task thread calls EtherCAT functions that do not use 
> any "struct semaphore" locks (priority 50).
>
> - The soft rtai task thread calls EtherCAT functions that do use 
> "struct semaphore" locks (priority 0).
>
> After a time (10 minutes to 1 hour) I am getting the following kernel bug:
>
> [  373.990904] BUG: scheduling while atomic: kmc/988/0x00000200
>
> [  374.000014] Modules linked in: ec_e1000 ec_e1000e ec_cx2100 
> ec_master rtai_s
>
> hm rtai_msg rtai_mbx rtai_rtdm rtai_sem rtai_lxrt rtai_hal
>
> [  374.019325]
>
> [  374.028624] Pid: 988, comm: kmc Not tainted 
> (2.6.32.11-kmc-rtai-3.8.1 #1) CX
>
> 2020-0100
>
> [  374.038308] EIP: 0060:[<c011643f>] EFLAGS: 00003282 CPU: 0
>
> [  374.047931] EIP is at ipipe_critical_exit+0x5d/0x60
>
> [  374.057342] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
>
> [  374.066927] ESI: 00000000 EDI: 00000000 EBP: dec5fe1c ESP: c2002a90
>
> [  374.076260]  DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068
>
> [  374.085493] CR0: 8005003b CR2: b765d6b0 CR3: 1ee11000 CR4: 000406d0
>
> [  374.094878] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>
> [  374.104062] DR6: ffff0ff0 DR7: 00000400
>
> [  374.113062] Call Trace:
>
> [  374.122082]  [<c0146aa2>] ? ktime_get_real+0x0/0x29
>
> [  374.131009]  [<c0146987>] ? ktime_get+0x0/0x88
>
> There's not much of a call stack, but through logging I have 
> determined this occurs when the soft rtai task thread is calling 
> down() on a semaphore within the EtherCAT module.  After it occurs the 
> /proc/rtai/scheduler output shows the soft rtai task with a State of 
> 0x0, and the thread is no longer functioning.
>
> My understanding is that a soft rtai task could call any Linux 
> function and be pre-empted by other rtai tasks.  The above looks like 
> soft tasks may still have a problem with atomic operations.
>
> Do you know if there is a fix for this (maintaining my Linux and RTAI 
> versions)?  Is it a problem with current RTAI versions?
>
> One option I'm investigating is to change the EtherCAT modules locks 
> to RTAI rt_mutex… (from rtai_sem.h).  However, from what I understand 
> the rt_mutex_lock() call won't block when used by the EtherCAT modules 
> kthread.  Is this correct?  If so, there is a showroom example 
> "kern\rsmfromlnxitr" that makes a kthread into a soft rtai task.  
> Should I use this method for the EtherCAT kthreads?
>
> Alternatively, would Linux's rt_mutex… function calls solve the above 
> problem?
>
> Regards,
>
> Graeme Foot.
>
>
>
> _______________________________________________
> Rtai mailing list
> [email protected]
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai

_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai