Bug 679326 - Shell only works on second try (likely due to too-short timeout on gnome-session-is-accelerated)
Shell only works on second try (likely due to too-short timeout on gnome-sess...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-session (Show other bugs)
15
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Triaged
: 675481 679488 679685 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-22 04:32 EST by Sandro Mathys
Modified: 2011-04-06 23:51 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-06 23:51:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dmesg output after the first boot with drm.debug=0x04 (124.49 KB, text/plain)
2011-02-22 04:33 EST, Sandro Mathys
no flags Details
syslog from after the first boot with drm.debug=0x04 (275.61 KB, text/plain)
2011-02-22 04:34 EST, Sandro Mathys
no flags Details
Xorg.0.log from after the first boot with drm.debug=0x04 (89.15 KB, text/plain)
2011-02-22 04:34 EST, Sandro Mathys
no flags Details
dmesg output after a later boot with drm.debug=0x04 (124.48 KB, text/plain)
2011-02-22 04:39 EST, Sandro Mathys
no flags Details
syslog from after a later boot with drm.debug=0x04 (1018.88 KB, text/plain)
2011-02-22 04:40 EST, Sandro Mathys
no flags Details
Xorg.0.log from after a later boot with drm.debug=0x04 (89.15 KB, text/plain)
2011-02-22 04:40 EST, Sandro Mathys
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 641992 None None None Never

  None (edit)
Description Sandro Mathys 2011-02-22 04:32:49 EST
Description of problem:
Using a LiveUSB pen I'm working on the nouveau test day. There I noticed a very strange behavior. At the very first time I boot the pen, I get the Gnome 3 fallback. When I boot the pen another time, I'll get the Gnome 3 Shell.

I didn't make any changes, so it's a self-repairing problem. Probably one'd always get the fallback if you use a CD or no overlay.

Version-Release number of selected component (if applicable):
gfx_test_week_20110221_x86-64.iso

How reproducible:
Twice so far

Steps to Reproduce:
1. Setup the iso on a USB pen with an overlay
2. Boot once -> fallback
3. Boot twice -> Shell

Additional info:
HW: http://www.smolts.org/client/show/pub_acfad2d6-9081-4c20-87da-12c0776da4e3
Comment 1 Sandro Mathys 2011-02-22 04:33:50 EST
Created attachment 480077 [details]
dmesg output after the first boot with drm.debug=0x04
Comment 2 Sandro Mathys 2011-02-22 04:34:18 EST
Created attachment 480078 [details]
syslog from after the first boot with drm.debug=0x04
Comment 3 Sandro Mathys 2011-02-22 04:34:38 EST
Created attachment 480079 [details]
Xorg.0.log from after the first boot with drm.debug=0x04
Comment 4 Sandro Mathys 2011-02-22 04:39:51 EST
Created attachment 480081 [details]
dmesg output after a later boot with drm.debug=0x04
Comment 5 Sandro Mathys 2011-02-22 04:40:16 EST
Created attachment 480082 [details]
syslog from after a later boot with drm.debug=0x04
Comment 6 Sandro Mathys 2011-02-22 04:40:41 EST
Created attachment 480084 [details]
Xorg.0.log from after a later boot with drm.debug=0x04
Comment 7 Paul W. Frields 2011-02-22 08:48:50 EST
I'm seeing the same symptoms on a G86 [GeForce 8400M GS] [10de:0427] (rev a1): http://www.smolts.org/client/show/pub_712c4340-5618-4510-a7d9-ce737712c29c

I'm not attaching output here so as not to munge up this bug accidentally.
Comment 8 John Reiser 2011-02-22 10:19:14 EST
I see the same symptoms with G84 (GeForce 8400 GS] pci 10de:0404 (rev a1).
smolt d3e3c69d-c3e0-48ca-bb91-868d24470366.
Comment 9 John Reiser 2011-02-22 10:51:36 EST
Crash of gnome-user-share seems to be related: crash of g-u-s implies no Gnome3 shell.  Abrt > Report insists on downloading 179MB, including gcc-debuginfo (the debuginfo of the _compiler_), which fills up the LiveCD drive.
Comment 11 John Reiser 2011-02-22 12:20:44 EST
Same problem with 05:00.0 VGA compatible controller [0300]: nVidia Corporation NV43 [GeForce 6600] [10de:0141] (rev a2), including same interaction with gnome-user-share.
Comment 12 John Reiser 2011-02-22 13:41:37 EST
Workaround: log out (System > Log out liveuser...) then log back in.  Logging back in seems to require clicking the Login button; typing '\r' did not work for me.  But I got Gnome Shell instead of the fallback.
Comment 13 James Laska 2011-02-22 17:46:44 EST
Feb 22 10:38:05 localhost abrt[1617]: saved core dump of pid 1611 (/usr/libexec/gnome-user-share) to /var/spool/abrt/ccpp-1298389084-1611.new/coredump (1318912 bytes)
Feb 22 10:38:05 localhost abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1298387534-1824)
Feb 22 10:38:05 localhost abrtd: Deleting crash ccpp-1298389084-1611 (dup of ccpp-1298387534-1824), sending dbus signal
Feb 22 10:38:09 localhost abrt[1840]: saved core dump of pid 1651 (/usr/libexec/notification-daemon) to /var/spool/abrt/ccpp-1298389089-1651.new/coredump (21270528 bytes)
Feb 22 10:38:09 localhost abrtd: Directory 'ccpp-1298389089-1651' creation detected
Feb 22 10:38:09 localhost abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1298388027-1650)
Feb 22 10:38:09 localhost abrtd: Deleting crash ccpp-1298389089-1651 (dup of ccpp-1298388027-1650), sending dbus signal

