Red Hat Bugzilla – Bug 139086
System hangs on logout
Last modified: 2007-11-30 17:10:54 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: On a fresh install of Fedora Core 3 logging out causes the machine to start flickering the monitor endlessly and never returns to the login prompt. The machine is completely hung at this point. I can't get to a text console with Ctrl+Alt+F1. Attempts to connect with ssh from another machine on the network don't even find the FC3 machine (nor does ping). This is hardware I've been running Linux on successfully since RH8, with upgrades at each major release (RH9, FC1, FC2, and now FC3), with nothing resembling this behavior ever before. I first upgraded from FC2 to FC3, when I ran into the problem, at which point I recycled the power, backed up the machine, wiped it and did a fresh install of FC3. This hasn't solved the problem. I really have no idea what component to select for this report. I picked udev at random, but who knows? This is a 600MHz Pentium 3, and I'll be happy to report back with any information about attached hardware (nothing exotic) that anyone thinks will be relevant. I am able to run telinit 3 to get back to text-only and then telinit 5 to resume X without problems. Version-Release number of selected component (if applicable): udev-039-10.FC3.1 How reproducible: Always Steps to Reproduce: 1. Click 'Actions' button 2. Select 'Log Out' 3. Click 'OK' Actual Results: Machine hangs. Expected Results: The login screen should be presented. The machine should not hang. Additional info:
same thing happens for me. kossler@physics.wm.edu
I hate it, if people blame udev per random!!
Created attachment 107256 [details] Log found after a crash
> I hate it, if people blame udev per random!! I didn't say I was blaming udev. What I actually wrote was "I really have no idea what component to select for this report." If there's a way to file a bug report without selecting a component, I'd be glad to have you point it out to me. If there's a component that means "I don't know which component is causing the failure" buried in the 432KB page that comes up when you click on the help for component assignment I'm afraid I missed it. If you prefer that users not report problems if they don't know which component is responsible for those problems, then perhaps you need a vacation. :->}
For the future, just so you know (although I admit completely that it is non-obvious to anyone who hasn't been directly informed), is to choose the "distribution" component when unsure what component is at fault. This goes to our technical lead, who is rather good at determining the most likely faulty component and reassigning it to that component for investigation. Another benefit of doing this is to ensure one's bug actually gets looked at, because due to bug volume, sometimes misfiled bugs fall between the cracks. Also the developer who ends up getting a misfiled bug report may themselves not know what the right component is, resulting sometimes in a bit of a game of "pass the hot potato", which isn't helpful to the original reporter. ;o)
Looking at your attached info, I only see one thing that jumps out at me: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: Open failed While drmOpenDevice later does succeed, it seems perhaps there is a bug in the kernel mga DRM code there, which eventually goes away. I've carbon copied our kernel maintainer for comment about that as he's more likely to know about the kernel side of DRM than I. Is this log file /var/log/Xorg.0.log from while the X server is running, or was it backed up after the problem, and before you started the X server up again? I ask, because often people have a crash, then reboot or restart X, which wipes out /var/log/Xorg.0.log with the new server's log, so it never shows any errors that may have caused the problem. If this is the case, the old log file, the real one from the crash, is renamed to .log.old, and should be attached. Also, please attach the /var/log/messages file including all text from initial boot onward until the crash occurs, as that often yields many clues useful for debugging, which may be non-obvious. Please try disabling DRI by commenting out the 'Load "dri"' option from the xorg.conf config file. If this resolves the problem, please update the report ot indicate that too. I notice your system is SMP also. Another test that would be useful is to boot into the uniprocessor (UP) kernel so it's only using a single processor, but keeping DRI enabled. If this makes the problem go away, this could be an DRI+SMP problem that seems to be happening for a lot of people using multiprocessor on different hardware, and seems to point to a generic DRI locking issue of some sort that hasn't yet been determined. Knowing if DRI works on this card on this system with one CPU would be greatly useful. Thanks in advance.
Since this bugzilla report was filed, there have been several major updates to the X Window System, which may resolve this issue. Users who have experienced this problem are encouraged to upgrade to the latest version of Fedora Core, which can be obtained from: http://fedora.redhat.com/download If this issue turns out to still be reproduceable in the latest version of Fedora Core, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to "CURRENTRELEASE".