Description of problem: When a program requires OpenGL libraries the desktop become unresponsive. This happened after last update. Version-Release number of selected component (if applicable): How reproducible: Use a program that output using OpenGL. Steps to Reproduce: 1. launch vlc with video output OpenGL 2. play a video Actual results: Desktop hangs Expected results: Play of video file Additional info: If video output is XCB or X11 the video is played as expected. Also other softwares free the desktop, eg Google Chrome or Remmina.
I've tried downgrading packages: mesa-libEGL mesa-libGL mesa-libOSMesa mesa-libglapi But the problem persists. Also musescore (mscore) isn't working, program and desktop hangs during startup
The problem is with kernel version 5.7.7. I'm using now version 5.6.19 and I have no bugs.
(In reply to Domenico Ferrari from comment #2) > The problem is with kernel version 5.7.7. > I'm using now version 5.6.19 and I have no bugs. Hi, can you get us more information here? What kind of graphics card you're using, what kind of DE are you running, what graphics driver are you using, etc.? Ideally as well, an sosreport would help since that would give us a lot of that information. The best way to get that would be to log into your machine with ssh from another computer, then generate the sosreport immediately after the hang.
Hi. I'm testing kernel 5.7.8. If I set DRI option to false, I can play the video as expected. cat /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "DRI" "false" EndSection Sorry, but currently I haven't another computer to generate the report you requested. My system is Intel(R) Pentium(R) CPU G3420 @ 3.20GHz 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Device 0402 Flags: bus master, fast devsel, latency 0, IRQ 33 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 I'm using xfce DE.
(In reply to Domenico Ferrari from comment #4) > Hi. > I'm testing kernel 5.7.8. > If I set DRI option to false, I can play the video as expected. > > cat /etc/X11/xorg.conf.d/20-intel.conf > > Section "Device" > Identifier "Intel Graphics" > Driver "intel" > Option "DRI" "false" > EndSection > > Sorry, but currently I haven't another computer to generate the report you > requested. > > My system is Intel(R) Pentium(R) CPU G3420 @ 3.20GHz > > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen > Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA > controller]) > Subsystem: ASRock Incorporation Device 0402 > Flags: bus master, fast devsel, latency 0, IRQ 33 > Memory at f0000000 (64-bit, non-prefetchable) [size=4M] > Memory at e0000000 (64-bit, prefetchable) [size=256M] > I/O ports at f000 [size=64] > Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] > Capabilities: <access denied> > Kernel driver in use: i915 > Kernel modules: i915 > > I'm using xfce DE. Hi, that's likely because you're turning off hardware acceleration by using that option. Also, have you tried the modesetting driver?
(In reply to Lyude from comment #5) > > Hi, that's likely because you're turning off hardware acceleration by using > that option. Also, have you tried the modesetting driver? Yes, I know that I turned off the acceleration. Why use the modesetting driver? I want to use my computer with hardware acceleration as with the previous kernel 5.6.
jfyi, sorry I lost track of this bug for a bit! next time I get a chance (hopefully sometime this week) I can try to bisect this the next time I get a chance if you want, but the reason I suggested changing ddx is because you don't need the xorg-x11-drv-intel package for hardware acceleeration on X anymore, and it's also not really actively maintained much upstream either. We generally don't recommend users use it anymore, except for Intel gen3 GPUs and earlier.
(In reply to Lyude from comment #7) > jfyi, sorry I lost track of this bug for a bit! next time I get a chance > (hopefully sometime this week) I can try to bisect this the next time I get > a chance if you want, but the reason I suggested changing ddx is because you > don't need the xorg-x11-drv-intel package for hardware acceleeration on X > anymore, and it's also not really actively maintained much upstream either. > We generally don't recommend users use it anymore, except for Intel gen3 > GPUs and earlier. thank you for your time. I'm not forcing xorg-x11-drv-intel, the installation of Fedora selected the driver. Maybe I'm using it because I haven't done a fresh install for years but only updates? I thought that the system selected the best driver for me, I'm wrong? Do I need to force the modesetting driver? What's the best way to do it? So are you saying that X and programs (like vlc) doesn't use hardware acceleration? tnx
Same problem with kernel-5.8.11-200. I'm not sure what to look for... Is there any log I can check to narrow down the search?
(In reply to Domenico Ferrari from comment #8) > (In reply to Lyude from comment #7) > > jfyi, sorry I lost track of this bug for a bit! next time I get a chance > > (hopefully sometime this week) I can try to bisect this the next time I get > > a chance if you want, but the reason I suggested changing ddx is because you > > don't need the xorg-x11-drv-intel package for hardware acceleeration on X > > anymore, and it's also not really actively maintained much upstream either. > > We generally don't recommend users use it anymore, except for Intel gen3 > > GPUs and earlier. > > thank you for your time. > I'm not forcing xorg-x11-drv-intel, the installation of Fedora selected the > driver. Maybe I'm using it because I haven't done a fresh install for years > but only updates? > I thought that the system selected the best driver for me, I'm wrong? Do I > need to force the modesetting driver? What's the best way to do it? > So are you saying that X and programs (like vlc) doesn't use hardware > acceleration? > > tnx Hi! Sorry about that it looks like I misspoke - the xorg-x11-drv-intel ddx is selected by default for gen4 and older, not gen3 and older. That being said it might be worth checking if forcing modesetting helps anyway, although it may end up making things worse. To force using the modesetting driver, you can put a file in /etc/X11/xorg.conf.d/07-modesetting.conf that says: Section "Device" Identifier "Device0" Driver "modesetting" EndSection Then restart X.org. If it makes things worse you can just undo it by deleting that file and restarting.
(In reply to Domenico Ferrari from comment #8) > (In reply to Lyude from comment #7) > > jfyi, sorry I lost track of this bug for a bit! next time I get a chance > > (hopefully sometime this week) I can try to bisect this the next time I get > > a chance if you want, but the reason I suggested changing ddx is because you > > don't need the xorg-x11-drv-intel package for hardware acceleeration on X > > anymore, and it's also not really actively maintained much upstream either. > > We generally don't recommend users use it anymore, except for Intel gen3 > > GPUs and earlier. > > thank you for your time. > I'm not forcing xorg-x11-drv-intel, the installation of Fedora selected the > driver. Maybe I'm using it because I haven't done a fresh install for years > but only updates? > I thought that the system selected the best driver for me, I'm wrong? Do I > need to force the modesetting driver? What's the best way to do it? > So are you saying that X and programs (like vlc) doesn't use hardware > acceleration? > > tnx also just to clarify - they do use acceleration, it's just that X.org has it's own level of "drivers" which handle modesetting and providing GLX to applications, and it used to be that back in the day you had to use something like xf86-video-intel (named xorg-x11-drv-intel on Fedora) on all intel cards in order to have hardware acceleration. These days we try to focus development on the one-size-fits-all video driver for X.org, xf86-video-modesetting (included by default in xorg-x11-server), which is why I think it would be a good idea for you to try to see if that helps with your issues at all.
Thanks for your clear answer. I tried the modesetting but I have the same problem. Xorg is working but applications that use hardware acceleration are failing, it seems that they are waiting or in a loop, the desktop freezes. This is vlc with output OpenGL VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2) [00005606f19039b0] main libvlc: Esecuzione di vlc con l'interfaccia predefinita. Usa 'cvlc' per utilizzare vlc senza interfaccia. libva info: VA-API version 1.7.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: va_openDriver() returns -1 libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_7 libva info: va_openDriver() returns 0 [00007fec0cc3fe70] avcodec decoder: Using Intel i965 driver for Intel(R) Haswell Desktop - 2.4.1 for hardware decoding [00007fec0cc3fe70] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?) [00005606f199b2e0] main playlist: end of playlist, exiting Again, this happens with kernel > 5.6. Xorg.log [ 1068.560] (II) xfree86: Adding drm device (/dev/dri/card0) [ 1068.560] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 14 paused 0 [ 1068.562] (--) PCI:*(0@0:2:0) 8086:0402:1849:0402 rev 6, Mem @ 0xf0000000/4194304, 0xe0000000/268435456, I/O @ 0x0000f000/64, BIOS @ 0x????????/65536 [ 1068.562] (II) LoadModule: "glx" [ 1068.562] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 1068.563] (II) Module glx: vendor="X.Org Foundation" [ 1068.563] compiled for 1.20.8, module version = 1.0.0 [ 1068.563] ABI class: X.Org Server Extension, version 10.0 [ 1068.563] (II) LoadModule: "modesetting" [ 1068.563] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 1068.563] (II) Module modesetting: vendor="X.Org Foundation" [ 1068.563] compiled for 1.20.8, module version = 1.20.8 [ 1068.563] Module class: X.Org Video Driver [ 1068.563] ABI class: X.Org Video Driver, version 24.1 [ 1068.563] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 1068.563] (II) modeset(0): using drv /dev/dri/card0 [ 1068.563] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 1068.563] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 1068.563] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 1068.563] (==) modeset(0): RGB weight 888 [ 1068.563] (==) modeset(0): Default visual is TrueColor [ 1068.563] (II) Loading sub module "glamoregl" [ 1068.563] (II) LoadModule: "glamoregl" [ 1068.564] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 1068.566] (II) Module glamoregl: vendor="X.Org Foundation" [ 1068.566] compiled for 1.20.8, module version = 1.0.1 [ 1068.566] ABI class: X.Org ANSI C Emulation, version 0.4 [ 1068.579] (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) HD Graphics (HSW GT1) [ 1068.579] (II) modeset(0): glamor initialized
> Is it the same bug or are they possibly related? I think it may be yet another problem with the iris driver. You can try to force use i965. However, please keep in mind that Gen12+ GPUs are supported only by iris. Sandy Bridge is a Gen6 GPU, if I good remember. Anyway, at first, try this: MESA_LOADER_DRIVER_OVERRIDE=i965 vlc or this: export MESA_LOADER_DRIVER_OVERRIDE=i965; vlc If that helps, put this in ~/.drirc (user configuration) or /usr/share/drirc.d/01-i915-force-i965.conf (system configuration; you can use /etc/drirc as well): <?xml version="1.0" standalone="yes"?> <driconf> <device driver="loader" kernel_driver="i915"> <option name="dri_driver" value="i965" /> </device> </driconf>
Forget what I just said. Iris only supports Gen8+ GPUs anyway, and you're already using i965: libva info: Trying to open /usr/lib64/dri/i965_drv_video.so [00007fec0cc3fe70] avcodec decoder: Using Intel i965 driver for Intel(R) Haswell Desktop - 2.4.1 for hardware decoding
Problem still persists on Fedora 33 with new kernel. Now I'm using kernel 5.6 from Fedora 32.
Hi, same problem with CPU G3220 (HSW GT1)
Using kernel 5.11.0-0.rc7.149.fc34.x86_64 on Intel G3420. So far, so good.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.