Created attachment 717748 [details] Log files, list of all RPM packages installed, lspci -v output. Description of problem: After yum update, gnome-shell fails when more than one display is attached. Version-Release number of selected component (if applicable): How reproducible:Attach multiple displays and restart system. Steps to Reproduce: 1.Fresh install of fedora 18. yum update to latest version of all packages. I don't know what package caused this. I will attach file with "rpm -qa" output. 2.Attach multiple displays. 3.Restart X session. Actual results: "Oh no! Something has gone wrong!" message. Check attached logs for more info. Expected results: Login screen. Additional info: Instead of login screen on startup, I got the message "Oh no, something has gone wrong". When login with single display, everything is working. At the moment I turn on the 2nd display from System Settings > Displays, I got the same error. Switched to console with Alt+F2, started "gnome-shell --replace --display=:0". No errors, but a second after I go to Alt+F1, I got the same error, back in the text console I got "core dumped" message. "yum downgrade gnome-shell" didn't help, so I guess it should be some other package that I updated but I don't know which. Tried to reinstall Fedora 18 on clean. After fresh install, nothing extra installed and nothing removed. "yum update" only with Fedora repositories added and after reboot, same error. The logs and rpm packages in the attached files are all from the new fresh install.
(In reply to comment #0) > After yum update, gnome-shell fails when more than one display is attached. Does that mean that it worked before? Otherwise the most likely reason would be that you are hitting the texture size limit of your graphics card when enabling the 2nd monitor.
It worked before. I am working on this hardware and with 2 monitors sense Fedroa 16. Many updates with no trouble. I got the hard disk and plugged on my home PC, there it worked fine with 2 monitors, but when I put it back on my work laptop, it fails again. Can it be be something with the ATI display driver? I didn't install ati drivers from repositories or from the ATI web site, because every time I try to install it, it fails and after reboot I got no X. I was always working with the included in the distribution one. Booting the old kernel from the grub entry doesn't help.
(In reply to comment #2) > Can it be be something with the ATI display driver? The texture size limit depends on the graphics hardware / driver, so yes. You can use glxinfo -l | grep MAX_TEXTURE_SIZE to see if this is indeed the problem here (you'll need the glx-utils package, which isn't installed by default if I recall correctly).
Created attachment 732086 [details] Core dump directory ccpp-2013-03-27-02:27:21-1491 (check syslog output) Core dump directory ccpp-2013-03-27-02:27:21-1491. Got from this syslog entry: Apr 6 00:28:56 mehanzhi abrt[1956]: Saved core dump of pid 1495 (/usr/bin/gnome-shell) to /var/tmp/abrt/ccpp-2013-04-06-00:28:55-1495 (147963904 bytes) Apr 6 00:28:56 mehanzhi abrtd: Directory 'ccpp-2013-04-06-00:28:55-1495' creation detected ...................................... Apr 6 00:28:56 mehanzhi gnome-session[1268]: WARNING: Application 'gnome-shell.desktop' killed by signal 7 Apr 6 00:28:56 mehanzhi abrtd: Generating backtrace Apr 6 00:28:57 mehanzhi abrtd: Backtrace is generated, 41294 bytes Apr 6 00:28:57 mehanzhi abrtd: Core backtrace is generated and saved, 3546 bytes Apr 6 00:28:59 mehanzhi abrtd: Duplicate: core backtrace Apr 6 00:28:59 mehanzhi abrtd: DUP_OF_DIR: /var/tmp/abrt/ccpp-2013-03-27-02:27:21-1491 Apr 6 00:28:59 mehanzhi abrtd: Deleting problem directory ccpp-2013-04-06-00:28:55-1495 (dup of ccpp-2013-03-27-02:27:21-1491)
Hello, glx-utils package was installed by default :) root@glxinfo -l | grep MAX_TEXTURE_SIZE [root@mehanzhi root]# glxinfo -l | grep MAX_TEXTURE_SIZE GL_MAX_TEXTURE_SIZE = 8192 [root@mehanzhi root]# This is the output you asked for. If you like I can attach the entire output without the grep. This time I started the machine with single display so I can extract the information and attach it here. When I turn on the second display, the monitor switch on that white stuff like radio noise. This is what I see now in the /var/log/messages: Apr 6 00:28:44 mehanzhi systemd[1]: Starting Stop Read-Ahead Data Collection... Apr 6 00:28:44 mehanzhi systemd[1]: Started Stop Read-Ahead Data Collection. Apr 6 00:28:51 mehanzhi NetworkManager[804]: <info> (p4p1): IP6 addrconf timed out or failed. Apr 6 00:28:51 mehanzhi NetworkManager[804]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) scheduled... Apr 6 00:28:51 mehanzhi NetworkManager[804]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) started... Apr 6 00:28:51 mehanzhi NetworkManager[804]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) complete. Apr 6 00:28:56 mehanzhi abrt[1956]: Saved core dump of pid 1495 (/usr/bin/gnome-shell) to /var/tmp/abrt/ccpp-2013-04-06-00:28:55-1495 (147963904 bytes) Apr 6 00:28:56 mehanzhi abrtd: Directory 'ccpp-2013-04-06-00:28:55-1495' creation detected Apr 6 00:28:56 mehanzhi gnome-session[1268]: WARNING: Detected that screensaver has left the bus Apr 6 00:28:56 mehanzhi NetworkManager[804]: <warn> error requesting auth for org.freedesktop.NetworkManager.wifi.share.protected: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.80': no such name Apr 6 00:28:56 mehanzhi NetworkManager[804]: <warn> error requesting auth for org.freedesktop.NetworkManager.wifi.share.open: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.80': no such name Apr 6 00:28:56 mehanzhi gnome-session[1268]: WARNING: Application 'gnome-shell.desktop' killed by signal 7 Apr 6 00:28:56 mehanzhi abrtd: Generating backtrace Apr 6 00:28:57 mehanzhi abrtd: Backtrace is generated, 41294 bytes Apr 6 00:28:57 mehanzhi abrtd: Core backtrace is generated and saved, 3546 bytes Apr 6 00:28:59 mehanzhi abrtd: Duplicate: core backtrace Apr 6 00:28:59 mehanzhi abrtd: DUP_OF_DIR: /var/tmp/abrt/ccpp-2013-03-27-02:27:21-1491 Apr 6 00:28:59 mehanzhi abrtd: Deleting problem directory ccpp-2013-04-06-00:28:55-1495 (dup of ccpp-2013-03-27-02:27:21-1491) I've attached the core dump directory ccpp-2013-03-27-02:27:21-1491 in a tarball above. Thank you.
I have the exact same problem after update of mesa-dri-drivers. I'm also on ATI (HD 5870). Downgrade of mesa fixed the problem (but now suspend does not work). (yum downgrade mesa-dri-drivers llvm-libs mesa-dri-filesystem mesa-libxatracker) Maybe the same as: https://bugs.freedesktop.org/show_bug.cgi?id=61182 and https://bugzilla.redhat.com/show_bug.cgi?id=918499
Hello, I am using docking station too, but I didn't think it matters, because when my laptop is on it, but I don't use external monitor, everything is running OK.
Yes, on my system the docking station does also not matter, I get the same problem if I connect two monitors directly to the laptop. So it is the number of monitors that differ. And vice versa, if I connect only one external monitor to the docking station it also works without downgrading mesa.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.