Bug 252509

Could you attach the output of "ps aux" right after reboot before answering "No"?

Created attachment 123131 [details]
output of ps aux before answering "No"

This looks like a gdm bug to me. Could you verify this by setting DISPLAYMANAGER to "xdm" in /etc/sysconfig/displaymanager and reboot afterwards? Thanks.

Done. Seems to work nicely, only the login screen looks somewhat weird.

What do you mean with somewhat weird Graphics distortion?

What do you mean with "somewhat weird"? Graphics distortion? Could you attach
a screenshot?

  XAUTHORITY=/var/lib/xdm/authdir/authfiles/<press_tab> -window root xdm.png

Install package ImageMagick before.

sorry, nothing serious, just the screen is all grey and there is a status window in the bottom left corner. After logging in everything appears as usual.

Well, that's xdm. It's different to kdm/gdm. :-) Reassigning since it's a gdm bug.

HPJ, wasn't there a bug like this released as a maintenance update for SLED 10?

That was bug #206804, for which the fix is in SP1. It was not shipped as a maintenance update. The patch does not apply to 10.3 because the code has since been rewritten upstream.

I'll see if this is the same bug, and if porting the patch would help.

Based on code forensics, the GDM in OpenSUSE 10.3 seems to have the same problem. I've ported the patch from SLE10-SP1, but I'd love a couple of test runs before I submit it. You'll find test packages at:

http://hp.cl.no/dist/gdm-252509/

Please choose the correct package for your platform, install it (you may have to use --force), and try to trigger the bug a couple of times.

OK, it needed --force to install.

After installation the error occurred on the 1st and 2nd boot, this time it just stays in TTY1, you need to ALT+CTL+F8 to get to see the message.

Attempt 3 to 9 booted straight to GDM, attempt 10 failed again, which led me to add another 10 cycles. They all went through to GDM.

The average cycle time was 2':45", 0:35" for shutting down, 2':10" for coming up.

I used gdm-2.17.7-2.i586.rpm on an FSC Amilo Si1520 running openSuSE 10.3 alpha2plus.

This bug is probably different from bug 206804, then. I'll submit the ported patch to 10.3 anyway.

When it fails, do you get any interesting messages from gdm in /var/log/messages?

Also, can you attach the /var/log/Xorg.0.log resulting from a failed gdm init?

Created attachment 125843 [details]
Output from cat /var/log/messages | grep gdm

Created attachment 125844 [details]
As requested

Created attachment 125845 [details]
Previous xorg.0.log

This happens more frequently again after yesterdays update, dmesg doesn't show anything about gdm. I'll attach an actual xorg.0.log

Created attachment 129911 [details]
/var/log/Xorg.0.log

I don't see anything suspicious in the X log, but maybe a trained eye will. What say you, Mr. Dirsch?

X.Org logfile looks fine to me.

I'm going back to the code to see exactly where it fails, or put in some debug output to pin it down if necessary.

This is now worse, since yesterdays update ( tty1 greets me with Welcome to openSUSE 10.3 (alpha4) Kernel 2.6.21-3-default ), gdm is 2.18.1-9, xorg-x11 is 7.2-68

After booting tty1 is displayed with login prompt.

CTL+ALT+F7 / CTL+ALT+F8 both show blank screen.

Logging in and issuing 

ps -A | grep gdm

shows two instances each of gdm and gdmopen.

issuing init 3 then init 5 doesn't change that.

Killing the gdm with the lowest pid ( oldest ) makes all disappear, starting gdm afterwards results in "there appears ..."

Booting afresh and killing first the gdm with the highest pid ( youngest ) then the remaining one, then running gdm will finally start the x-server.

Created attachment 138044 [details]
/var/log/Xorg.0.log

When turning off Xgl ( Desktop effects ) it's back to normal.

I.e. yast2 sysconfig setting /etc/sysconfig/displaymanager 

DISPLAYMANAGER_XSERVER to Xorg from Xgl

Probably the same as disabling Desktop Effects from "Control Center/Desktop Effects" where it states:

"Your graphics card is not known to be supported by Xgl. However, it does appear to support 3D acceleration.

To enable Xgl, press "Enable Desktop Effects" below. This will log you out and return you to the login screen.

If the login screen does not come back up, you will need to disable Xgl from the command line by logging in as root and running:

gnome-xgl-switch --disable-xgl

If you are having problems configuring Desktop Effects, you can click the "Help" button below to visit the troubleshooting page on the openSUSE wiki for advice."

While the Desktop Effects seem to work, the start behaviour is as comment #23 when enabled.

*** Bug 263147 has been marked as a duplicate of this bug. ***

Since trying several features in KDE, I find that the behaviour from Bug 263147 ( system freezes on logout ) is occuring here too.

OK, KDE seems to use GDM as well:
cjp@workstation6l:~> ps -A | grep gdm
 4162 ?        00:00:00 gdm
 4337 ?        00:00:00 gdm

Egbert, JFYI. Since Matthias or me is in Cc of this bugreport or the reported itself, it might be interesting for you as well.

JFYI, Matthias. This is a bugreport, which is assigned to Egbert/me or with Egbert/me in CC or reported by Egbert/me.

You might want to check out https://bugs.freedesktop.org/show_bug.cgi?id=10768 ( debian ) and  https://bugs.freedesktop.org/show_bug.cgi?id=10124 ( gentoo ) as well.

Could you please check kdm, whether it has the same behavior? (Edit /etc/sysconfig/displaymanager for that, also kdm has to be installed, of course).

It could well be, that gdm uses a different technique for checking whether X startup is completed than the official one (waiting for SIGUSR1). In that case, Xgl probably doesn't support this technique, and this should be fixed in gdm. I know that Xgl *does* support the SIGUSR1 method.

I just remembered there was something in kdm - which is fixed now AFAIK.

As this only happens with Xgl, it is either startup detection, or shutdown doesn't work correctly. It could well be that Xgl doesn't wait for Xorg finishing during shutdown. Adding David to CC.

Instead of waiting for Xorg to shut down, Xgl could also loop/wait for Xorg to come up during startup. That might be more stable, as Xgl simply cannot react (and wait) if it is killed e.g. with SIGKILL.

Just an idea.

Moving to Xgl component and reassigning.

Is this still an issue with openSUSE 11.0 >= Beta1?

Not sure about this one. It happened only occasionally in the past, I haven't seen it since Beta1 & upgrade from factory. Might as well close, I will reopen if it shows up again.

Ok.