gdm greeter crashes when X is using vesa driver

[Klaus S. Madsen]

Binary package hint: gdm

I have a Thinkpad T61p, on which I would like to use the vesa driver. However when I try to start gdm up, the greeter crashes with a segfault. gdm works as it should if the closed source nvidia driver is used.

I have posted a similar bug regarding a crash in kdm with similar properties: https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/138697

I'm using gutsy, with gdm version 2.19.8-0ubuntu2.

[Sebastien Bacher (seb128)]

looks like an xorg issue

[Tormod Volden (tormodvolden)]

Can you please attach /var/log/Xorg.0.log (from using the vesa driver)?

[Klaus S. Madsen (ubuntu-hjernemadsen)]

I forgot to mention it in the bug report, but the X server is actually working as it should, if I start it using startx on the command line.

[Tormod Volden (tormodvolden)]

Can you please attach /etc/gdm/gdm.conf ? Did you ever change it, or gdm.conf-custom?

[Klaus S. Madsen (ubuntu-hjernemadsen)]

I doesn't work with the config files that are installed by default. Do you still want a copy?

[Tormod Volden (tormodvolden)]

> Do you still want a copy?
No, that is not needed I think.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Ok. I figure the problem out. I got an xorg.conf file from another user with a T61p, who didn't have any problems using kdm, and if I use his refresh settings, both gdm and kdm works again.

I changed the refresh settings from:

        Horizsync 30-70
         Vertrefresh 50-160

to:

        Horizsync 28-96
         Vertrefresh 43-60

Which solved the problem.

[Tormod Volden (tormodvolden)]

Funny that it worked when you launched X with startx.
Is autodetection working, will dpkg-reconfigure -phigh xserver-xorg make it work again? (Maybe backup your xorg.conf first)

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Nope. The autodetection causes the nv driver to be used, and my graphics card is too new to work with that driver.

[Tormod Volden (tormodvolden)]

Did the installer choose nv by itself the first time, or have you selected nv at some point?

From your log I found the PCI ID 10de:040c which I can not find in discover-data. It's not in src/nv_driver.c either. It clearly should not select the nv driver.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

To be honest, I can't remember. I believe that I had working X, with the wrong screen resolution after the installation, but I might have changed the driver to vesa before that. I don't remember.

I know that I have manually selected the nv-driver by editing /etc/X11/xorg.conf, at some point. However I'm pretty sure that I never have been given the choice to select the nv driver automatically, so I've only selected it by hand.

But the xorg.conf file generated by running dpkg-reconfigure had the correct refresh rates. So I'm guessing that the nvidia driver configuration have inserted the other rates (I certainly haven't changed them in any way after the installation).

If there is any why I can try to "reset" the dpkg-reconfigure of xserver-xorg, so it returns to the state when installing (and hopefully selects the working vesa driver), I'll be happy to try it.

[Tormod Volden (tormodvolden)]

dpkg-reconfigure xserver-xorg keeps a setting in the debconf database "xserver-xorg/config/device/driver" to remember which driver has been detected or chosen. You can look at the /var/cache/debconf/config.dat file, but I wouldn't recommend to modify it manually. If you run dpkg-reconfigure without -phigh you should get the choice of drivers and you can choose vesa.

The best way to see if this still is an existing bug would be if you could try a recent live CD and see if it chooses the vesa driver and sets up the correct sync ranges.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Do you mean just booting the livecd, or re-installing from the livecd?

[Tormod Volden (tormodvolden)]

Just booting from it.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Ok. I finally got time to test kubuntu tribe 5. It will not bring up a working X, when booting ordinarily. However the safe graphics mode, will bring up working X. However in this case, the refresh settings are:

        HorizSync 30-70
        VertRefresh 50-160

I.e. the ones that don't work with gdm/kdm and the vesa driver after installation.

Any way I can get the xorg.conf from the non-safe mode boot?

[Tormod Volden (tormodvolden)]

You can switch to a virtual console with ctrl-alt-F2 and log in and copy the xorg.conf. Then modify it to work and restart X.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Unfortunately CTRL+ALT+F2 does not work. However I think that the laptop is still alive, as it requests a DHCP lease, when a network cable is connected, after X have started. Is it possible to have the LiveCD start up the SSH-server, or display a console on an USB Serial converter?

[Tormod Volden (tormodvolden)]

Boot with break=bottom on the kernel line. Then copy /root/etc/X11/xorg.conf to /root/etc/X11/xorg.conf.nonsafe
You can now edit the file with: chroot /root nano /etc/X11/xorg.conf
When you're done exit the "break" shell and it will continue booting.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Ok. Attached is the xorg.conf I have obtained using the break=bottom method, using a tribe5 kubuntu installer. As you can see, it tries to use the nv driver. Also it have detected the display size to be 1920x1920 instead of the correct 1920x1200. However the refresh rates seem to be correct.

[Tormod Volden (tormodvolden)]

Thanks for trying out the live cd. It picks the wrong driver, but I don't know why. Can you try this:

sudo discover --disable-all --enabled=pci --format="%S\t%D\n" video

[Tormod Volden (tormodvolden)]

BTW, the greeter should not segfault because of a wrong sync line. I would suggest keeping this bug for the crash - it should be allowed to change the driver in xorg.conf without adjusting the monitor sync ranges. And open a new bug on the installer picking the wrong driver for your card.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

