gdm/kdm starting too early for DRM modules to load, no video

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Anouar,

I think I am experiencing this same problem on my xps 13. Can you tell me if this fixes it for you?

sudo /etc/init.d/gdm stop
sudo /etc/init.d/gdm start

i am having this same problem when i reboot my laptop, but the above commands fix it.

I will confirm it and mark it as affecting me too if this is the same issue.

Darran

No luck, does not appear to be the same issue.

Thank you for your bug report, assigning the issue to our xorg maintainer for review

Unfortunately, the attached logs are from a boot with the nomodeset parameter set, which means that the nouveau drivers aren't actually in use.

When you say “no video”, at what point do you lose video - Do you see the bios startup screen? Do you see the grub screen (if it is displaying for you)? Do you see a modeswitch flicker after grub? Do you see the Ubuntu purple splash screen? Can you describe what happens during boot?

Could you please run “apport-collect 615549” during a boot *without* nomodeset parameter and with “drm.debug=0x04” set? If the video goes blank when starting X you should be able to boot into recovery mode and run this command. If you get no video at all, you should be able to run this command after ssh-ing in from a second machine. If you can't ssh in or don't have a second computer available, as a last resort you should be able to boot without nomodeset, wait for the boot to finish, restart, and then collect & attach /var/log/Xorg.0.log.old and /var/log/kern.log.

I lose the video when Nouveau is loaded (screen flickers, then nothing, no purple splash screen)
I see BIOS and GRUB just fine

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

VGA switcheroo, race conditions, vesafb, oh my!

You say “I lose the video when Nouveau is loaded”, but nouveau isn't loaded until 20 seconds into your boot and doesn't start modesetting until 22 seconds. Did you mean “I lose the video right after GRUB starts loading the kernel”? If so, we have the first bug: vesafb being confused in some way by your multiple graphics cards.

In chronological order, then, we encounter the second bug: X starts at approximately +20seconds, and is probing DRM at 20.625. However, the nouveau kernel driver is busy trying to get the video bios at this point, and hasn't finished initialising. Nouveau finishes bringing up your 9200M GS (which looks like it should be driving the VGA output at this point) at +22 seconds, and then brings up the 9400M G at +25 seconds. By this time, the nouveau X driver has given up looking for DRM, the VESA X driver has loaded and started merrily stomping on card state of the 9400M, which would be my guess as to why the nouveau kernel module bails soon after with a bunch of
[ 25.465878] [drm] nouveau 0000:03:00.0: PFIFO_INTR 0x00000010 - Ch 1
errors.

I'd guess that this race condition is why it is reported by some that restarting gdm fixes things - by that point the nouveau kernel module will actually have initialised and be ready for the nouveau X driver.

To clear things up, I ran a non quiet boot

last line is the init bottom, then the splash screen appears for almost a second then its all black

Hm. That suggests to me that the main problem here might be the race in X start up. Could you please try running

echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash
sudo update-initramfs -u

to get initramfs-tools to add the drm modules to your initramfs? This should ensure that they're loaded earlier and certainly before X.

If that fixes the problem I'll need to work out how to get libdrm to block appropriately while the kernel modules are being initialised.

Got video, Chris's suggestion did the job

Right. So, the underlying problem here appears to be that /dev/fb0, driven by vesafb, gets tagged as PRIMARY_DEVICE_FOR_DISPLAY=1 and gdm is starting on fb0 && PRIMARY_DEVICE_FOR_DISPLAY=1. So gdm is starting before the drm devices are available, and all hell breaks loose.

Reassigning to gdm, as that's what's responsible for prematurely starting X. A safe fix for this would be to replace
"""
...
          and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1
               or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
               or stopped udevtrigger))
"""
with
"""
...
         and stopped udevtrigger
"""
from gdm's upstart script. There may be a better way, though, as this will increase boot time.

For merely ignoring framebuffer devices if we have DRM devices, this would be enough, and more efficient:

          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
               or stopped udevtrigger))

However, that would still not fix devices which have two video cards and X wants to start on the second one (Chris mentioned this). Scott, is there a magical "all video devices are up" wait condition, or do we really have to fall back to the full "stopped udevtrigger" for this special case?

Thanks, Martin

Scott is there any chance you could reply to the previous question?

