[etherlab-users] System randomly freezes in multi-thread Qt application with a RT process

[Simone Comari]

Hi all,

I am a young research fellow at the university of Bologna and I just started working with EtherCAT technology and RT systems yet, so please forgive me if I misuse words or I'm not precise enough.

First, I'll try to describe my setup:

  *   Ubuntu 16.04.6 with patched fully preemptible RT kernel 4.13.13-rt5
  *   Qt 5.12.2
  *   PCI driver e1000e
  *   Ethercat master running on this Linux RT
  *   Elmo GOLD SOLO WHISTLE Drives (ethercat slaves)

Secondly, a brief outline of my software architecture:

  *   POSIX threads
  *   Qt-based GUI running on a non-RT thread
  *   Ethercat network setup (ethercat master and slaves init) done in the same non-RT thread
  *   If initialization is successful, start a new RT-thread in charge of handling all ethercat-related functionalities (read/write/status-check).
  *   Shared resources between RT and non-RT ones handled with pthread_mutex (even if I'm not 100% sure I'm using it correctly)
  *   Implementation of our generic ethercat master can be found here<https://github.com/UNIBO-GRABLab/grab_common/blob/e5278b6fe611654bfa84c951d8b77e56ebbc8fa9/libgrabec/src/ethercatmaster.cpp>

Problem description:

  *   Once the ethercat network is setup and the RT thread is started, quite randomly the system freezes without errors of any sorts. Sometimes it happens when motors are enabled and operational, sometimes when they are enabled and idle, sometimes even if they are disabled. It is not reproducible and I couldn't link it to any particular step in my application. Sometimes it happens even if I simply start it, but always after successful initialization.
  *   Even when I manage to close the application, next time I try to run it it tells me that master is busy and ec_e1000e is in use. Only solution is to manually hard-shut-down the PC.
  *   Other thing I noticed is that even if the main thread (the GUI one, so non-RT) is closed, the child RT-thread stays running with status D  (uninterruptible sleep) blocking a great deal of CPU (that is why probably the whole system freezes).
  *   We tried with different computers (both laptop and desktop) to exclude a platform's dependency, but the issue remains.

Please let me know if there is any missing important information that can help understanding the problem.
Thank you a lot for the support.

Best regards,
Simone

____________________________________________________

SIMONE COMARI

Research Fellow
DIN – Dept. of Industrial Engineering
Alma Mater Studiorum –  University of Bologna
Via Umberto Terracini, 24, 40131 Bologna (BO), Italy

E-mail: simone.comari2 at unibo.it<mailto:simone.comari2 at unibo.it>
Websites:
<http://www.unibo.it/docenti/marco.carricato>https://www.unibo.it/sitoweb/simone.comari2
http://grab.diem.unibo.it<http://grab.diem.unibo.it/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20190522/cb331a65/attachment-0002.htm>