Bug 138503
Summary: | System freezes while it tries to switch from rhgb to gdm (Xorg) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Philip Van Hoof <spam> | ||||
Component: | xorg-x11 | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3 | CC: | frank.swasey, g.eustace, goldfish, henkler, jeremythehunt, mhw, mikereape, peter, redhat-bugzilla, saphipps, shadbolt | ||||
Target Milestone: | --- | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-03-23 22:58:19 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 136451 | ||||||
Attachments: |
|
Description
Philip Van Hoof
2004-11-09 18:11:41 UTC
I've seen similar problems with a HP nx7010 laptop using: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01) cp /etc/X11/xorg.conf to /etc/rhgb/ and disable DRI in the later, then retry... I though DRI issues and multiple instance of X had been taken care of both in recent rhgb and xorg.x11 packages though, that should not crash. Daniel I encountered this problem as well, with an ATI Radeon 9000 and a dual display setup. If /etc/rhgb/xorg.conf is set up with a single head layout the problem goes away. Would a symbolic link [/etc/rhgb/xorg.conf] to [/etc/X11/xorg.conf] introduce more problems if it where to be put in the rhgb-package? I can imagine the problems one could be having with rhgb if his/hers xorg.conf aint working. If a small switch from graphical boot to console to graphical loginscreen is needed, I don't really see the point in supporting dualhead in rhgb. My idea about dualhead is that a lot current dualhead configurations are known to cause hardware problems with videocards if tampered with to much. I've had hardware-crashes with radeon dualhead configurations after switching from console to X and vica versa. For that reason I've always disliked the fact that rhgb was indeed supporting dualhead (which I noticed because during the boot I could move my mouse from one screen to the other). I wonder whether or not it would be possible to bypass any switching from rhgb to the X session used for gdm. What is so wrong with the X11 instance created for the bootup? Why shut it down and restart it for gdm? So or your graphical setup fails and you boot in text, or your graphical setup succeeds and once that X-server is started, it remains running. Why not? (I don't see the reason for that one flikker from graphical boot to console to graphical login-screen). the symbolic link doesn't sound a good idea to me. rhgb will use /etc/rhgb/xorg.conf only if the file is present, otherwise it will let X use the default configuration file whatever it happens to be. The symlink sounds like a recipe for a disaster. The X11 created for the bootup cannot be reused because at the moment it is started from a tempfs memory filesystem because x.org need a filesystem mounted read-write to start and when rhgb start you only have root mounted read-only available. read /usr/share/doc/rhgb-xxx/HOW_IT_WORKS to try to get some basic context needed before making suggestions. Daniel copying the file to /etc/rhgb/ didn't solve the problem here. I can, however, start multiple X instances and switch to them. I can shutdown and restart X manually with no problems. But I can't bootup the system using rhgb. It's crashing during the switch to the new X instance. The last message I can see is about starting the HAL-deamon (in rhgb). Oh wait, I can't switch to a console-window (nor can go back to X11). It's very unstable. When I press alt+ctrl+f1 (for example), the mouse/X11/keyboard freezes. When I use another host to login using ssh, I can killall X and init 5 to get everything back to normal. Note that I am using the radeon xorg driver as shipped with Fedora Core 3 (I am not using a thirth party driver). I am experiencing the same problem. I have an ATI Radeon 7000 dual head configuration. rhgb-0.15.1-1.FC3 is installed. Using the suggestion above of creating an /etc/rhgb/xorg.conf file with a single head configuration has circumvented the problem for me. I am also having this problem with a radeon 7500 and dual head. Note that I also have a dualhead config. I assume that this is a bug in the dualhead implementation for radeon? Switching from X to console and back to X seems to hang the keyboard and mouse and the instances of X. Yes, I believe Philip is correct. I have just up2date'd and gotten the rhgb-0.16.1-1.FC3 that was released today. It doesn't fix the problem. I have also completely removed rhgb from the grub.conf file and that way, I can boot up and my dualhead X will start and will work, but if I attempt to switch from X to console, the mouse/keyboard is immediately hung. So, if rhgb isn't specified in grub.conf and switching from X to the console still hangs the display/keyboard/mouse (although I can still SSH in and -- can it really be rhgb that is causing the problem? I have in fact, ssh'd in, become root, and killed off gdm, it restarts, but the display/mouse/keyboard is still hung tight, in fact the gdm-binary has spawned off the /etc/X11/gdm/XKeepsCrashing script to attempt to communicate with me, but the display is still stubornly showing the same X display from when I attempted to switch to the console. What other information would be helpful? I have confirmed (at least for my manifestation of this problem) that it is absolutely something in the dualhead support. Having reconfigured (system-config-display) my system to not use dual head support, I can boot up with rhgb and switch back and forth between X and the console to my heart's content... I did notice that when rhgb quit and X started up the first time that both screens were behaving as the one (may be normal, dunno), but after I switched to the console and back, only the one screen is showing the X system (although the second screen is still getting a signal of some sort because the light is green instead of orange). Experiencing the exact same problem here. Default radeon driver, dual head support causes rhgb to "hang". Even if I disable rhgb, using CTRL-ALT-SHIFT-F1, for example to get a console, X will will become unresponsive (still show the same window, but no mouse movement or keyboard control), and attempting to switch back to X with ALT-F8 does not work. CTRL-ALT-DELTE is still caught and reboots the system when this occurs though. If I reconfigure xorg.conf to only have one monitor, everything works fine. Since there is no working proprietary driver available from ATI for the newer Xorg releases yet, I hope someone is able to figure out a solution to this one. If you can't switch from X to a text console and back, then this is an xorg-x11 problem. The fact that recent rhgb runs 2 xservers at the last steps of the boot process is certainly related to the problem you're seeing. It can only be fixed by keeping the same X server from boot to the user session and that will require a lot of changes on both side, so don't expect a quick fix for this. Daniel *** Bug 139797 has been marked as a duplicate of this bug. *** For now, as a quickfix, I'd try to make sure that the rhgb xorg.conf file ain't trying to support dualhead configurations (and that there is one, in stead of using the xorg-generated config). I suppose this can easily be done by a script that checks whether or not there's two Device sections and/or the ServerLayout section is talking about multiple Screen's. In which case a text-dialogbox-warning could explain the problem (and if applicible to the situation of the user, how to get rid of it --perhaps some button that will revert the /etc/rhgb/xorg.conf to a standard non-dualhead setup--). I can imagine the frustration many (non investigative) users are having at this moment :-( It's not just rhgb. I've turned that off (which at least lets me boot properly), but switching to a text console is still unavailable and appears to "lock" the system (not really, since CTRL-ALT-DELETE still responds, but nothing is viewable on X except for the last viewed screen with no mouse). Definately an x.org problem with the radeon driver in dual head in my opinion, but I haven't had a chance after the freedesktop.org lists came back online to see if they have acknowledged the problem yet. The bug should probably be switched to x.org instead so we can get the proper maintainer on this one. If this does get turned into a "xorg locks up when switching to text console" bug, please can someone also look at bug 141500 which is reporting the same thing I also have the problem of FC3 screen locking up when rhgb is enabled (ctrl-alt-f1 does not work either). This (old) system operated correctly under FC2. When I loaded FC3, I erased all partitions and loaded all packages. 1) If I edit /etc/inittab to boot into run level 3, boot, and then manually do a /sbin/init 5, it works correctly. 2) If I remove "rhgb quiet" from /boot/grub/grub.conf, it works correctly. From /proc/cpuinfo: model name : Celeron (Mendocino) cpu MHz : 334.159 From /etc/X11/xorg.conf: Section "Device" Identifier "Videocard0" Driver "mga" VendorName "Videocard vendor" BoardName "Matrox Millennium G200" EndSection This old card only supports one monitor. Comment #20: Are you saying that if you start in run level 3 and then switch to run level 5 and do not have rhgb running that you are then able to successfully switch (via CTRL-ALT-F1) between the console and the XWindows display? Comment #21: I'm not sure whether or not in Mike Potts situation this works. In my situation, however, it ain't working. I can also startup an XServer manually (for example as root) using startx, switching to the console while the server remains running will make the system unresponsiveness. Killing the server or doing ALT-CTRL-BACKSPACE will, however, drop me successfully into the console. My situation is the ATI Radeon 9600 with the Acer TravelMate 8000 laptop. Using the default (with Fedora Core 3 shipped) radeon drivers (not the one which ATI is distributing, if any). Comment #20 / Comment #21 : Oops. Either 1 OR 2 will fix this problem, I do not need to do both. Those of us with dual-heads still have the problem even after 1 AND/OR 2 in #20. Even with rhgb completely disabled and starting from runlevel 3 and bringing up X, switching to the console will cause the X display to freeze. ALT-F8 from the "unviewable console" doesn't bring it back either, and CTRL-ALT-SHIFT-BACKSPACE is unresponsive, though CTRL-ALT-DELETE still starts up runlevel 6 like it should. I also had the same problem, though I do not have a dual head graphics card. I configured GDM to serve XDMCP and decided not to have any local X Server run to save memory. Configuration in gdm.conf which caused the problem: [xdmcp] Enable=true ... [servers] #0=Standard ... After I did this, X would freeze after the HAL service has successfully started (sshd worked). If I set the X server to run (ie. 0=Standard default configuration) the problem would go away. I presume there is some problem switching between the X session for boot (RHGB) and the new GDM process. I disabled GRAPHICS in /etc/sysconfig/init and all works fine now. Some more information... I've posted some comments over on bug 140435 and been looking into this on my Dell D600 with Radeon Mobility 9000 controller. I tried disabling DRI - no help, no joy. Tried disabling hardware acceleration. Problem eliminated. Graphics speeds (especially switching desktops or scrolling Mozilla) sucks, but I can now switch between X server instantiations on different VCs or switch to a terminal mode VC. Looks like the problem may be related to hardware acceleration with the dual head modes. I added this to the "Device" sections (Driver "radeon"): Option "NoAccel" "on" Now it works. Comment it out and restart X and X once again freezes if you try and switch away from an instantiation in a dual head mode. This issue also exists when you are running only one screen. My system freezes at any resolution above 640x480 with a Radeon 7000. Any updates on this issue? If i set it at 8bit color the login screen does come up at 1024x768, however during the gnome desktop startup it goes back to 640x480. Created attachment 109704 [details]
Xorg log file
I have the same issue with Ctl+Alt+F1 but only when using Xinerama. Since I
didn't see anyone else post their xorg log files, here's mine which clearly
shows a problem with the radeon driver resetting over and over when I do this.
X apparently freezing up is that it's using 100% of the CPU when this happens.
To everyone: Please upgrade to xorg-x11-6.8.2 from fc3-testing, reboot your system to cause a full hardware reset cycle to occur, then try to reproduce the problem initially reported. After doing this: To the original bug reporter: (and anyone else experiencing the 100% exact same issue reported in the initial comment. All other issues reported by other people here, may be completely unrelated bugs. We will focus our efforts here on the bug initially being reported.) Does disabling DRI by commenting out the Load "dri" part in the xorg.conf allow X to load after rebooting? If you disable acceleration by adding Option "noaccel" to the device section of the xorg.conf, does the problem go away after rebooting? To all other people who have added comments about possibly similar issues: If you are not experiencing the *exact* same issue reported by the original bug reporter, please file your own new bug report(s) to track the issues you are having. If it turns out it is the same issue later on, we can then resolve them as duplicates, however if they are different issues, when this bug gets closed, your problems may just get lost. I also very strongly recommend reporting the problems directly to X.Org using the freedesktop bugzilla, as this will maximize the number of X.org developers who see the issue, which may lead to a faster fix: http://bugs.freedesktop.org in the "xorg" component. Once you've reported the issue in X.Org bugzilla, paste the bug URL here and we will track the issue there as well. Thanks in advance. Setting status to "NEEDINFO", awaiting status update from using 6.8.2 and testing with information in comment #30 above. Having installed the 6.8.2 version from fc3-test, I will report that using rhgb no longer hangs my dual headed system. I can also use the Ctrl-Alt-F1 combination to switch from X11 back to the console. However, when I switch back to X11 (using the Alt-F7 combination), the second display is not refreshed. I have to log out of X and log back in to get the second display to work properly again. commenting out the 'load "dri"' line and restarting the X server (kill -1) did not change this new behavior. Adding 'Option "NoAccel"' to the two device sections that describe the two screens made no difference. Commenting out the load dir and having the NoAccel option set for both screens made no difference. So, the rhgb problem is fixed for me. However, there are still problems with dual head support on the Radeon card. Frank: Thanks for the update. Please report the new bug you're experiencing in a new bug report in X.Org bugzilla at http://bugs.freedesktop.org in the "xorg" component, with the full details, and attach your X server log and config file to the bug report. If you file a tracking bug in our bugzilla and paste the URL to the X.Org bug report in the tracking bug, we'll track it in the upstream bugzilla as well. That will maximize the number of eyes on the problem, and expediate a resolution. Thanks in advance. Setting status to "RAWHIDE", although a new errata for FC3 will be out in the next week roughly with this as well. Please reopen the bug if the original problem recurs, and we'll reinvestigate. Thanks again everyone! |