Martin: there can never be any "all video devices are up" case because a video card can be hotplugged later.

This bug sounds very like a problem that Andy Whitcroft and Colin Watson have been tracking as part of their vgafb/efifb work - if I were you, I would talk to them before taking any action

I've talked with Andy, and he doesn't think that this is related to the problems they've been tracking down. What we need to do here is to wait for DRM to be ready before starting X.

Using:

          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
               or stopped udevtrigger))

will cut down on the occurrence of this bug, but as the logs attached above show, the kernel is initialising the :02 PCI card first but X is looking for the :03 PCI card, so there's still a race possible.

Waiting for udev to finish will adversely affect boot time, but unless we can grow a “video devices are up” signal somehow I don't see how to safely boot without waiting for udev.

Can we get a poor-man's all-devices-up signal by enumerating the PCI bus at the start of the boot and waiting for all the graphics cards on it to be initialised? Does any hardware do something so terribly braindead as expose new GPUs during boot? I think we could probably live with users who insert cards during boot getting a possibly broken experience that one time :).

Dropping the start condition on fb0 seems fine to me; it should help a lot of people, and doesn't affect boot time on reasonably modern machines (i. e. with DRM) at all.

Could somebody who feel comfortable on the change to do claim this bug and upload?

Not sure whether this is sufficient; if not, please cry out and reopen.

gdm (2.30.5-0ubuntu4) maverick; urgency=low

  * debian/gdm.upstart: Do not already fire on a framebuffer device. When a
    real DRM driver gets loaded later on, X will be started too early to catch
    it. This should go a long way towards fixing LP: #615549

 -- Martin Pitt <email address hidden> Mon, 13 Sep 2010 15:23:24 +0200

Just to confirm, video works on today's build.

More info if needed: Running gdm 2.30.5-0ubuntu4

@Anouar Mansour: And that's without having the drm modules loaded in your initramfs? (IE: you've removed the FRAMEBUFFER line from /etc/initramfs-tools/conf.d/splash and re-run update-initramfs?)

I have no idea if this is normal but I do not have a "splash" file in "/etc/initramfs-tools/conf.d/"

We should also backport this to lucid.

Lucid SRU uploaded. This needs review/ack from another SRU team member now.

SRU patch: http://bazaar.launchpad.net/~ubuntu-desktop/gdm/lucid/revision/251

(Cherrypicked from packaging trunk)

The patch from comment #64 does not entirely fix this issue for me on Lucid, although it has certainly improved things. I looked at the patch and changed my /etc/init/gdm.conf file accordingly (hopefully that's all I was supposed to do?). My gdm.conf is included with the archive attached to this comment. I went nearly two full days with this patch and no GDM crash, including a few reboots, suspends and hibernates... until tonight :( The lovely GDM crash appeared again, shortly after resuming from a suspend.

I've also included relevant log files around the time of this GDM crash.

After the crash, I shut down, then booted again, and promptly had another GDM crash almost immediately. I've logged in again and have been safe for 10-15 minutes here on tty8 now. I'll add a separate attachment for logs for this second crash.

As I mentioned in my previous comment, I had another GDM crash right after a reboot. The logs for this one are attached here. Please let me know if there's anything else I can provide. Thanks.

Yes, changing gdm.conf is all that the proposed SRU will do as well.

Can you please change this to

start on (filesystem
          and started dbus
          and stopped udevtrigger)

and run with that for a few days? Perhaps also do 20 reboots in a row if you can? Does that make a difference?

On 09/22/2010 08:45 AM, Martin Pitt wrote:
> Yes, changing gdm.conf is all that the proposed SRU will do as well.
>
> Can you please change this to
>
> start on (filesystem
> and started dbus
> and stopped udevtrigger)
>
> and run with that for a few days? Perhaps also do 20 reboots in a row if
> you can? Does that make a difference?
>
>
On Lucid or on Maverick?

Seth [2010-09-22 8:00 -0000]:
> On Lucid or on Maverick?

Doesn't matter really.

Martin,

As you suggested, I've changed to this in my gdm.conf:

start on (filesystem
          and started dbus
          and stopped udevtrigger)

I will run with this for normal use and report back in a few days, or whenever a crash might occur (hopefully none!). I can also do 20 reboots in a row, but I'm not sure this will show me much. The crashes don't always occur right after reboot. Is there something more to this? Thanks.