I'm guessing that the gnome-user-share problem is where we should start tackling this issue.  That issue is already filed as bug#677555

When logging into gnome-shell works okay, does gnome-user-share still crash?  Meaning, is the gnome-user-share crash causing the login problem?
Comment 14 John Reiser 2011-02-22 18:36:01 EST
On four different machines each with a different model NV card (6600, 8400GS, 9400GS, GT210), what I see is: gnome-user-share crashes if and only if the fallback gets invoked (and not Gnome shell.)  The workaround (log out, log back in (do not reboot)) always works for me.
Comment 15 Andre Robatino 2011-02-23 01:43:57 EST
I'm booting from an optical disc, and get fallback when logging in for the first time. Any later login (either logging out and back in, or logging in as a different user) gets Gnome shell. It doesn't matter whether I log in by clicking the Login button or by hitting Enter.

http://www.smolts.org/client/show/pub_e6c78f7d-d38c-47df-8f06-47696b5c01b3
Comment 16 MahMahoritos 2011-02-23 05:31:38 EST
*** Bug 679685 has been marked as a duplicate of this bug. ***
Comment 17 MahMahoritos 2011-02-23 05:33:58 EST
Have same problem on M92 [Mobility Radeon HD 4500 Series]

More info - https://bugzilla.redhat.com/show_bug.cgi?id=679685
Comment 18 Adam Williamson 2011-02-23 11:33:40 EST
*** Bug 679488 has been marked as a duplicate of this bug. ***
Comment 19 John Reiser 2011-02-23 11:52:19 EST
http://bugs.freedesktop.org/show_bug.cgi?id=641992
displays "Bug #641992 does not exist" so the External Tracker bug ID on this bugzilla report does not help.
Comment 20 Adam Williamson 2011-02-23 12:32:56 EST
that's because I'm an idiot, and it's a GNOME bug. =) fixing
Comment 21 Rob Whalley 2011-02-25 06:08:46 EST
Same issue working from the test day live CD on a Samsung NC10 netbook (external USB DVD-RW): http://www.smolts.org/client/show/pub_6addbf83-d0f4-47c5-8219-d88d2c00e5aa

Behaviour of fallback as per John Reiser's comments above: "gnome-user-share crashes if and only if the fallback gets invoked (and not Gnome shell.)"

For me this happened about half the time, not always on the first login, sometimes on subsequent logins, but logging out and back into Gnome would eventually load the shell properly.

