[mythtv] deadlocks when "use real-time threads" enabled in mythfrontend

[Peter Bennett]

On 12/28/2017 07:03 PM, Piotr Oniszczuk wrote:
> Peter,
>
> I’m wonder Your opinion:
>
> Recently I enabled „use real-time threads” in mythtv config and started to have frequent system hangs (complete UI stale; sometimes whole system becomes non-responsive).
>
> I looked via TOP utility how myth allocates priorities to threads and discover that:
>
> -after startup all is OK (all threads are prio=0)
>
> -first playback gives one thread starting to have prio=-83. all others have prio=0
>
> -exiting first playback leaves mythfrontend process with few threads with prio=-34
>
>    PID  PR USER      NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>     10  RT root       0     0    0    0 S    0  0.0   0:00.02 migration/0
>     13  RT root       0     0    0    0 S    0  0.0   0:00.01 migration/1
>     18  RT root       0     0    0    0 S    0  0.0   0:00.01 migration/2
>     23  RT root       0     0    0    0 S    0  0.0   0:00.02 migration/3
> 23429 -34 minimyth   0 6345m 616m 137m S    2 15.6   0:19.86 mythfrontend
> 24241 -34 minimyth   0 6345m 616m 137m S    0 15.6   0:00.02 SignalingTimer
>      4   0 root     -20     0    0    0 I    0  0.0   0:00.00 kworker/0:0H
>
> -entering playback again gives now bunch of threads with prio=-34
>
>    PID  PR USER      NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>     10  RT root       0     0    0    0 S    0  0.0   0:00.02 migration/0
>     13  RT root       0     0    0    0 S    0  0.0   0:00.01 migration/1
>     18  RT root       0     0    0    0 S    0  0.0   0:00.01 migration/2
>     23  RT root       0     0    0    0 S    0  0.0   0:00.02 migration/3
> 23429 -83 minimyth   0 6392m 636m 144m S    2 16.1   0:23.25 mythfrontend
> 24523 -34 minimyth   0 6392m 636m 144m S    0 16.1   0:00.00 TVBrowseHelper
> 24529 -34 minimyth   0 6392m 636m 144m S    0 16.1   0:00.09 MythSocketThrea
> 24530 -34 minimyth   0 6392m 636m 144m S    1 16.1   0:00.42 MythSocketThrea
> 24533 -34 minimyth   0 6392m 636m 144m S    1 16.1   0:00.09 RingBuffer
> 24542 -34 minimyth   0 6392m 636m 144m S    0 16.1   0:00.01 AudioOutputBase
> 24546 -34 minimyth   0 6392m 636m 144m S    6 16.1   0:00.78 Decoder
>      4   0 root     -20     0    0    0 I    0  0.0   0:00.00 kworker/0:0H
>
> -after some normal playback/exit cycles, I started to have growing set of zombie threads with prio=-34 & -83 when frontend is in idle:
>
>     PID  PR USER      NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>     10  RT root       0     0    0    0 S    0  0.0   0:00.02 migration/0
>     13  RT root       0     0    0    0 S    0  0.0   0:00.01 migration/1
>     18  RT root       0     0    0    0 S    0  0.0   0:00.02 migration/2
>     23  RT root       0     0    0    0 S    0  0.0   0:00.02 migration/3
> 27650 -83 minimyth   0 6365m 638m 141m S    0 16.1   0:00.01 PT13
> 27651 -83 minimyth   0 6365m 638m 141m S    0 16.1   0:00.00 PT14
> 27652 -83 minimyth   0 6365m 638m 141m S    0 16.1   0:00.00 PT15
> 27653 -83 minimyth   0 6365m 638m 141m S    0 16.1   0:00.00 PT16
> 27654 -83 minimyth   0 6365m 638m 141m S    0 16.1   0:00.00 PT17
> 27655 -83 minimyth   0 6365m 638m 141m S    0 16.1   0:00.00 PT18
> 23429 -34 minimyth   0 6365m 638m 141m S    2 16.1   0:51.32 mythfrontend
> 27505 -34 minimyth   0 6365m 638m 141m S    0 16.1   0:00.00 PT11
> 27510 -34 minimyth   0 6365m 638m 141m S    0 16.1   0:00.00 PT12
> 27806 -34 minimyth   0 6365m 638m 141m S    0 16.1   0:00.02 SignalingTimer
>      4   0 root     -20     0    0    0 I    0  0.0   0:00.00 kworker/0:0H
>
> (pls see: now we have PT8/9/20 alt the time siting with priority -34)
>
> Why after playback exit frontend leaves any thread with prio different than 0?
>
> All tests are on: current myth master, minimyth2 OS, ION2 with 4.14.8 kernel and Nvidia 340.104
>
>
>
>   
>
>
I set rtprio 50 in the /etc/security/limits.conf file as per the wiki.

I see similar things to you. I see priority of -2 and -34, I do not see 
-83. The more times going into playback, the more threads have priority 
-34. It looks like a bug in resetting the priority after the end of a 
playback.

Peter