[Hardy] Race condition in Xgl startup process

I'm having a similar error in Hardy (cannot open display :1)
Could you elaborate on this patch please?
1) My guess is that the line about seahorse in your .xsession-error is unrelated. Correct?
2) Where in /usr/share/xserver-xgl/Xgl-session should the code you added above be pasted? Could you provide the contents of the previous and following lines?
I tried adding the commands between:
"...
verbose "Starting Xgl with options: " $XGL_ACCEL_OPTS $XGL_OPTS "\n"
$XGL_WRAPPER $XGL_DISPLAY $XGL_ACCEL_OPTS $XGL_OPTS &
DISPLAY=$XGL_DISPLAY"
and
"#Don't use Shift+Backspace as terminate_server
xmodmap -e "keycode 22 = BackSpace"
else
..."

But the patch did not seem to help. On logging in, the system just paused. Admittedly, I did not get the error in .xsession-errors, but Gnome did not load and the PC just waited. I had to disable Xgl (reinstating the file 'disable' in ~/.config/xserver-xgl) to login as usual.

If possible, please attach a copy of your Xgl-session that works.

My config:
Hardy
Compaq nc6230
ATI Mobility radeon

Thanks!

PS> Is your .xsession-error similar to Bug 174408 (https://bugs.launchpad.net/ubuntu/+bug/174408)?

Sorry, in the hurry I forgot to post the file. Here is the modified version of Xgl-session

The command "/usr/bin/seahorse-agent --execute /usr/bin/gnome-session " is passed as argument to the Xgl-session script and executed at the end.
If the display in $DISPLAY is not ready the command fails with "can't open display" and gnome-session is not executed.

Adding traces to this script, I've observed that the "exec $@" is executed _before_ the Xgl command in the wrapper script "Xgl-lockfile-wrapper" (except the first time you log in). In this case the session can't start because the display is not ready.

My .xsession-errors was similar to the one of Bug 174408.

The wait loop added to the startup script also solved the xmodmap error.

Great. I got Xgl to load on DISPLAY :1 using your Xgl-session attachment.
However, gnome (or for that matter KDE) refused to start. On entering login details, I can see the hard disk activity till Xgl loads, then it just stops with the human background and a busy pointer.
I noticed that if I run compiz from tty1 (# DISPLAY=:1 compiz &), compiz finds Xgl and loads without an error, but still no desktop.
However, if I run # DISPLAY =:0 xterm, I get an xterm on vt7. I can then start gnome-panel and nautlius to have a working gnome session. But, as this is :0 (whereas Xgl loaded on :1), when I try running compiz from this xterm, it exits with an error that it couldnt find Xgl.

~/.xsession-errors now does not have any errors that could give a clue. Neither does /var/log/Xorg.0.log.

Any suggestions?

Your patch seems a fine solution for this problem. I'll look at adding something like this to the scripts sometime over the holidays, but don't hold your breath too soon! Feel free to push this along (by providing a candidate debdiff, as per «https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff») if you'd like a solution before I get around to it.

My very first debdiff attempt. Hope I did it fine.

@Slash123 : It seems to be a pb with your gnome session. look into ~/.gnome2/session or try removing your ~/.gnome2 directory to see if it solves it. But this is off topic and this place is not a support forum. I can't help any further here.

Has anyone already tested this debdiff??

The debdiff has unrelated changes in it (to config.guess, and another autogen'd file). I'll extend your patch to fix the TODO and upload a new snapshot soon.

The cause of this bug is probably the same as the following
https://bugs.launchpad.net/ubuntu/+bug/174408

I would not call it a race condition since it is always reproducible btw.

This bug was fixed in the package xserver-xgl - 1:1.1.99.1~git20080115-0ubuntu1

---------------
xserver-xgl (1:1.1.99.1~git20080115-0ubuntu1) hardy; urgency=low

  * New git snapshot. Fixes FTBFS on AMD64.
  * debian/rules:
    + Add get-orig-source target
  * debian/copyright:
    + Add git URL
  * debian/Xgl-session
    + Wait for Xgl to finish starting (as determined by lockfiles in /tmp)
      before spawning other processes (LP: #176515).
      Thanks to Jean-Baptiste Lallement.

 -- Christopher James Halse Rogers <email address hidden> Tue, 15 Jan 2008 23:34:10 +1100

The bug still presents for me with the latest xserver-xgl (1:1.1.99.1~git20080115-0ubuntu1) . there is no change in the symtomps at all..

xmodmap still waits during the loading of the desktop. when i kill it, seahorse starts and waits. when i disable the xgl, plain xorg uses 60% of the cpu.

cpu pentium m 2.0
vga radeon mobile x700 with fglrx

Ok, xorg had a business with glxinfo, which is also using quite alot cpu (30%) killing glxinfo eases the pain of xorg and the system becomes normal (without xgl)

I found some spare time to look at it.
Applications started within the session, always stuck in select, endlessly waiting for a response in my case.

I had prepended a gnome-terminal before xmodmap in Xgl-session. Here is its backtrace

Core was generated by `/usr/bin/gnome-terminal'.
#0 0xb7fc3410 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fc3410 in __kernel_vsyscall ()
#1 0xb75fb2dd in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb70c155a in _xcb_in_read_block (c=0x80a7ca0, buf=0x80a7328, len=8) at xcb_in.c:248
#3 0xb70c07fc in xcb_connect_to_fd (fd=3, auth_info=0xbfb79c10) at xcb_conn.c:131
#4 0xb70c2f21 in xcb_connect (displayname=0x0, screenp=0x0) at xcb_util.c:279
#5 0xb76d57f7 in _XConnectXCB () from /usr/lib/libX11.so.6
#6 0xb76be109 in XOpenDisplay () from /usr/lib/libX11.so.6
#7 0xb7a1f032 in gdk_display_open () from /usr/lib/libgdk-x11-2.0.so.0
#8 0xb79fca0d in gdk_display_open_default_libgtk_only () from /usr/lib/libgdk-x11-2.0.so.0
#9 0xb7bb2e4f in gtk_init_check () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7bb2e84 in gtk_init () from /usr/lib/libgtk-x11-2.0.so.0

I also checked if xauth really add the token for Xgl and it works correctly.

Wanted to confirm hnmb's point: The updated xserver-xgl has not solved the problem in my computer. Have reinstalled (and now updated) gdm, but the system continues to pause at gdm load when xserver-xgl is enabled.

There are no errors in Xorg.0.log and .xsession-errors.

As of today's updates (including an upgrade of the kernel), Xgl seems to be working well.

Haven't been able to figure out what exactly put things right.

Thanks to whoever put this right :)

Ooops... Jumped the gun there.

Though fglrxinfo was reporting that the appropriate driver was in use, I found the graphics to be a bit too slow. So I checked glxgears and found that I was getting frame rates of ~300.

I reinstalled the ATI driver (8.01) only to find that the blank screen on login as before. .xsession-errors ends with the line 'Waiting 10 seconds for Xgl to start'. Nothing more.

FWIW: Was also getting a gnome-settings-daemon error at startup (bug 199960).

Have now reverted to no Xgl and metacity. Performance is back to normal (1700 fps in glxgears).