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