Jamie Krug [2010-09-22 13:31 -0000]:
> The crashes don't always occur right after reboot.

Any effect which is related to the gdm.conf start condition _is_
related to boot. I. e. if gdm starts too early, then you will not get
a graphical environment at all, or a very poor one (no acceleration,
etc.). Crashes which happen during the running GNOME/KDE session are
unrelated to this.

Martin:
> Crashes which happen during the running GNOME/KDE session are
> unrelated to this.

Interesting. After sharing extensive results in bug #625239, it seemed quite clear that my issue related to the correct bug and that #625239 was a duplicate of this one (and has been marked as such). Am I really dealing with a completely different bug still? If so, any tips would be incredibly appreciated. This has been a long frustrating road (i.e., nice new loaded System76 Serval laptop w/Ubuntu 10.04, which is barely usable). Thanks in advance!

Jamie,

well, it could be that you actually only get a crash later on, when
gdm starts X.org on the framebuffer driver, and nvidia (or fglrx,
etc.) only gets loaded later on. So it would crash when you try to
start a 3D application, etc.

However, by looking at "glxinfo" or just the X server look it should
be possible to detect this situation right after boot.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

On 09/22/2010 04:10 PM, Jamie Krug wrote:
> Martin:
>
>> Crashes which happen during the running GNOME/KDE session are
>> unrelated to this.
>>
> Interesting. After sharing extensive results in bug #625239, it seemed
> quite clear that my issue related to the correct bug and that #625239
> was a duplicate of this one (and has been marked as such). Am I really
> dealing with a completely different bug still? If so, any tips would be
> incredibly appreciated. This has been a long frustrating road (i.e.,
> nice new loaded System76 Serval laptop w/Ubuntu 10.04, which is barely
> usable). Thanks in advance!
>
>
The way I see it it was well established that you had the same bug that
was fixed here _BUT_ you then went on to receive other crashes that I'm
not sure are related at all. I haven't checked but can you still
identify the same symptoms:

   X starts on shared tty with getty
   X tty has isig flag set (stty(1))
   X crashes on hitting Enter or 2 keys (and perhaps a few other) with a
SIGINT (Enter) or a rather obscure handler traceback?

All this should be established when the greeter screen is shown (change
to vt1)

Include

ps -ef | grep X
gdmtty="$(ps --no-heading -o tty -p $(pgrep X))"
stty -F "/dev/$gdmtty"
ps -f -t "$gdmtty"

To me the CRUCIAL determinant to this particular bug is that 'vt7' does
_not_ appear on the command line for X. If it does, you have a different
bug or it is fixed :)

@Jamie

I think the fact that you haven't been getting VT1 starts confirms that the /etc/init/gdm.conf fix is effective.

Those logs look like the ones you posted in comment #69 and comment #98 of bug #625239. You are running on a good virtual terminal rather than VT1 or VT2 and you get just the header line of the backtrace--so they don't look like the bug we were tracking here or there.

When I looked a couple of weeks ago I couldn't find any bug reports like the ones you just posted, but I only looked for 15 minutes or so. You may want to check yourself.

Do you remember if you are typing anything when they happen? Anything else you can remember about the circumstances? You mentioned above a resume, is that always or usually involved?

If you think you were only having the VT1 (VT2) problem before you first reported the problem perhaps it would be worthwhile to check the changes you were trying out around comment #69 to see if they were all reversed. You were making changes to the grub configuration, if I recall.

Since we now know that your problem was related to the start of the proprietary NVIDIA driver and since the new problem looks like a crash in the same driver, you might be able to get relief from both by trying to switch to a different driver. I'm no longer using an nvidia card with my lucid system, but if I remember correctly I think you might check either the System->Admin->Hardware Drivers to change drivers, or perhaps you can switch drivers just by turning off all special effects in the Appearance preference. The new driver name then would be reflected in your xorg.0.log files.

If you decide to report this problem I'd suggest you use the "ubuntu-bug xorg" command right after experiencing it to collect the logs the xorg bug team like to see.

I'm sorry you are continuing to have problems.

Martin:
> by looking at "glxinfo" or just the X server look it should
> be possible to detect this situation right after boot.

Sorry, I'm not entirely sure what to look for, but I've attached the output from a glxinfo command just after boot/login.

