After updating, I rebooted to find a distinct lack of gdm. The screen would blank but the logon screen never appeared. Adding the following to package.mask allows gdm to come back up: =x11-base/xorg-server-1.15.99.903 =media-libs/mesa-10.2.1 =x11-drivers/xf86-video-intel-2.99.912 Reproducible: Always Steps to Reproduce: 1. Update your GNOME 3 system 2. Reboot 3. Get frustrated for several days Actual Results: A blank screen of Zen awesomeness but GNOME sub-awesomeness. Expected Results: A logon screen of GNOME awesomeness and Zen sub-awesomeness. I'm trying to downgrade only mesa on another box with this problem. I'll let you know how it goes.
The mesa line alone is insuficient.
Only the xorg line is required
Please attach your "emerge --info xorg-server gdm" output. And check for relevant error messages (about gdm, gnome-shell, X, etc.) in journalctl.
I got the exact same problem - which was pretty horrible to pin down. The thing is: The bug showed up for me in the morning without having updated or rebuilt xorg-server 1.5.99.903 recently, so I guess this was triggered by some other update. Also I couldn't find any trace pointing to xorg-server being the problem in the logs (even with debugging turned on) Masking xorg-server-1.15.99.903 solves the problem though
Created attachment 379098 [details] emerge --info xorg-server gdm
I can confirm the same issue and the same solution (masking =x11-base/xorg-server-1.15.99.903). I'd tried reinstalling x11-drivers/xf86-video-intel as well as installing older versions of gdm and that didn't work, then I installed xfce4-meta and when everything worked just fine I was confused -- but at least I could get a browser open and find this bug report, so I could figure out how to fix it. I don't know if this is an upstream issue, or just a quirk with how the packages were compiled on our systems, but for what it's worth I've attached my emerge --info for gdm and xorg-server. The machine in question is a Lenovo Thinkpad X1, Intel drivers.
> x11-base/xorg-server-1.15.1 was built with the following: > USE="ipv6 kdrive nptl suid udev xorg xvfb -dmx -doc -minimal (-selinux) -static-libs -tslib -unwind -xnest" It would be good to know which flags were enabled for xorg-server-1.15.99.903. Also, did gdm produce any log entries?
*** Bug 513530 has been marked as a duplicate of this bug. ***
I believe I am seeing a similar issue when starting Cinnamon via lightdm. I thought it was just hanging before Cinnamon loads, but the display seems to freeze. If I "blindly" launch something with alt-f2, then move my mouse around, I can actually see my cursor change as it gets to window borders for resize. So it's just a rendering issue. I downgraded x11-drivers/xf86-video-intel from 2.99.912 to 2.99.911-r1 and it resolved my issue. If this isn't related, my apologies. But it sounds very similar, maybe there is a common component between my Cinnamon session and your gdm-3. If it does end up being the same issue... FWIW my Xorg logs and Cinnamon session logs do not show anything abnormal, as far as I can tell.
I'd seen the same reported as bug 51350. Attaching info of xorg-server and a gdm greeter-log.2. I did find in looking around last night that this has happened in the past, and it may be relevant that in my case it's ivybridge hardware.
Created attachment 379140 [details] xorg emerge info
Created attachment 379142 [details] gdm greeter log
(In reply to Ben Kohler from comment #9) > maybe there is a common component between my Cinnamon session and your gdm-3. Both Cinnamon and GDM use media-libs/clutter and media-libs/cogl for rendering.
Could someone who sees this issue try xf86-video-intel-9999 from git?
(In reply to Chí-Thanh Christopher Nguyễn from comment #14) > Could someone who sees this issue try xf86-video-intel-9999 from git? I still see the issue on 9999, and I've also done a git bisect with limited success: git bisect start # good: [582adf067c275a18f55bb43945348b84cb7eb3c4] 2.99.911 snapshot git bisect good 582adf067c275a18f55bb43945348b84cb7eb3c4 # bad: [cb7b27a705b477ae1b369786eea13fb14506d54a] 2.99.912 snapshot git bisect bad cb7b27a705b477ae1b369786eea13fb14506d54a # good: [c410f0cd982cad8de440727b0ad7d9268b89a704] sna: Set desired mode after rediscover during VT switch git bisect good c410f0cd982cad8de440727b0ad7d9268b89a704 # good: [3dac734bb0fb0ae1febfef9a9289cf830a87be1c] test: Only compute the masked pixel value if depth!=32 git bisect good 3dac734bb0fb0ae1febfef9a9289cf830a87be1c # bad: [9566fc0ccc71bc4fcd6bf83b567a41cc5366f5ee] sna: Curry parameters to sna_damage_all() git bisect bad 9566fc0ccc71bc4fcd6bf83b567a41cc5366f5ee # skip: [67b37332bd45dd4cea297107bfdc9df21984fdcd] intel-virtual-output: Add DRI3 xfer path git bisect skip 67b37332bd45dd4cea297107bfdc9df21984fdcd # skip: [0fbe8995d51b4643f1cf06c07da8b4b5ac5ae7c3] sna: Relax tiling height restrictions git bisect skip 0fbe8995d51b4643f1cf06c07da8b4b5ac5ae7c3 # good: [fc1f9b91ae2c761e4b126daecab13e13ae2534d3] sna: Mark all caches for expiration git bisect good fc1f9b91ae2c761e4b126daecab13e13ae2534d3 # bad: [ff36e1f7546e0ac4d6e831e5cf8d1317792ed7af] uxa: Add Present extension support git bisect bad ff36e1f7546e0ac4d6e831e5cf8d1317792ed7af # good: [8a02886a24c8699374a39a9363e72bec0e7bbe30] sna/dri2: Use real async flips git bisect good 8a02886a24c8699374a39a9363e72bec0e7bbe30 # skip: [d8eb87f84f88ad2df42c6fed1d93df76589a14e3] sna: Add support for DRI3 git bisect skip d8eb87f84f88ad2df42c6fed1d93df76589a14e3 # bad: [dd6db82680b05cde4a47116b7096c054f3837e20] uxa: Add DRI3 and miSyncShm support git bisect bad dd6db82680b05cde4a47116b7096c054f3837e20 # skip: [9cf6cd9726ed5ba73bb8c38c06f7b5c78706309b] Add rudimentary tests for Present git bisect skip 9cf6cd9726ed5ba73bb8c38c06f7b5c78706309b # good: [d6240d197be1e752c0de26fbf84fc8fa8d55383c] intel: Clear structs for valgrind git bisect good d6240d197be1e752c0de26fbf84fc8fa8d55383c # good: [6ab6734369fbd902a23109f4c3626df9d529891c] Add rudimentary tests for DRI3 git bisect good 6ab6734369fbd902a23109f4c3626df9d529891c # bad: [975b9798be77b30cbed485583d0ccb48318708f7] sna: Add support for Present git bisect bad 975b9798be77b30cbed485583d0ccb48318708f7 # only skipped commits left to test # possible first bad commit: [975b9798be77b30cbed485583d0ccb48318708f7] sna: Add support for Present # possible first bad commit: [d8eb87f84f88ad2df42c6fed1d93df76589a14e3] sna: Add support for DRI3 # possible first bad commit: [0fbe8995d51b4643f1cf06c07da8b4b5ac5ae7c3] sna: Relax tiling height restrictions # possible first bad commit: [67b37332bd45dd4cea297107bfdc9df21984fdcd] intel-virtual-output: Add DRI3 xfer path # possible first bad commit: [9cf6cd9726ed5ba73bb8c38c06f7b5c78706309b] Add rudimentary tests for Present
(In reply to Ben Kohler from comment #15) > # possible first bad commit: [975b9798be77b30cbed485583d0ccb48318708f7] sna: > Add support for Present > # possible first bad commit: [d8eb87f84f88ad2df42c6fed1d93df76589a14e3] sna: > Add support for DRI3 > # possible first bad commit: [0fbe8995d51b4643f1cf06c07da8b4b5ac5ae7c3] sna: > Relax tiling height restrictions > # possible first bad commit: [67b37332bd45dd4cea297107bfdc9df21984fdcd] > intel-virtual-output: Add DRI3 xfer path > # possible first bad commit: [9cf6cd9726ed5ba73bb8c38c06f7b5c78706309b] Add > rudimentary tests for Present Sounds about right with what's been said so far. I've pushed a -r1 that should disable DRI3. Could you all try it out and let me know how it goes? Thanks
I have this Problem, if I do an update from mesa-10.2.0_rc5 to mesa-mesa-10.2.1. I use xorg-server-1.15.99.903 and xf86-video-intel-2.99.912 and all works fine. I think, the pro bem is mesa.
(In reply to klaus818 from comment #17) > I have this Problem, if I do an update from mesa-10.2.0_rc5 to > mesa-mesa-10.2.1. > > I use xorg-server-1.15.99.903 and xf86-video-intel-2.99.912 and all works > fine. I think, the pro bem is mesa. I have no problems with: [ebuild R ] media-libs/mesa-10.0.4 USE="classic egl gallium llvm nptl vdpau -bindist -debug -gbm -gles1 -gles2 -llvm-shared-libs -opencl -openvg -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -wayland -xa -xvmc" ABI_X86="(64) (-32) (-x32)" VIDEO_CARDS="i915 i965 intel (-freedreno) -ilo -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware" 0 kB [ebuild R ~] x11-drivers/xf86-video-intel-2.99.912 USE="dri sna udev -debug -glamor -uxa -xvmc" 0 kB [ebuild R ] x11-base/xorg-server-1.15.0:0/1.15.0 USE="kdrive nptl suid udev xorg xvfb -dmx -doc -ipv6 -minimal (-selinux) -static-libs -tslib -unwind -xnest" 0 kB Then, the latest intel driver looks to still work for me with stable xorg-server and mesa
Ok, with the new xf86-video-intel-2.99.912-1 with the no-dri3-patch all works fine for me.
(In reply to Pacho Ramos from comment #18) > (In reply to klaus818 from comment #17) > > I have this Problem, if I do an update from mesa-10.2.0_rc5 to > > mesa-mesa-10.2.1. > > > > I use xorg-server-1.15.99.903 and xf86-video-intel-2.99.912 and all works > > fine. I think, the pro bem is mesa. > > I have no problems with: > [ebuild R ] media-libs/mesa-10.0.4 USE="classic egl gallium llvm nptl > vdpau -bindist -debug -gbm -gles1 -gles2 -llvm-shared-libs -opencl -openvg > -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -wayland -xa -xvmc" > ABI_X86="(64) (-32) (-x32)" VIDEO_CARDS="i915 i965 intel (-freedreno) -ilo > -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware" 0 kB > [ebuild R ~] x11-drivers/xf86-video-intel-2.99.912 USE="dri sna udev > -debug -glamor -uxa -xvmc" 0 kB > [ebuild R ] x11-base/xorg-server-1.15.0:0/1.15.0 USE="kdrive nptl suid > udev xorg xvfb -dmx -doc -ipv6 -minimal (-selinux) -static-libs -tslib > -unwind -xnest" 0 kB > > Then, the latest intel driver looks to still work for me with stable > xorg-server and mesa Hei Pacho, you are on stable, I use testing. And you don't use mesa-10.2.1.
-r1 resolves my gdm issue.
(In reply to klaus818 from comment #17) > I have this Problem, if I do an update from mesa-10.2.0_rc5 to > mesa-mesa-10.2.1. > > I use xorg-server-1.15.99.903 and xf86-video-intel-2.99.912 and all works > fine. I think, the pro bem is mesa. Mesa-10.2.1 at the request of bug #512932 "Enable DRI3 by default again" I got around the problem by disabling again dri3 in mesa ! Downgrading to Mesa-10.1.4 didn't help i still need to disable dri3 flag.
If you use a version of mesa with dri3 available and enabled, with a version of xf86-video-intel with dri3 enabled, you hit this bug. That's the jist of it, you can blame mesa or xf86-video-intel, but it's just that dri3 is breaking some stuff. Workaround is xf86-video-intel with dri3 off, or mesa with dri3 off.
I know it's a bit ugly, but since no one is likely to fix this bug in the very near future, might i suggest a block in xf86-video-intel on dri3? !mesa[dri3] or some such?
(In reply to Rick Farina (Zero_Chaos) from comment #24) > I know it's a bit ugly, but since no one is likely to fix this bug in the > very near future, might i suggest a block in xf86-video-intel on dri3? > !mesa[dri3] or some such? xf86-video-intel-2.99.912-r1 disables DRI3 and thus fixes this bug, at least temporarily. Closing
FWIW, I believe this is fixed in mesa-10.2.4. mesa-10.2.2[dri3] + xf86-video-intel-2.99.912 = bad mesa-10.2.2[dri3] + xf86-video-intel-2.99.912-r1 = good mesa-10.2.4[dri3] + xf86-video-intel-2.99.912 = good mesa-10.2.4[dri3] + xf86-video-intel-2.99.912-r1 = good
(In reply to Ben Kohler from comment #26) > mesa-10.2.4[dri3] + xf86-video-intel-2.99.912 = good > mesa-10.2.4[dri3] + xf86-video-intel-2.99.912-r1 = good Duly noted. Though I'm still not quite sure what to do with DRI3 right now, since hardly anything uses it (I'm not even sure mesa actually uses it by default now, the current bug looks like a fumble of DRI2 and 3). I'll look into it and maybe will turn DRI3 back on in the coming weeks. Thanks for doing the testing
> Duly noted. Though I'm still not quite sure what to do with DRI3 right now, > since hardly anything uses it (I'm not even sure mesa actually uses it by > default now, the current bug looks like a fumble of DRI2 and 3). > > I'll look into it and maybe will turn DRI3 back on in the coming weeks. > > Thanks for doing the testing For what it's worth, disabling it in xf86-intel at the time got me back to a working optimus system, but I was still seeing hinkiness until I just added -DRI3 to make.conf in case xorg 1.16 or mesa were fumbling around in the back seat or something and all was well. I don't think they are able to really get it on successfully yet.