Fallback always accompanied by gnome-user-share crash: https://bugzilla.redhat.com/show_bug.cgi?id=677555
Comment 22 Horst H. von Brand 2011-03-01 10:54:33 EST
Now here (rawhide, not branched 15; x86_64) I always get fallback

gnome-session-2.91.90-2.fc15.x86_64
xorg-x11-drv-nouveau-0.0.16-21.20110224gitbc5dec2.fc16.x86_64
Comment 23 Sandro Mathys 2011-03-01 11:12:58 EST
That's funny, in contrast to what Horst describes: I haven't seen fallback on the system in questions for quite a while - I'd even think it's always been Shell for nearly a week now.

But there's a difference between my initial report and the situation now: I no longer use the usb pen but installed the system instead. So my initial report might be a live system related bug of sorts.
Comment 24 Adam Williamson 2011-03-01 11:49:05 EST
sandro: live system boot is usually going to be slower than an installed system boot, and this is a highly speed-dependent bug...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 25 Sandro Mathys 2011-03-01 12:38:17 EST
Adam: I haven't read anything in this bug so far that says "this is highly speed-dependent" - but now you've said it, it pretty obviously is - so this is some sort of a race condition on the live media again. Just as with bug 679486...
Comment 26 Horst H. von Brand 2011-03-01 12:59:26 EST
(In reply to comment #23)
> That's funny, in contrast to what Horst describes: I haven't seen fallback on
> the system in questions for quite a while - I'd even think it's always been
> Shell for nearly a week now.
> 
> But there's a difference between my initial report and the situation now: I no
> longer use the usb pen but installed the system instead. So my initial report
> might be a live system related bug of sorts.

My experience: I (briefly) used Gnome shell up to around February 3 or 4. Then GDM and Gnome went south here. I went on vacation, using XDM and XFCE afterwards from February 12 or so. Tried Gnome on and off until today, no way to get it working. When I tried the one for the graphics test, Gnome from disk still didn't work for my account, and the on the LiveCD had to be restarted to go to the shell. Now Gnome fallback works from disk (GDM is still shot), and I was informed that my graphics card wasn't up to the task the first time I started Gnome again. I can't get Gnome shell (Perhaps the logout/login process is diferent here? It doesn't work started from XDM?).
Comment 27 Adam Williamson 2011-03-01 20:53:39 EST
sandro: it's not, strictly speaking, a race condition, it's just a timeout. gnome-session-is-accelerated, which is a test script to figure out if the current environment (graphics card, driver, mesa etc) can support GNOME Shell, has an arbitrary timeout to stop it taking too long; after the timeout expires it assumes the test failed and goes to fallback mode. The current timeout is very short, so it's being hit in many cases where, if it were a bit longer, the test would complete and pass successfully.

There's more detail in the upstream bug.

horst: if you can't get Shell by running gnome-shell --replace , then this is not your bug. This bug is only for the case where the fallback mode kicks in because of the test timeout issue noted above, but actually Shell would work fine.
Comment 28 Adam Williamson 2011-03-07 18:45:46 EST
*** Bug 675481 has been marked as a duplicate of this bug. ***
Comment 29 Horst H. von Brand 2011-03-08 14:59:49 EST
(In reply to comment #27)
> horst: if you can't get Shell by running gnome-shell --replace , then this is
> not your bug. This bug is only for the case where the fallback mode kicks in
> because of the test timeout issue noted above, but actually Shell would work
> fine.

I had the exact same symptoms with the live CD. Now, with the installed rawhide (16) system I only get fallback, and:

$ gnome-shell --replace
failed to create drawable
Window manager error: Unable to initialize Clutter.
Cannot register the panel shell: there is already one running.
compiz (core) - Error: Screen 0 on display ":0.0" already has a window manager; try using the --replace option to replace the current window manager.
Window manager warning: Failed to load theme "Nodoka": Failed to find a valid file for theme Nodoka
Comment 30 Horst H. von Brand 2011-03-15 14:33:30 EDT
Fixed here now (same machine, clean install of Fedora ~~-> 15)
Comment 31 Matthias Clasen 2011-04-06 23:51:47 EDT
Considering this fixed, we do have longer timeouts now.

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