Seth:
> Include
>
> ps -ef | grep X
> gdmtty="$(ps --no-heading -o tty -p $(pgrep X))"
> stty -F "/dev/$gdmtty"
> ps -f -t "$gdmtty"

I rebooted, switched to tty1 and I'm attaching the output from the above. Thanks.

@John

> Do you remember if you are typing anything when they happen? Anything
> else you can remember about the circumstances? You mentioned above a
> resume, is that always or usually involved?

I'm fairly certain I was *not* typing anything, but usually had just clicked something (e.g., a link). I doubt the resume was involved, because last night I rebooted right after a crash and saw another crash shortly thereafter--unless it's possible that some sort of residual issue was related.

> If you think you were only having the VT1 (VT2) problem before you
> first reported the problem perhaps it would be worthwhile to check the
> changes you were trying out around comment #69 to see if they were all
> reversed. You were making changes to the grub configuration, if I
> recall.

Yes, I'm positive that I've reversed any and all changes. I've triple-checked. I may attempt a clean install soon anyway, just to be absolutely certain.

> Since we now know that your problem was related to the start of the
> proprietary NVIDIA driver and since the new problem looks like a crash
> in the same driver, you might be able to get relief from both by
> trying to switch to a different driver. I'm no longer using an nvidia
> card with my lucid system, but if I remember correctly I think you
> might check either the System->Admin->Hardware Drivers to change
> drivers, or perhaps you can switch drivers just by turning off all
> special effects in the Appearance preference. The new driver name then
> would be reflected in your xorg.0.log files.

I'm not sure I follow you here. I have tried the alternate nVidia driver ("version 173") and the "recommended" one, but had issues with both. When I disable nVidia drivers I have no problem, but then I get a very boring desktop experience ;-) Thanks again.

I have some new clues on my crashes! First, Martin's changes to my gdm.conf as mentioned in comment #67 did not fix all for me, as I just had a few more crashes. What I noticed (and had a hunch this morning too), is that I believe I've primarily (if not always) had crashes occur while on battery power. This would explain the fact that I'm sometimes perfectly stable all day at the office (with AC power plugged in to my laptop) while other times it's just crash after crash.

I've also noticed that the crashes seem to occur very soon after login. The last 4-5 crashes have also all occurred just as I was opening Chrome browser.

I've also found a hint of this being battery/power related, as I found mentions of "gnome-power-manager" in a GDM log just after crash. I've attached various output and X/GDM logs. Here are a few lines from my :0-greeter.log.1 log, which has the gnome-power-manager warnings:

(gnome-power-manager:1852): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:2273: signal `proxy-status' is invalid for instance `0x773250'

** (gnome-power-manager:1852): WARNING **: Either HAL or DBUS are not working!

** (gnome-power-manager:1852): WARNING **: proxy failed

** (gnome-power-manager:1852): WARNING **: failed to get Computer root object

** (gnome-power-manager:1852): WARNING **: proxy NULL!!

Martin, you'd mentioned that the crash could be delayed from boot if something using 3D opens--could this be what's happening with Chrome? Then again, if my bug is related to power management, is this a separate bug or related? Thanks again to all for any help!

Martin,

