Bug 245522 - System locks up when logging out of Gnome.
System locks up when logging out of Gnome.
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: X/OpenGL Maintenance List
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-24 18:33 EDT by Rodd Clarkson
Modified: 2008-08-02 19:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-15 10:19:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Rodd Clarkson 2007-06-24 18:33:54 EDT
Description of problem:

When I try to log out of Gnome, the desktop blanks to just the back ground and
then it stops.  The mouse pointer moves, but the keyboard seems unfunctional
(the caps lock light doesn't toggle) and hard disk activity ceases.  The only
option you're left with is to hold down the power button (I'm on a laptop).

It doesn't seem to matter how long you're logged in for.  If you start the
desktop and then log out it locks.  If I use if for a couple of days (including
suspends and resumes) it still locks.

I haven't tried logging out using CTRL-ALT-BKSP so will try this after filling
this bug, but obviously, this isn't how you should be logging out.

It's likely that this isn't gnome-session, but it's a starting point.

I'm currently using fedora-updates-testing and I'm up-to-date.  This problem has
been around for at least a week (and maybe a couple) for me, but between not
filling bugs because I forget when I restart my laptop, or because I was hoping
that it would resolve itself (it happens) I haven't (but should have).  It may
even date back to my fresh install of F7, but I couldn't confirm this without a
reinstall which is problematic.
Comment 1 Rodd Clarkson 2007-06-24 18:49:47 EDT
Okay, CTRL-ALT-BKSP also locks up too.

However, my network is still alive so I'm able to log in using ssh and have a
look around.

Killing all my processes didn't have any affect.

However, top shows Xorg consuming 99% of CPU and a `sudo kill -9 <pid for Xorg>`
kills the Xorg process and a new logging is offered.

ADMISSION:  I'm using the nvidia drivers from livna. Since this appears to be an
Xorg issue I suspect that we aren't going to go much further with this until
such time as we can find someone with the same problem who isn't using these
drivers.

I've change the Component accordingly.
Comment 2 Bas Driessen 2007-06-24 19:38:48 EDT
I am having exact the same problem. I am on Fedora 7 x86_64. I noticed that if I
DISable the "Enable Software Sound Mixing (ESD)" and "Play System Sounds" in the
Sound Preferences (System/Preference/Hardware/Sound), logging in and out works OK.

I also have the nvidia drivers from livna.

I can not access the box anymore via ssh when it freezes up, so this part seem
to be different.


Comment 3 Ray Strode [halfline] 2007-06-25 10:19:54 EDT
I'm going to reassign this to the Xorg team.  Would one of you mind trying the
open source nvidia drivers to see if you still see the issue?
Comment 4 Ray Strode [halfline] 2007-06-25 10:21:47 EDT
Also, are you running compiz?  If so, does running metacity make the problem go
away?  This may be a duplicate of bug 244572.
Comment 5 Matěj Cepl 2007-06-25 17:56:02 EDT
(In reply to comment #3)
> I'm going to reassign this to the Xorg team.  Would one of you mind trying the
> open source nvidia drivers to see if you still see the issue?

I am sorry, we won't. The standard info follows:

Thanks for the report. We are sorry that we cannot help you with your problem,
but we are not able to support binary-only drivers. If you would be able to
reproduce this issue using only open source software, please, reopen this bug
with the additional information, but in meantime I have no choice than to close
this bug as CANTFIX (because we really cannot fix it).

For users who are experiencing problems installing, configuring, or using the
unsupported 3rd party proprietary "nvidia" video driver, Nvidia provides
indirect customer support via an online web based support forum.  Nvidia
monitors these web forums for commonly reported problems and passes them on to
Nvidia engineers for investigation.  Once they've isolated a particular problem,
it is often fixed in a future video driver update.

The NVNews Nvidia Linux driver forum is located at:

    http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14

Once you have reported this issue in the Nvidia web forums, others who may have
experienced the particular problem may be able to assist.  If there is a real
bug occuring, Nvidia will be able to determine this, and will likely resolve the
issue in a future driver update for the operating system releases that they
officially support.

While Red Hat does not support the proprietary nvidia driver, users requiring
technical support may also find the various X.Org, XFree86, and Red Hat mailing
lists helpful in finding assistance:

X.Org mailing lists:
    http://www.freedesktop.org/XOrg/XorgMailingLists

XFree86 mailing lists:
    http://www.xfree86.org/sos/lists.html

Red Hat mailing lists:
    https://listman.redhat.com/mailman/listinfo
Comment 6 Rodd Clarkson 2007-06-25 20:47:33 EDT
Nice, close the bug before someone has even had a chance to report whether this
is a problem using the open source nvidia driver.  Really slick.  Maybe this is
why so many people seem reluctant to mention the nvidia driver they use.

As it turns out, I have tried the nv driver and it logs out fine, so in this
case I understand the action taken, however...

While I understand that fedora won't support issue with the nvidia driver, it
might actually be worth confirming that this is nvidia driver related before
taking this action.  A simple request to try the nv (or nouveau) driver and the
willingness to wait until such time that it's been tested would be reasonable.

Yes, we could reopen this bug if it was an issue, but as I say, it would appear
many people seem reluctant to mention their use of the nvidia driver because the
knee jerk reaction is to close bugs before it's even been confirmed that it's
the nvidia driver that's at fault.

Taking the time to just confirm this would encourage people to file bugs, and it
 doesn't require any action from developers (other than a stock "could you test
this with the nv drivers" text paste) until it's confirmed.

Enough ranting.
Comment 7 Bas Driessen 2007-06-25 21:03:14 EDT
Couldn't agree more Rodd. The last couple of days were the first time that I
became a bit more active in reporting issues in the Fedora bugzilla system, but
I got similar rejective responses. I am going to move to the back seat again and
just use the system and let the "mighty inner circle people" play with their toy.  



Comment 8 Matěj Cepl 2007-06-26 07:56:13 EDT
For that retesting with open source drivers we have this in the official blurb
"If you would be able to reproduce this issue using only open source software,
please, reopen this bug with the additional information," However, our
experience is that people usually don't want to bother with installation of nv
driver (I don't argue with them -- "nv driver -- making SuperVGA out of your
SuperDuper ultraExpensive card again!" ;-)).

Probably should have more hope for our users and yes I have that stock test
available as well ;-)). Sorry, will try next time.

