|
Bugzilla – Full Text Bug Listing |
| Summary: | Intel Broxton: vdpau via libvdpau-va-gl+vaapi not working | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Hubert Mantel <mantel> |
| Component: | X.Org | Assignee: | Max Staudt <mstaudt> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | mantel, mstaudt |
| Version: | Leap 42.2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
lspci of affected machine
dmesg X server log of latest startup X server log after adding the new PCI ID glxinfo for working server |
||
|
Description
Hubert Mantel
2016-11-20 13:30:50 UTC
*** Bug 1011161 has been marked as a duplicate of this bug. *** *** Bug 1011162 has been marked as a duplicate of this bug. *** *** Bug 1011163 has been marked as a duplicate of this bug. *** *** Bug 1011164 has been marked as a duplicate of this bug. *** (In reply to Hubert Mantel from comment #0) > The funny thing is that mplayer seems to work just fine when giving the > option "-vo vdpau". According to its output it is indeed using vdpau. Unfortunately xine does not work and vdr is using xineliboutput. So mplayer cannot be used as workaround *** Bug 1011165 has been marked as a duplicate of this bug. *** Max, could you have a look into this? "Intel Corporation Device 5a85" appears to be "HD Graphics 500" aka Broxton. This is latest Celeron based graphics currently available. I'm afraid we don't have hardware available for reproduction. On Intel platforms, VDPAU is implemented using a third-party wrapper, libvdpau-va-gl, as the Intel driver only provide the VA interface. Pure output without hardware decoding is pretty much bound to work, as the wrapper implements video output via OpenGL. It's when it comes to hardware decoding that problems sometimes arise, but in your case, we don't even get there: The issues are in the VA layer. libva can't even recognize your GPU by itself. Can you please check whether the i915 driver in the kernel is working properly with your system? Maybe post a dump of dmesg? On my Ivy Bridge test system, mpv can play videos with "-vo=vaapi -hwdec=vaapi" just fine on Tumbleweed. This is independent of whether xf86-video-intel is installed or not. Please also run "vainfo" (package vaapi-tools) and provide the output. vdr:~ # export DISPLAY=:0 vdr:~ # vainfo libva info: VA-API version 0.39.3 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) vaInitialize failed with error code -1 (unknown libva error),exit vdr:~ # ps ax | grep i915 367 ? S 0:00 [i915/signal:0] 368 ? S 0:00 [i915/signal:1] 369 ? S 0:00 [i915/signal:2] 370 ? S 0:00 [i915/signal:4] 15550 pts/0 S+ 0:00 grep --color=auto i915 vdr:~ # lsmod | grep i915 i915 1413120 3 i2c_algo_bit 16384 1 i915 drm_kms_helper 176128 1 i915 drm 393216 4 i915,drm_kms_helper video 45056 1 i915 button 16384 1 i915 Trying to play a video via mpv is something I can only to tonight. But at least mplayer seems to be happy to consume the parameter "-vo vdpau". How else can I check that "i915 driver in the kernel is working properly"? Created attachment 702940 [details]
dmesg
For me this looks good. But I'm not an expert:
[ 3.651574] [drm] Initialized drm 1.1.0 20060810
[ 3.712224] [drm] Memory usable by graphics device = 4096M
[ 3.712229] fb: switching to inteldrmfb from VESA VGA
[ 3.713444] [drm] Replacing VGA console driver
[ 3.713616] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 3.713617] [drm] Driver supports precise vblank timestamp query.
[ 3.716820] [drm] Finished loading i915/bxt_dmc_ver1_07.bin (v1.7)
[ 4.704811] [drm] failed to retrieve link info, disabling eDP
[ 4.707294] [drm] GuC firmware load skipped
[ 4.714989] [drm] Initialized i915 1.6.0 20160711 for 0000:00:02.0 on minor 0
[ 5.231607] fbcon: inteldrmfb (fb0) is primary device
[ 5.341075] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 5.859742] [drm] RC6 on
Btw, I just stumbled about this one: https://bugs.freedesktop.org/show_bug.cgi?id=97077 Maybe I should simply try these boot parameters: "i915.enable_guc_loading=2 i915.enable_guc_submission=2" (In reply to Hubert Mantel from comment #10) > vdr:~ # export DISPLAY=:0 > vdr:~ # vainfo > libva info: VA-API version 0.39.3 > libva info: va_getDriverName() returns -1 > libva error: va_getDriverName() failed with unknown libva > error,driver_name=(null) > vaInitialize failed with error code -1 (unknown libva error),exit Please set here LIBVA_DRIVER_NAME=i965 as well. Just for fun I added the kernel parameters and rebooted the system. Here are the kernel messages: [ 4.636410] [drm] failed to retrieve link info, disabling eDP [ 4.636770] i915 0000:00:02.0: Direct firmware load for i915/bxt_guc_ver8_7.bin failed with error -2 [ 4.636825] [drm:intel_guc_init [i915]] *ERROR* Failed to fetch GuC firmware from i915/bxt_guc_ver8_7.bin (error -2) [ 4.639063] [drm:intel_guc_setup [i915]] *ERROR* GuC firmware load failed: -5 [ 4.639106] [drm:intel_guc_setup [i915]] *ERROR* GuC init failed: -5 [ 4.639144] [drm:i915_gem_init [i915]] *ERROR* Failed to initialize GPU, declaring it wedged And indeed, there is no bxt_guc_ver8_7.bin file. Several people on the internet are reporting the very same problem. Unfortunately I cannot find this binary only file anywhere. Seems I got once more screwed by choosing Intel "Linux-supported" hardware. Should have gone with AMD as Torsten Duwe suggested :( (In reply to Stefan Dirsch from comment #13) > (In reply to Hubert Mantel from comment #10) > > vdr:~ # export DISPLAY=:0 > > vdr:~ # vainfo > > libva info: VA-API version 0.39.3 > > libva info: va_getDriverName() returns -1 > > libva error: va_getDriverName() failed with unknown libva > > error,driver_name=(null) > > vaInitialize failed with error code -1 (unknown libva error),exit > > Please set here LIBVA_DRIVER_NAME=i965 as well. vdr:~ # export LIBVA_DRIVER_NAME=i965 vdr:~ # vainfo libva info: VA-API version 0.39.3 libva info: va_getDriverName() returns -1 libva info: User requested driver 'i965' libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 vainfo: intel_driver.c:100: intel_driver_init: Assertion `VA_CHECK_DRM_AUTH_TYPE(ctx, VA_DRM_AUTH_DRI1) || VA_CHECK_DRM_AUTH_TYPE(ctx, VA_DRM_AUTH_DRI2) || VA_CHECK_DRM_AUTH_TYPE(ctx, VA_DRM_AUTH_CUSTOM)' failed. Abgebrochen (core dumped) vdr:~ # If I understand correctly. the whole issue is the fact that the hardware is very new and Intel has not yet released the matching firmware. Is this correct? If so, feel free to close this bug as INVALID or WONTFIX (like other distributions are doing). Or do you have contact to Intel to help them speed up releasing this needed firmware? https://bugs.freedesktop.org/show_bug.cgi?id=97825#c2 Hubert, Takashi believes that the guc firmware for Broxton is optional. Only the dmc firmware is required. On 42.2 I found: /lib/firmware/i915/bxt_dmc_ver1.bin /lib/firmware/i915/bxt_dmc_ver1_04.bin /lib/firmware/i915/bxt_dmc_ver1_05.bin /lib/firmware/i915/bxt_dmc_ver1_06.bin I can't understand why mplayer works with vdpau backend. Could it be that it does a fallback to a different backend, after vdpau this fails? For example with no VA driver in place I see in mplayer output: [VS] Software VDPAU backend library initialized libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/r600_drv_video.so libva info: va_openDriver() returns -1 Trying to run it from remote... vdr:/video/data/Terra X # l /lib/firmware/i915/ total 428 drwxr-xr-x 2 root root 4096 Nov 21 14:04 ./ drwxr-xr-x 76 root root 12288 Nov 19 17:38 ../ -rw-r--r-- 1 root root 8380 Okt 5 19:30 bxt_dmc_ver1_07.bin lrwxrwxrwx 1 root root 19 Okt 5 19:30 bxt_dmc_ver1.bin -> bxt_dmc_ver1_07.bin -rw-r--r-- 1 root root 8616 Okt 5 19:30 kbl_dmc_ver1_01.bin lrwxrwxrwx 1 root root 19 Okt 5 19:30 kbl_dmc_ver1.bin -> kbl_dmc_ver1_01.bin -rw-r--r-- 1 root root 8824 Okt 5 19:30 skl_dmc_ver1_23.bin -rw-r--r-- 1 root root 8928 Okt 5 19:30 skl_dmc_ver1_26.bin lrwxrwxrwx 1 root root 19 Okt 5 19:30 skl_dmc_ver1.bin -> skl_dmc_ver1_26.bin -rw-r--r-- 1 root root 109636 Okt 5 19:30 skl_guc_ver1.bin -rw-r--r-- 1 root root 128320 Okt 5 19:30 skl_guc_ver4.bin -rw-r--r-- 1 root root 129024 Okt 5 19:30 skl_guc_ver6_1.bin lrwxrwxrwx 1 root root 18 Okt 5 19:30 skl_guc_ver6.bin -> skl_guc_ver6_1.bin vdr:/video/data/Terra X # mplayer -vo vdpau 20151224\ 1527\ -\ zdf_neo\ HD\ -\ Terra\ X.ts MPlayer -6 (C) 2000-2015 MPlayer Team mplayer: could not open config files /root/.lircrc and /etc/lirc/lircrc mplayer: No such file or directory Failed to read LIRC config file ~/.lircrc. Playing 20151224 1527 - zdf_neo HD - Terra X.ts. libavformat version 57.56.100 (external) TS file format detected. VIDEO H264(pid=6310) AUDIO MPA(pid=6321) SUB Teletext(pid=6330) PROGRAM N. 11130 FPS seems to be: 50.000000 Load subtitles in ./ libva info: VA-API version 0.39.3 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 57.64.100 (external) Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== ========================================================================== Trying to force audio codec driver family libmad... Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) ========================================================================== AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [vdpau] 1280x720 => 1280x720 Planar YV12 [zoom] A:30375.0 V:30376.1 A-V: -1.121 ct: -0.002 3/ 3 ??% ??% ??,?% 2 0 [h264 @ 0x7f9887188b60]Increasing reorder buffer to 2 A:30376.2 V:30377.4 A-V: -1.206 ct: -0.122 65/ 65 62% 42% 0.8% 18 0 MPlayer interrupted by signal 2 in module: sleep_timer function is no-op.4 A-V: -1.224 ct: -0.124 66/ 66 61% 42% 0.8% 18 0 Exiting... (Quit) The output "VO: [vdpau]" for me indicates that it is indeed using it. But I was not really able to watch the movie from the office... (In reply to Stefan Dirsch from comment #18) > I can't understand why mplayer works with vdpau backend. Could it be that it > does a fallback to a different backend, after vdpau this fails? See Comment 8: "Pure output without hardware decoding is pretty much bound to work, as the wrapper implements video output via OpenGL." It doesn't use VA for drawing, just for decoding. (In reply to Hubert Mantel from comment #19) > Trying to run it from remote... > > vdr:/video/data/Terra X # l /lib/firmware/i915/ > -rw-r--r-- 1 root root 8380 Okt 5 19:30 bxt_dmc_ver1_07.bin > lrwxrwxrwx 1 root root 19 Okt 5 19:30 bxt_dmc_ver1.bin -> > bxt_dmc_ver1_07.bin So required firmware does exist. > vdr:/video/data/Terra X # mplayer -vo vdpau 20151224\ 1527\ -\ zdf_neo\ HD\ > -\ Terra\ X.ts > MPlayer -6 (C) 2000-2015 MPlayer Team > mplayer: could not open config files /root/.lircrc and /etc/lirc/lircrc > mplayer: No such file or directory > Failed to read LIRC config file ~/.lircrc. > > Playing 20151224 1527 - zdf_neo HD - Terra X.ts. > libavformat version 57.56.100 (external) > TS file format detected. > VIDEO H264(pid=6310) AUDIO MPA(pid=6321) SUB Teletext(pid=6330) PROGRAM N. > 11130 > FPS seems to be: 50.000000 > Load subtitles in ./ > libva info: VA-API version 0.39.3 > libva info: va_getDriverName() returns -1 > libva error: va_getDriverName() failed with unknown libva > error,driver_name=(null) So it fails exactly the same way as it does with vdpauinfo, vainfo. Some fallback is used I'm pretty sure. At least now we have a consistent picture. ;-) vdr:~ # vainfo --display drm
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 1.7.2
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
vdr:~ #
So vainfo works meanwhile. What did you change? I did not change anything at all. Just searched the web and found people having the exact same problem. vainfo still fails as before: vdr:~ # vainfo libva info: VA-API version 0.39.3 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) vaInitialize failed with error code -1 (unknown libva error),exit vdr:~ # It only works when using the parameter "--display drm" : vdr:~ # vainfo --display drm libva info: VA-API version 0.39.3 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.39 (libva 1.7.2) vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 1.7.2 vainfo: Supported profile and entrypoints So I just wanted to report this additional data point. System is completely unchanged since last week. Can you please try the current development packages on your system? https://build.opensuse.org/package/show/X11:XOrg/libva https://build.opensuse.org/package/show/X11:XOrg/vaapi-intel-driver If that doesn't work, I can still try to build packages for the latest release, 1.7.3. Or, you can build them yourself if you wish: https://www.freedesktop.org/software/vaapi/releases/ With 1.7.3 I get exactly the same behaviour:
vdr:~ # vainfo
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
vaInitialize failed with error code -1 (unknown libva error),exit
vdr:~ # vainfo --display drm
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 1.7.2
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
vdr:~ #
However Intel Broxton driver still reports version 1.7.2
After fiddling around I finally succeeded updating the vaapi-intel-driver to 1.7.3 as well. Unfortunately no change in behaviour:
vdr:~ # vainfo
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
vaInitialize failed with error code -1 (unknown libva error),exit
vdr:~ # vainfo --display drm
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 1.7.3
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
[...]
Unfortunately you still need to set LIBVA_DRIVER_NAME=i965 manually. Created attachment 704266 [details]
X server log of latest startup
As requested.
I've patched the X server 1.18.4 that is currently in Factory to include your PCI ID 0x8086/0x5a85: https://build.opensuse.org/package/show/home:mstaudt:branches:openSUSE:Factory/xorg-x11-server Can you please test this version? If it still does not work, add Mesa 13.0.2 from X11:XOrg : https://build.opensuse.org/package/show/X11:XOrg/Mesa As soon as xorg-x11-server 1.19.0 and mesa 13.0.2 are are accepted from X11:XOrg into openSUSE:Factory, your device will be supported by default. You're my hero:
vdr:~ # vainfo
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 1.7.3
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
[...]
I only updated the X server. Mesa is still at installation level. Did a short test with mplayer and xine and things seem to look fine!
Thanks!
Cool! Let's close this ticket then. Just for us, as a reference: Can you please attach a recent /var/log/Xorg.0.log and glxinfo so we can see what state the system is in after only updating the X server? Created attachment 704299 [details]
X server log after adding the new PCI ID
X server log from successful startup. As for the glxinfo: I do not have such a command and have no idea which package might contain it.
[ 12078.479] (II) modeset(0): [DRI2] Setup complete [ 12078.479] (II) modeset(0): [DRI2] DRI driver: i965 [ 12078.479] (II) modeset(0): [DRI2] VDPAU driver: i965 Looks good now! Before: [ 87.416] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x8086 / 0x5a85 [ 87.416] (EE) modeset(0): Failed to initialize the DRI2 extension. glxinfo -> package Mesa-demo-x Created attachment 704356 [details]
glxinfo for working server
glxinfo output looks also good. Mesa's DRI2 driver is active. Seems it is still not completely solved. When trying to use vdpau, I get this error: vo_vdpau: Failed to check vdpau get/put bits native capability : VDP_STATUS_NO_IMPLEMENTATION Funnily enough, I just tried "opengl" as driver and this seems to work!? Seems like xine and the VDPAU wrapper don't get along. OpenGL output sounds right for using VAAPI acceleration natively. If it works and you're happy with whatever CPU usage there is, then you should use the direct interfaces. No need for an extra wrapper, whether it works or not. To clarify: You have an Intel GPU, and its native interface is not VDPAU, but VAAPI. Since xine supports VAAPI natively starting in version 1.2.6 (which was already included in Leap 42.1), you can and should ignore its VDPAU support. Please stop using xine's VDPAU output on this machine. Submitted the PCI IDs for Leap 42.2: https://build.opensuse.org/request/show/445133 Factory now has xorg-x11-server 1.19.0, which ships the new Broxton IDs by default. openSUSE-RU-2016:3240-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1011158 CVE References: Sources used: openSUSE Leap 42.2 (src): xorg-x11-server-7.6_1.18.3-7.1 As I wanted to clean things up I re-installed the machine and hoped it now would work out of the box. But it seems meanwhile some new issue has been introduced. vainfo now again prints: vdr:~ # vainfo libva info: VA-API version 0.39.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) vaInitialize failed with error code -1 (unknown libva error),exit It seems for some reason loading of the firmware now fails according to the kernel logs: [ 2.954989] [drm] Memory usable by graphics device = 4096M [ 2.955096] [drm:finish_csr_load [i915]] *ERROR* Unknown stepping info, firmware loading failed [ 2.956951] checking generic (80000000 8d0000) vs hw (80000000 10000000) [ 2.956954] fb: switching to inteldrmfb from VESA VGA The firmware load problems seems to be the root cause of the problem now: vdr:~ # intel_watermark unknown chip 0x5a85 vdr:~ # intel_gpu_frequency No intel gpu found SKIP (-1.000s) vdr:~ # On my workstation: Terra:/usr/bin # intel_gpu_frequency cur: 350 MHz min: 350 MHz RP1: 650 MHz max: 1150 MHz Terra:/usr/bin # (In reply to Hubert Mantel from comment #19) > vdr:/video/data/Terra X # l /lib/firmware/i915/ > total 428 > drwxr-xr-x 2 root root 4096 Nov 21 14:04 ./ > drwxr-xr-x 76 root root 12288 Nov 19 17:38 ../ > -rw-r--r-- 1 root root 8380 Okt 5 19:30 bxt_dmc_ver1_07.bin > lrwxrwxrwx 1 root root 19 Okt 5 19:30 bxt_dmc_ver1.bin -> > bxt_dmc_ver1_07.bin After the new install, ver1_07 does no longer exist: vdr:/lib/firmware/i915 # l bxt* -rw-r--r-- 1 root root 5872 16. Mai 2016 bxt_dmc_ver1_04.bin -rw-r--r-- 1 root root 5872 16. Mai 2016 bxt_dmc_ver1_05.bin -rw-r--r-- 1 root root 8380 16. Mai 2016 bxt_dmc_ver1_06.bin lrwxrwxrwx 1 root root 19 13. Mai 14:41 bxt_dmc_ver1.bin -> bxt_dmc_ver1_06.bin vdr:/lib/firmware/i915 # Maybe this is the problem?? With firmware bxt_dmc_ver1_07.bin the problem still exists: [ 3.163081] [drm:finish_csr_load [i915]] *ERROR* Unknown stepping info, firmware loading failed However, I stumbled over this posting which indicates that this could be a kernel problem: https://askubuntu.com/questions/873109/unknown-stepping-info-firmware-loading-failed "I don't know why, but my upgrade from 16.04 to 16.10 left me with an unchanged kernel, the problematic 4.4 from Ubuntu 16.04. According to my recent reading, the stepping info problem and freezing of Intel CPU's (that have embedded HD graphics) is/was an issue through kernel 4.5, fixed in 4.6+. A fresh install of 16.10 gave me kernel 4.8, and it has been stable for days. My take-away lesson is that to solve this problem, get kernel 4.6+. One way is to install a stable 16.10+ version fresh from bootable media (an incremental upgrade might not suffice)" I'm currently running the most recent kernel: vdr:~ # uname -a Linux vdr 4.4.72-18.12-default #1 SMP Mon Jun 19 14:11:41 UTC 2017 (9c03296) x86_64 x86_64 x86_64 GNU/Linux vdr:~ # But this still is one from the 4.4 series... With a new kernel, the firmware loading finally succeeds, but problem still present: vdr:~ # uname -a Linux vdr 4.11.7-1.gddd09a5-default #1 SMP PREEMPT Sat Jun 24 07:54:41 UTC 2017 (ddd09a5) x86_64 x86_64 x86_64 GNU/Linux vdr:~ # vainfo libva info: VA-API version 0.39.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) vaInitialize failed with error code -1 (unknown libva error),exit vdr:~ # dmesg | grep drm [ 3.410370] [drm] Memory usable by graphics device = 4096M [ 3.410377] fb: switching to inteldrmfb from VESA VGA [ 3.411542] [drm] Replacing VGA console driver [ 3.411885] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 3.411886] [drm] Driver supports precise vblank timestamp query. [ 3.413344] [drm] Finished loading DMC firmware i915/bxt_dmc_ver1_07.bin (v1.7) [ 3.417433] [drm] GuC firmware load skipped [ 3.417973] [drm] Initialized i915 1.6.0 20170123 for 0000:00:02.0 on minor 0 [ 3.696244] fbcon: inteldrmfb (fb0) is primary device [ 3.784393] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 4.835484] [drm] RC6 on vdr:~ # Maybe I should re-install 42.1 instead of 42.2 and ask for a patched X Server that supports the chip. It was working quite nicely end of last year... I no longer remember the details, but I'm afraid you still set LIBVA_DRIVER_NAME=i965 as a minimum. Leap 42.2/sle12-sp2 hasn't seen a fundamental graphics stack update (at least no Xserver update). So you may need to do something similar as in comment #30, i.e. at least update xorg-x11-server of X11:XOrg. I don't know which patch Max added. His repo is gone meanwhile and he is on sick leave until begin of July. And yes, Leap 42.3 will likely be affected by that issue as well. (In reply to Stefan Dirsch from comment #49) > I no longer remember the details, but I'm afraid you still set > > LIBVA_DRIVER_NAME=i965 > > as a minimum. Leap 42.2/sle12-sp2 hasn't seen a fundamental graphics stack > update > (at least no Xserver update). So you may need to do something similar as in > comment #30, i.e. at least update xorg-x11-server of X11:XOrg. I don't know > which patch Max added. His repo is gone meanwhile and he is on sick leave > until begin of July. I forgot to mention: I tried explicitly setting this environment variable, but it just leads to the core dump as before. But thanks for the hint with the updated X server. Will try this tonight. I tried to use the one from Max's home project, but unfortunately it is gone. But even if this will solve my problem, some questions remain: 1. Why don't we have the most recent firmware version any longer? 2. Why can't the kernel correctly load the firmware? This has worked before and seems to be fixed again in a more recent kernel. Of course using this newer kernel is totally acceptable for me and if the patched X server solved the problem, I'm fine. But there still seems to be something fishy at least in the currently available official kernel then. But I understand this is not a problem of the X guys then :) Thanks a lot for your quick answer! (In reply to Stefan Dirsch from comment #49) > I no longer remember the details, but I'm afraid you still set > > LIBVA_DRIVER_NAME=i965 > > as a minimum. Leap 42.2/sle12-sp2 hasn't seen a fundamental graphics stack > update > (at least no Xserver update). So you may need to do something similar as in > comment #30, i.e. at least update xorg-x11-server of X11:XOrg. I don't know > which patch Max added. His repo is gone meanwhile and he is on sick leave > until begin of July. I just double-checked again (did that already at home) and the X server changelog shows this entry: * Fri Dec 09 2016 mstaudt@suse.com - U_dri2-Sync-i965_pci_ids.h-from-mesa.patch Update Intel PCI IDs for modesetting to include Broxton 2x6. Fixes (boo#1011158). This is addressing this very bug, so are you sure this is the problem? Indeed, apparently Max added the patch to Leap 42.2 updates. So this is likely not the problem. Now I'm wondering, which distribution you were using, when we got it working. Originally the bug was opened against Tumbleweed ... I believe we also updated libva/vaapi-intel-driver at this time. So very likely Tumbleweed or components from TW at this time respectively, were much newer than what we still have in Leap 42.2. (In reply to Stefan Dirsch from comment #53) > I believe we also updated libva/vaapi-intel-driver at this time. So very > likely Tumbleweed or components from TW at this time respectively, were much > newer than what we still have in Leap 42.2. Ok, this would make sense then. Honestly I do not know which exact version I had been using back in december. I was under the impression that it was a beta of 42.2, but it could very well have been tumbleweed as well. Thanks for the hint. I will test with tumbleweed as soon as possible (probably in the weekend) and report back then. So no more action required from you right now :) (In reply to Hubert Mantel from comment #54) > Ok, this would make sense then. Honestly I do not know which exact version I > had been using back in december. I was under the impression that it was a > beta of 42.2, but it could very well have been tumbleweed as well. Btw, I think you are right and I tested with tumbleweed in december. I just checked the kernel-firmware package and it already has the new version 1.07. Since I never tampered with it, this is a very strong indication that it indeed was not 42.2 I tested before. Was not aware that tumbleweed is that much newer than leap :) I'm quite confident things will work fine with the new version again. Thanks a lot! Ok, I installed tumbleweed but unfortunately the vainfo tool seems not to be available any longer :( I installed everything that looked promising, but I failed to find the tool. Searching the internet, I found several documents stating that the tool is available in package "vaapi-tools", but it seems this package also has been dropped. Sigh. Giving up for now. Maybe tomorrow I will try to compile the tool myself. What is the reason for dropping such an important, tiny diagnosis tool? Finally it works! I was able to find the vainfo tool here: https://www.rpmfind.net/linux/rpm2html/search.php?query=vaapi-tools It installs just fine and prints success: vdr:/tmp # vainfo libva info: VA-API version 0.40.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_40 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.40 (libva 1.2.1) vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 1.8.1 vainfo: Supported profile and entrypoints VAProfileNone : VAEntrypointVideoProc VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : <unknown entrypoint> VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : <unknown entrypoint> VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: <unknown entrypoint> vdr:/tmp # But please re-add the package vaapi-tools. I was not able to find it anywhere in the build service :( Seems vainfo is now built from libva-utils sources/source package. Looks like this has never been submitted to factory. :-( Just did this now. Request: #506340 submit: X11:XOrg/libva-utils@4 -> openSUSE:Factory Message: splitted upstream, hence also splitted downstream; formerly known as vaapi-tools ... (In reply to Stefan Dirsch from comment #58) > Seems vainfo is now built from libva-utils sources/source package. Looks > like this has never been submitted to factory. :-( Glad to hear this was not intentional. Thanks for fixing! |