Based on my previous comment (#79), I'm curious whether you think this bug is still relevant or whether I should be opening a new bug (I'm guessing the latter). I've further confirmed the battery power relationship by working for a few hours with AC power plugged in and now crash, then later booting up on battery power and seeing crashes come fairly quickly and repeatedly. I've been searching around for other bugs that match, but no luck. Thanks again.

Accepted gdm into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Shouldn't SRUs have a well-defined test case?

Unfortunately it is not that well-defined. This is mainly a race condition between loading DRM modules (such as nvidia) and gdm starting up. So this should mainly be tested by people who are affected by this bug, i. e. they do not get X start up, or with only the framebuffer driver (meaning no 3D acceleration, poor video playback, and presumably also problems on user switching).

Adding kdebase-workspace task for kdm.

This bug was fixed in the package kdebase-workspace - 4:4.5.1-0ubuntu5

---------------
kdebase-workspace (4:4.5.1-0ubuntu5) maverick; urgency=low

  * debian/kdm.upstart: Do not already fire on a framebuffer device. When a
    real DRM driver gets loaded later on, X will be started too early to catch
    it. (LP: #615549)
 -- Jonathan Thomas <email address hidden> Tue, 28 Sep 2010 17:25:49 -0400

I reinstalled lucid on the same system Anouar was using and I can't reproduce this bug, even with lucid fully up-to-date. Following upgrading to gdm from -proposed the issue still doesn't appear, so the best I can say is that the new package doesn't cause regressions on this particular hardware.

Jamie Krug [2010-09-23 18:47 -0000]:
> Based on my previous comment (#79), I'm curious whether you think this
> bug is still relevant or whether I should be opening a new bug (I'm
> guessing the latter).

Yes, it indeed sounds as if you have an unrelated problem then.
Thanks!

On 10/01/2010 06:38 PM, Martin Pitt wrote:
> Jamie Krug [2010-09-23 18:47 -0000]:
>
>> Based on my previous comment (#79), I'm curious whether you think this
>> bug is still relevant or whether I should be opening a new bug (I'm
>> guessing the latter).
>>
> Yes, it indeed sounds as if you have an unrelated problem then.
> Thanks!
>
>
+1, sadly for you

Martin, Seth: Thanks for the confirmation. FWIW, I've narrowed my newfound nasty crashes down to the Chrome browser, with nVidia drivers installed, but only when on battery power! If I disable nVidia drivers, or simply keep AC power connected to my laptop, everything is fine; but with battery power and nVidia, Chrome crashes hard almost instantly, every time--including a fresh install of Lucid/10.04 64-bit. Nothing else seems to cause a crash. As long as I stick with Firefox when on battery power, I've never seen a crash while working (with plenty of other apps, for extended periods). Ah well, haven't found a report yet, but will open a bug soon if I have to.

Based on comment #86, the package does not cause any regressions in Lucid. Marking as "verification-done" for Lucid.

This bug was fixed in the package gdm - 2.30.2.is.2.30.0-0ubuntu4

---------------
gdm (2.30.2.is.2.30.0-0ubuntu4) lucid-proposed; urgency=low

  * debian/gdm.upstart: Do not already fire on a framebuffer device. When a
    real DRM driver gets loaded later on, X will be started too early to catch
    it. Cherrypicked from packaging trunk r275. (LP: #615549)
 -- Martin Pitt <email address hidden> Mon, 20 Sep 2010 11:03:09 +0200

sorry for my (maybe stupid) question ... now the bug has been fixed: should I remove the PPA reference from my software source "http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu" ???

thanks

cm

After some upgrade/update my laptop (Sony VGN-SZ750N) stopped starting the graphical interface. For a couple of days I simply logged in, said "startx", and started working. After about five minutes, the graphical login would show up, interrupting what I was doing.

So I decided to investigate, and I discovered that reverting the patch discussed here fixes my problem.

I have had the same problem since 10.04. On MSI EX600 running GeForce 8400M G driver version 260.19.21. The kernel is 2.6.35-24. Before upgrading to 10.04 gdm worked perfectly but since then I get to the shell 50% of the time. So Ubuntu 10.10 has not fixed this problem as of today. Running on batteries or not makes no difference.

My gdm package is 2.30.5-0ubuntu4 (standard maverick package). Any ideas?

I also tried editing /etc/init.d/gdm.conf as stated at top of this thread with no effect. Also "sudo service gdm start" does not work. A strange thing is that shutting down the laptop causes the NVidia logo to appear immediately after pressing the power button to shut down the machine. It appears that the driver is waiting for some user input or signal at boot time. And it gets it when shutdown is started.

This keeps happening to me with recent natty kernels on 9500m nvidia card on dell xps1340 machine: either stuck on plymouth or thrown to tty login. Please, is there any way to work around this?

Well, I found a simple workaround: install lightDM and choose it as the default greeter in the dialog that ensues. Now I do not have to use failsafeX any more.

My natty system has recently started doing this too... X is ending up on VT 1 somehow, and then 'enter' is randomly triggering SIGQUIT...

@Yotam Benshalom Installing lightDM did *not* fix this issue for me.
Trying https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/625239/comments/143 next...

I have this bug on Natty with an intel mobile graphics card, I have i915 driver if that's important at all.

Andrew, you probably have a different bug. Please file a separate bug report with a description of what you're experiencing.