So, Bas, could YOU reproduce this with nv driver (or nouveau, but that's still
alpha-quality and incomplete)?
Comment 9 Robin Laing 2007-07-27 01:26:16 EDT
I want to add to this.

Since installing F7, I have had issues with both the nv and nvidia binary
drivers.  I have followed the nvidia bug list and also checked other lists and I
am seeing a common problem with both ATI and nvidia binary drivers on f7.

Bug 213227 is similar to the issues that I keep reading about.

I have tried to use the nv driver but it won't allow my kids to play games and
is so slow.

As for the issue.  There is a problem in the Xorg or kernel that has changed
between kernel-2.6.21-1.3228.fc7 and kernel-2.6.22.1-27.fc7.  I say this because
my symptoms have changed (for the better) with this issue.  Also the problems
remain with different versions of the nvidia drivers.

As I now have a way to get information without crashing, I will test the nv
driver and see if I can push it to generate the same strace errors.

In the above bug that I referenced, I copied what someone had posted to the
nvidia site.  It had to do with cfq in the kernel.  Is it important?  I don't
know but if I remember correctly, there was a change to the cfq in the latest
kernel and my symptoms changed.

I will try the nv driver and add any more info that I can.
Comment 10 Robin Laing 2007-07-27 02:03:55 EDT
Now I just tired the nv driver and I didn't lock up but then with the latest
kernel I don't lock up with the nvidia driver either.

Now in my test for both cards I run mplayer from teh command line.  I watch top
with the -d flag set for 1 second.  If I speed up mplayer using the } key, I
will see mplayer % usage increase but Xorg increases much more.  Sometimes to
50% and stays in the 30 to 40% range.

I also ran strace during this and I get more of these when the Xorg process
takes up more CPU time.

This is from the nv driver.

read(28, "\214\23\r\0A\0\0\0\1\0\300\2\6\0\300\2\7\0\300\2YV12\0"..., 4096) = 52
gettimeofday({1185514771, 138796}, NULL) = 0
gettimeofday({1185514771, 138848}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
gettimeofday({1185514771, 140394}, NULL) = 0
select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28]
, NULL, NULL, {0, 125000}) = 1 (in [28], left {0, 124000})
gettimeofday({1185514771, 141955}, NULL) = 0
read(28, "\214\23\r\0A\0\0\0\1\0\300\2\6\0\300\2\10\0\300\2YV12\0"..., 4096) = 5
2
gettimeofday({1185514771, 142081}, NULL) = 0
gettimeofday({1185514771, 142143}, NULL) = 0
read(28, 0x891a418, 4096)               = -1 EAGAIN (Resource temporarily unavai
lable)
gettimeofday({1185514771, 143582}, NULL) = 0
select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28]
, NULL, NULL, {0, 122000}) = 1 (in [28], left {0, 112000})
gettimeofday({1185514771, 153403}, NULL) = 0

