Bug 139086 - System hangs on logout
System hangs on logout
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-12 15:52 EST by Bob Kline
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-11 15:14:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log found after a crash (38.83 KB, text/plain)
2004-11-22 18:02 EST, Alain Coron
no flags Details

  None (edit)
Description Bob Kline 2004-11-12 15:52:15 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:
Comment 1 kossler 2004-11-13 21:02:49 EST
same thing happens for me. kossler@physics.wm.edu
Comment 2 Harald Hoyer 2004-11-15 06:24:34 EST
I hate it, if people blame udev per random!!
Comment 3 Alain Coron 2004-11-22 18:02:24 EST
Created attachment 107256 [details]
Log found after a crash
Comment 4 Bob Kline 2004-11-22 21:30:41 EST
> 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. :->}
Comment 5 Mike A. Harris 2004-11-23 04:07:27 EST
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)
Comment 6 Mike A. Harris 2004-11-23 04:16:13 EST
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.
Comment 7 Mike A. Harris 2005-04-11 15:14:57 EDT
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".

Note You need to log in before you can comment on or make changes to this bug.