Description of problem: When logging off the second user after switching users, X hangs. It is not possible to do anything locally on the machine but hard reboot. Version-Release number of selected component (if applicable): How reproducible: It can be reproduced by switching between users then logging off the second user Steps to Reproduce: 1. Login to account user1 2. Use fast user switching applet to login to account user2 3. Finish the work in account user2 and log off user 2 Actual results: Computer hangs Expected results: Password prompt for user1 Additional info: I have tried this and can reproduce the bug with 2 machines having Intel onboard graphics. Both exhibit the same behaviour. When replaying the above steps on a PC having ATI graphics card, it follows the expected behaviour and asks for password. Following is the lspci from the 2 machines with Intel graphics __Machine1__ 00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03) 01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) 01:04.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01) __Machine2__ 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) 01:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 02) 01:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Oops! After going through the other bug reports, I should have added this in mine. I don't have any /etc/X11/xorg.conf file. So, Xorg is auto detecting the values. I will attach the Xorg.[0,1].log tomorrow since it does have some clues too. It had some error lines which would be of help.
Created attachment 330323 [details] raw Xorg log
Created attachment 330324 [details] raw Xorg log old
Hi, I have attached Xorg.0.log and Xorg.0.log.old. I hope that is helpful enough. Thank You.
Both logs have only [matej@viklef ~]$ checkXorgLog 330323 (EE) Unable to locate/open config file (WW) Falling back to old probe method for fbdev (EE) open /dev/fb0: No such file or directory (WW) Falling back to old probe method for vesa (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB [matej@viklef ~]$ Except for the last line with which I am not sure all these are quite harmless.
Maybe the same error is not repeated on the machine from where I get the logs. This makes it all the more curious because all the machines with onboard intel graphics are exhibiting this behaviour. Is there any more information I can provide to check this? Or can somebody with intel graphics test it out?
Created attachment 330525 [details] xorg log
It's been over a week and no response on the bug. This bug is a big problem as we do user switching a lot at the office and most of the machines are affected by it. It would be very much appreciated if there is some response on this.
Created attachment 331804 [details] /var/log/Xorg.0.log
Created attachment 331805 [details] /var/log/Xorg.0.log.old
Created attachment 331806 [details] /var/log/Xorg.1.log
Created attachment 331807 [details] /var/log/Xorg.1.log.old
(Almost) the same here. Only here one can't even manage to log in as user2. The screen freezes after clicking 'other' in the 'User Switcher'. It happens here on a Dell Inspiron 6000 with Intel Graphics Controller: ~]# lspci|grep Graph 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) And no xorg.conf: ~]# cat /etc/X11/xorg.conf cat: /etc/X11/xorg.conf: No such file or directory The screen freezes after clicking 'other' in the 'User Switcher'. Mostly with a very colorful display, sometimes black screen, sometimes a screen as when x starts: a mouse arrow with rotating bubbles, which stop rotating almost immediately after showing up. Go to a terminal (Ctrl-Alt-F2) won't work, neither won't Ctrl-Alt-Backspace. Only thing left to do is hard switch off and then switch on again.
Created attachment 331808 [details] lspci.text Here is the output of lspci
I have a similar problem to this and comment #14 I run Fedora 10, all latest updates applied, running KDE. The laptop is an Acer Aspire 5920 with an Intel X3100 graphics card. Selecting "Switch User", then "New Session" switches the display to the plain fedora background but KDM never appears that the CPU seems to enter a 100% loop as the fans kick in on the laptop. At that point I can no longer switch TTY, even to get back to a text screen. There is nothing log in /var/log/messages. There are a couple of errors in the Xorg log files for .1 and .0: .1: (EE) [drm] Could not set DRM device bus ID. (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. (EE) intel(0): underrun on pipe B! .0: (EE) open /dev/fb0: No such file or directory (EE) intel(0): underrun on pipe B! I will attach the full log files. lspci output for the graphics card: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Device 0121 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f0000000 (64-bit, non-prefetchable) [size=1M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Count=1/1 Enable- Capabilities: [d0] Power Management version 3 Kernel modules: intelfb 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) Subsystem: Acer Incorporated [ALI] Device 0121 Flags: bus master, fast devsel, latency 0 Memory at f0100000 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 3
Created attachment 332120 [details] Screen 0 log from crash
Created attachment 332121 [details] Screen 1 log from crash.
It is worth noting I am running with graphical boot enabled (vga=0x315), although testing with text only boot makes no difference. I can successfully switch to a text TTY and back to graphical using CTRL-ALT-F2 etc. and I can also log out and back in again with a different user quite happily, this problem only occurs when trying to start a new X session to "Switch" to.
Testing from a text TTY, starting a second X session using Xorg :5 also causes the whole system to hang. Again nothing in /var/log/messages but I will attached the new xorg log in case it helps.
Created attachment 332125 [details] Xorg log file from starting XOrg manually from a TTY.
1 more comment... (sorry for lots of them). This *used* to work just fine with the vanilla Fedora 10, it was one of the updates that broke this behaviour. I cannot remember exactly when it changed but everything worked fine on the first release of F10 and I ran for quite a while switching users several times a day with no issues. This might help tracking down the change that caused the bug to occur.
Same story here. Activating the fast user switching applet and selecting 'Other...' hangs the computer. It ceases to respond mouse, keyboard, and network pings. I have Eee Box B202 with integrated Intel GMA 950 graphics controller, xorg.conf uses driver "intel".
Is there no solution to this? It has been replicated by others, too.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, including Intel driver, which may have resolved this issue. To be more precise, Intel has undergone a major rewrite during Fedora 10, 11 and 12 cycles, and whole driver is working a lot better now. Users who have experienced this problem are encouraged to retry with at least Fedora 12 Beta and see if the issue is still relevant. Please, if you experience this problem on Fedora 12 Beta or up-to-date system running Rawhide, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. We hope to see how many older bugs in Intel driver are still relevant today, in hope that most of them were fixed in rewrite process. [This is a bulk message for all open Fedora 10 i810-related bugs (39 of them are still open). I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
I'm glad to know you think it is fixed in Fedora 12 Beta. Unfortunately I still run Fedora 10 and as this is my main system I have no desire to upgrade to a beta release in the hope that the problem might be fixed. I'm rather disappointed that this bug appears to have simply been sat on for the last 9 months with no comments, then someone comes along and gives 1 month to reply to every i810 related bug otherwise they will be closed. It seems like a strange way to operate to me. From my point of view this *looks* like you've just decided to close off all the bugs in the hope that they are not occurring in the new driver and doesn't fill me with confidence that this bug is actually fixed (or for that matter that anyone has ever looked at what is wrong or tried to fix it). I'm writing this reply in the hope that someone might understand the frustration this issue has caused. When I installed Fedora 10 everything worked fine, a subsequent update introduced this problem but nobody seemed to care or want to fix it. What makes this even more frustrating from my point of view is that I specifically bought a machine with Intel graphics because I was under the impression that there were well maintained and well supported drivers out there for the hardware.
I must be hitting a different issue. My machines have NVidia cards and I still see user switching badness. My workaround was to use kdm instead of gdm (f11) and these problems mostly went away for me.
I don't see this issue in an F11 install anymore. It would be nice to see it taken care of earlier - but hey, this is Fedora!
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Thank you for your bug report. We are sorry, but the Fedora Project is will soon stop longer releasing bug fixes or any other updates for this version of Fedora. There were so many changes between Fedora 10 and Fedora 12 in Intel driver and X.Org that it's very likely that this bug is fixed. This bug will be set to CLOSED:WONTFIX to reflect this, but please reopen it if the problem persists after upgrading to the latest version of Fedora (version 12), which is available from: http://fedoraproject.org/get-fedora