Greetings,
I am running MythTV 0.31 [v31.0-165-g5d6f06cc3a-dirty] on Fedora 35. The frontend is configured to use VAAPI2, and logging reports:
VAAPIInterop: Created VAAPI 1.13 display for VAAPI DRM (Intel i965 driver for Intel(R) Gemini Lake - 2.4.1)
This has worked flawlessly for years, but after the kernel upgraded from 5.18.19-100 to 5.19.6-100, playback shows garbled video and often ends in a green screen. When you stop playback, the MythTV UI displays just fine. Just reverting to the previous kernel solves the issue.
I have since tried kernel versions 5.19.7-100 and 5.19.8-100 5.19.8-100, hoping it would contain a fix, but the problem remains. The kernel log shows errors like:
Sep 17 12:45:05 tux kernel: i915 0000:00:02.0: [drm] Resetting vecs0 for preemption time out
Sep 17 12:45:05 tux kernel: i915 0000:00:02.0: [drm] mythfrontend[1048] context reset due to GPU hang
Sep 17 12:45:05 tux kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:8:cff8ffef, in mythfrontend [1048]
Sep 17 12:45:06 tux kernel: i915 0000:00:02.0: [drm] Resetting vcs0 for CS error
Sep 17 12:45:06 tux kernel: i915 0000:00:02.0: [drm] mythfrontend[1048] context reset due to GPU hang
Sep 17 12:45:06 tux kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:4:cbfcffe7, in mythfrontend [1048]
Sep 17 12:46:06 tux kernel: Asynchronous wait on fence 0000:00:02.0:mythfrontend[1048]:a7c timed out (hint:intel_atomic_commit_ready [i915])
Sep 17 12:46:07 tux kernel: i915 0000:00:02.0: [drm] Resetting vecs0 for preemption time out
Switching playback from VAAPI2 to OpenGL avoids the problem, at the obvious cost of much higher CPU use, so it's VAAPI specific.
Is anyone else experiencing this issue? Any suggestion where to report this?
Thanks in advance for any suggestions on trying to get this solved.
Kind regards,
- Richard.
VAAPI2 playback broken after upgrading kernel to 5.19
Moderator: Forum Moderators
Re: VAAPI2 playback broken after upgrading kernel to 5.19
Richard,
If you can recompile kernel - you may try:
https://github.com/warpme/minimyth2/blo ... tive.patch
If you can recompile kernel - you may try:
https://github.com/warpme/minimyth2/blo ... tive.patch
Re: VAAPI2 playback broken after upgrading kernel to 5.19
I should be able to do that (already recompiling a kernel module to add IR support to the Hauppauge QuadHD card), so I'll give this a try and report back!
Thanks for the quick suggestion
- Richard.
Re: VAAPI2 playback broken after upgrading kernel to 5.19
Hello again. The patch applied fine:
Code: Select all
Applying patch
patching file drivers/gpu/drm/i915/i915_vma.c
Hunk #1 succeeded at 1870 (offset -12 lines).
Code: Select all
[root@tux i915]# uname -a
Linux tux 5.19.8-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 8 19:23:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[root@tux i915]# pwd
/usr/lib/modules/5.19.8-100.fc35.x86_64/kernel/drivers/gpu/drm/i915
[root@tux i915]# ls -l
total 2380
-rw-r--r-- 1 root root 1005032 Sep 17 14:44 i915.ko.xz
-rw-r--r-- 1 root root 1129956 Sep 8 13:23 i915.ko.xz.org
-rw-r--r-- 1 root root 118532 Sep 17 14:44 kvmgt.ko.xz
-rw-r--r-- 1 root root 176548 Sep 8 13:23 kvmgt.ko.xz.org
[root@tux i915]#
Kind regards,
- Richard.
Re: VAAPI2 playback broken after upgrading kernel to 5.19
FYI: I reported the issue on Intel's Github (/intel-vaapi-driver/issues/554)
Re: VAAPI2 playback broken after upgrading kernel to 5.19
Richard,
If you have still issue then my hypotheses are:
1.there is unknown bug in your sw. stack
2.patch i proposed is not enough for yours sw. stack.
If yours frontend is standalone frontend - you may try bootable USB key with current mythtv master:
https://github.com/warpme/minimyth2/releases
instructions: https://github.com/warpme/minimyth2/wik ... 2#overview
This is quite pure upstream sw.stack (5.19.9 kernel, 22.2.0-rc3 mesa, etc) - so this may help us answer where to look for root cause...
If you have still issue then my hypotheses are:
1.there is unknown bug in your sw. stack
2.patch i proposed is not enough for yours sw. stack.
If yours frontend is standalone frontend - you may try bootable USB key with current mythtv master:
https://github.com/warpme/minimyth2/releases
instructions: https://github.com/warpme/minimyth2/wik ... 2#overview
This is quite pure upstream sw.stack (5.19.9 kernel, 22.2.0-rc3 mesa, etc) - so this may help us answer where to look for root cause...
Re: VAAPI2 playback broken after upgrading kernel to 5.19
Piotr,warpme wrote: ↑Sun Sep 18, 2022 6:50 pmRichard,
If you have still issue then my hypotheses are:
1.there is unknown bug in your sw. stack
2.patch i proposed is not enough for yours sw. stack.
If yours frontend is standalone frontend - you may try bootable USB key with current mythtv master:
https://github.com/warpme/minimyth2/releases
instructions: https://github.com/warpme/minimyth2/wik ... 2#overview
This is quite pure upstream sw.stack (5.19.9 kernel, 22.2.0-rc3 mesa, etc) - so this may help us answer where to look for root cause...
Thanks for the feedback. I'm guessing the issue is likely a sw/hw mix affecting the type of GPU I'm using. There are other issues where developers report it only affects certain GPUs (which aren't all available to the developers making, it harder to regressions). There aren't any bites yet on the i915 defect that was submitted, but someone confirmed seeing the same issue so I'm hoping that Nirmoy & co will consider looking at it.
My frontend is standalone, so I'll consider the USB test you proposed if I can find some time. If I can make that work I'll report back if the issue is still there, as that would confirm the problem is related to the GPU hardware.
Kind regards,
- Richard.
Re: VAAPI2 playback broken after upgrading kernel to 5.19
This issue was resolved after upgrading the kernel to 5.19.13-100 (Fedora 35).
The same system update also included new Intel GPU firmware (intel-gpu-firmware-20220815-139.fc35.noarch), but reverting back to kernel 5.19.10-100 while leaving the newer firmware reintroduce the issued, so the problem does appear to have been fixed by the kernel+kmod combo.
The same system update also included new Intel GPU firmware (intel-gpu-firmware-20220815-139.fc35.noarch), but reverting back to kernel 5.19.10-100 while leaving the newer firmware reintroduce the issued, so the problem does appear to have been fixed by the kernel+kmod combo.