This is the output from running the above command, on a gutsy updated 3 hours ago:

$ sudo discover --disable-all --enable=pci --format="%S\t%D\n" video
XFree86 nv
XFree86 nv
XFree86 nv

I searched for the installer picking the wrong driver for my card, and that has already been reported in: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-driver-nv/+bug/133385

But, yes. I agree with you. The greeter should not crash, especially not when X seems to be working as it should otherwise.

[Tormod Volden (tormodvolden)]

Has anything changed with the new nv 2.1.5 driver?

[Tormod Volden (tormodvolden)]

Can you please also attach gdm.conf? I don't get why startx worked while gdm didn't.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Ok. I'll test with the nv driver later, as I don't want to restart my X currently.

The gdm.conf, as stated previously, is the one that is installed per default. I've made no changes. Should I attach it anyways?

Since the greeter segfaults, it should be possible to obtain a core-dump, and from that a backtrace. But I can't seem to find a corefile anywhere. Any ideas?

[Tormod Volden (tormodvolden)]

Sorry, I misread "I doesn't work with the config files that are installed by default" as if you had to modify them. Funny enough I got it right the last time :)

(from https://wiki.ubuntu.com/DebuggingXorg)
If you can't find any core files after a crash, look also in /var/crash, where apport (the automatic crash reporter) leaves its reports. apport interferes with the normal core dumping, so to get a core dump you can also try also to disable apport by editing /etc/default/apport (change disabled= from 1 to 0) and reboot.

You can also try to temporarily disable apport with "echo core | sudo tee /proc/sys/kernel/core_pattern"

Actually, there shouldn't be much changed with the new nv driver, it will work with your card ok, but the issue here is with vesa/gdm if I understand well.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Allright. I could not get it to produce a core file I could find (even when setting core_pattern to /tmp/core).

However I inserted some raise(SIGSTOP) at strategic points in the file, and then attached gdb to the process before it crashed. This is the output from gdb (running in the daemon directory of the gdm source):

Program received signal SIGSEGV, Segmentation fault.
0x0806b1e1 in gdm_slave_run (display=0x80a8fc0) at slave.c:1050
1050 display->screenx = xscreens[xineramascreen].x_org;
---> I run the command: bt
#0 0x0806b1e1 in gdm_slave_run (display=0x80a8fc0) at slave.c:1050
#1 0x0806b84d in gdm_slave_start (display=0x80a8fc0) at slave.c:934
#2 0x0805ccd0 in gdm_display_manage (d=0x80a8fc0) at display.c:414
#3 0x08051f1e in gdm_start_first_unborn_local (delay=0) at gdm.c:266
#4 0x08052a1f in main (argc=Cannot access memory at address 0x0
) at gdm.c:1828
---> I run the command: list
1045 if (screen_num <= gdm_daemon_config_get_value_int (GDM_KEY_XINERAMA_SCREEN))
1046 gdm_daemon_config_set_value_int (GDM_KEY_XINERAMA_SCREEN, 0);
1047
1048 xineramascreen = gdm_daemon_config_get_value_int (GDM_KEY_XINERAMA_SCREEN);
1049
1050 display->screenx = xscreens[xineramascreen].x_org;
1051 display->screeny = xscreens[xineramascreen].y_org;
1052 display->screenwidth = xscreens[xineramascreen].width;
1053 display->screenheight = xscreens[xineramascreen].height;
1054

Also xscreens, seems to point to NULL.

I can't see why I thought that this was a crash in gdmgreeter, as the greeter haven't even been started at this point. However it seems to be related to xinerama, as xscreens is the result of calling XineramaQueryScreens. However I'm quite unschooled in the workings of X, so I'll leave guessing why it returns NULL to you :-)

[Tormod Volden (tormodvolden)]

What is the value of xineramascreen? I have on idea of the inner workings of gdm :) but vesa does not do xinerama.
Is xscreens[0].x_org ok?

[Klaus S. Madsen (ubuntu-hjernemadsen)]

I don't know the value of xineramascreen. I'll have to single step the code, as the value is optimized out at the point where the program segfaults.

But xscreens is a pointer to a XineramaScreenInfo structure, and the pointer value is NULL, so screen[0].x_org is also invalid.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

Hmm... I just took a more through look at the code, and it seems that the code where gdm crashes should only be executed if XineramaIsActive returns true. So as far as I can tell, one of three things causes the problem:

1) XineramaIsActive falsely returns TRUE, even though no Xinerama support is available.
2) XineramaIsActive fails, but for some reason the ignore_error_handler doesn't get called, so x_error_occured is still false when we test it.
3) Some sort of compiler error.

Of these three posibilities, I think that 1) is the most likely one. However why XineramaIsActive should be affected by the refresh rate range set in xorg.conf, is beyond my imagination.

I'll try to debug it further tonight, if time permits.

[Timo Aaltonen (tjaalton)]

What is the status of this bug? It has become a bit confusing to follow. The vesa crash is due to wrong settings in the default xorg.conf. That's fixed in hardy since those values are not written (although vesa could still fail). Other issues should be on separate bugs.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

If the sync lines aren't written to the xorg.conf file anymore with Hardy, I don't believe that anyone will encounter the problem. However the problem still exists in Gutsy, and I haven't tested Hardy yet.

[Timo Aaltonen (tjaalton)]

Right, the sync-lines aren't written anymore, so closing as fixed.