Bug 679326

Summary: Shell only works on second try (likely due to too-short timeout on gnome-session-is-accelerated)
Product: [Fedora] Fedora Reporter: Sandro Mathys <sandro>
Component: gnome-sessionAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: airlied, ajax, anross, awilliam, dwmw2, jlaska, jmccann, jreiser, mahmahoritos, mail, mclasen, nekohayo, nphilipp, robatino, rstrode, stephane.demurget, stickster, vonbrand
Target Milestone: ---Keywords: CommonBugs, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://fedoraproject.org/wiki/Common_F15_bugs#GNOME_Fallback_mode_is_used_even_on_systems_which_can_run_Shell
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-07 03:51:47 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:
Attachments:
Description Flags
dmesg output after the first boot with drm.debug=0x04
none
syslog from after the first boot with drm.debug=0x04
none
Xorg.0.log from after the first boot with drm.debug=0x04
none
dmesg output after a later boot with drm.debug=0x04
none
syslog from after a later boot with drm.debug=0x04
none
Xorg.0.log from after a later boot with drm.debug=0x04 none

Description Sandro Mathys 2011-02-22 09:32:49 UTC
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 09:33:50 UTC
Created attachment 480077 [details]
dmesg output after the first boot with drm.debug=0x04

Comment 2 Sandro Mathys 2011-02-22 09:34:18 UTC
Created attachment 480078 [details]
syslog from after the first boot with drm.debug=0x04

Comment 3 Sandro Mathys 2011-02-22 09:34:38 UTC
Created attachment 480079 [details]
Xorg.0.log from after the first boot with drm.debug=0x04

Comment 4 Sandro Mathys 2011-02-22 09:39:51 UTC
Created attachment 480081 [details]
dmesg output after a later boot with drm.debug=0x04

Comment 5 Sandro Mathys 2011-02-22 09:40:16 UTC
Created attachment 480082 [details]
syslog from after a later boot with drm.debug=0x04

Comment 6 Sandro Mathys 2011-02-22 09:40:41 UTC
Created attachment 480084 [details]
Xorg.0.log from after a later boot with drm.debug=0x04

Comment 7 Paul W. Frields 2011-02-22 13:48:50 UTC
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 15:19:14 UTC
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 15:51:36 UTC
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 17:20:44 UTC
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 18:41:37 UTC
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 22:46:44 UTC
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 23:36:01 UTC
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 06:43:57 UTC
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 10:31:38 UTC
*** Bug 679685 has been marked as a duplicate of this bug. ***

Comment 17 MahMahoritos 2011-02-23 10:33:58 UTC
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 16:33:40 UTC
*** Bug 679488 has been marked as a duplicate of this bug. ***

Comment 19 John Reiser 2011-02-23 16:52:19 UTC
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 17:32:56 UTC
that's because I'm an idiot, and it's a GNOME bug. =) fixing

Comment 21 Rob Whalley 2011-02-25 11:08:46 UTC
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 15:54:33 UTC
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 16:12:58 UTC
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 16:49:05 UTC
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 17:38:17 UTC
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 17:59:26 UTC
(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-02 01:53:39 UTC
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 23:45:46 UTC
*** Bug 675481 has been marked as a duplicate of this bug. ***

Comment 29 Horst H. von Brand 2011-03-08 19:59:49 UTC
(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 18:33:30 UTC
Fixed here now (same machine, clean install of Fedora ~~-> 15)

Comment 31 Matthias Clasen 2011-04-07 03:51:47 UTC
Considering this fixed, we do have longer timeouts now.