RTAI 3.8.1 - BUG: scheduling while atomic
Graeme Foot <[email protected]> Thu, 8 Feb 2018 22:22:36 +0000
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <[email protected]> |
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