And 
read(28, "\214\23\r\0A\0\0\0\1\0\300\2\6\0\300\2\10\0\300\2YV12\0"..., 4096) = 1
04
gettimeofday({1185514771, 179584}, NULL) = 0
gettimeofday({1185514771, 179635}, NULL) = 0
gettimeofday({1185514771, 181031}, NULL) = 0
gettimeofday({1185514771, 181077}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
gettimeofday({1185514771, 183037}, NULL) = 0
select(256, [1 3 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28]
, NULL, NULL, {0, 82000}) = 1 (in [28], left {0, 77000})
gettimeofday({1185514771, 189678}, NULL) = 0
read(28, "\214\23\r\0A\0\0\0\1\0\300\2\6\0\300\2\10\0\300\2YV12\0"..., 4096) = 5
2

Now with the nvidia driver I get similar response to strace on the xorg process.

gettimeofday({1185512650, 300452}, NULL) = 0
gettimeofday({1185512650, 300492}, NULL) = 0
gettimeofday({1185512650, 300533}, NULL) = 0
gettimeofday({1185512650, 300573}, NULL) = 0
gettimeofday({1185512650, 300614}, NULL) = 0
gettimeofday({1185512650, 300654}, NULL) = 0
gettimeofday({1185512650, 300695}, NULL) = 0
gettimeofday({1185512650, 300735}, NULL) = 0
gettimeofday({1185512650, 300776}, NULL) = 0
gettimeofday({1185512650, 300821}, NULL) = 0
gettimeofday({1185512650, 300967}, NULL) = 0
read(37, "\214\23\r\0E\1\0\0\1\0\200\2\6\0\200\2\7\0\200\2YV12\0"..., 4096) = 52
gettimeofday({1185512650, 302864}, NULL) = 0
gettimeofday({1185512650, 302914}, NULL) = 0
gettimeofday({1185512650, 302961}, NULL) = 0
gettimeofday({1185512650, 303003}, NULL) = 0
  ...
gettimeofday({1185512650, 313010}, NULL) = 0
gettimeofday({1185512650, 313050}, NULL) = 0
gettimeofday({1185512650, 313090}, NULL) = 0
gettimeofday({1185512650, 313130}, NULL) = 0
gettimeofday({1185512650, 313170}, NULL) = 0
gettimeofday({1185512650, 313210}, NULL) = 0
read(37, 0xa144498, 4096)               = -1 EAGAIN (Resource temporarily unavai
lable)
select(256, [1 3 9 10 13 15 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 3
6 37 38 41 42 43 44], NULL, NULL, NULL) = 2 (in [3 41])
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
read(3, "\340\35\340\35", 64)           = 4
rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
read(41, "5\30\4\0\341\34\0\3C\16\0\3\202\2\232\1\235\4\5\0\342\34"..., 6520) = 
2776
gettimeofday({1185512650, 315016}, NULL) = 0
gettimeofday({1185512650, 315072}, NULL) = 0
gettimeofday({1185512650, 315113}, NULL) = 0
gettimeofday({1185512650, 315154}, NULL) = 0
gettimeofday({1185512650, 315194}, NULL) = 0
gettimeofday({1185512650, 315235}, NULL) = 0

Again, I am using all the same software and hardware except the change between
the nv and nvidia drivers.

I have tried various xorg.conf files as well as different versions of the nvidia
driver.  As stated before, the latest kernel and updates have made the problem
more of a loss of response until the xorg decides to respond to a key or mouse
click or the process that is using the display quits.  Before the system would
just freeze in logout or playing PPRacer or Supertuxkart.

I have not had a freeze since that has allowed me to test if ctrl+alt+bksp works
but as I don't have any keyboard input, I really doubt that it would.

Also, when the xorg process increases, the top display wouldn't update but the
mplayer display was still working.  strace was writing to a file and the mplayer
would stop while the write was taking place.

As for not wanting to look at issues with binary drivers.  This could be enough
for me to look at a different version of Linux.  With kids, I need 3D support
and the choices for video cards is very limited, especially in laptops.

FC4 worked perfectly on this computer and I am starting to regret the
installation of F7.  I have left FC4 on the laptop due to this issue as I need
to use the nvidia driver on that computer as well.
Comment 11 Andy Lawrence 2007-08-07 21:44:15 EDT
Same problem here, all OSS installed via yum.  I'm using nvidia and compiz with
the 2.6.22.1-41.fc7 Kernel.


Comment 12 Andy Lawrence 2007-08-07 21:47:24 EDT
Sorry, my bad, I'm also using the Livna driver..
Comment 13 Matěj Cepl 2007-08-15 10:19:07 EDT
It is certainly not your bad, just we really cannot help you, but we are not
able to support binary-only drivers. If you would be able to reproduce this
issue using only open source software, please, reopen this bug with the
additional information, but in meantime I have no choice than to close this bug
as CANTFIX (because we really cannot fix it).

For users who are experiencing problems installing, configuring, or using the
unsupported 3rd party proprietary "nvidia" video driver, Nvidia provides
indirect customer support via an online web based support forum.  Nvidia
monitors these web forums for commonly reported problems and passes them on to
Nvidia engineers for investigation.  Once they've isolated a particular problem,
it is often fixed in a future video driver update.

The NVNews Nvidia Linux driver forum is located at:

    http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14

Once you have reported this issue in the Nvidia web forums, others who may have
experienced the particular problem may be able to assist.  If there is a real
bug occuring, Nvidia will be able to determine this, and will likely resolve the
issue in a future driver update for the operating system releases that they
officially support.

While Red Hat does not support the proprietary nvidia driver, users requiring
technical support may also find the various X.Org, XFree86, and Red Hat mailing
lists helpful in finding assistance:

X.Org mailing lists:
    http://www.freedesktop.org/XOrg/XorgMailingLists

XFree86 mailing lists:
    http://www.xfree86.org/sos/lists.html

Red Hat mailing lists:
    https://listman.redhat.com/mailman/listinfo

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