[mythtv] deadlocks when "use real-time threads" enabled in mythfrontend
Peter Bennett
pb.mythtv at gmail.com
Sat Dec 30 19:00:11 UTC 2017
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
More information about the mythtv-dev
mailing list