X trying to start before plymouth has finished using the drm driver

[Tomas Vanderka]

X server fails to start the first time after boot, it works fine when I start it again.

Looks like a race condition with intel drm initialization, i guess X tries to start faster than drm driver is initialized so it fails.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xorg 1:7.6+12ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
Uname: Linux 3.2.0-23-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.0.1-0ubuntu3
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: compiz
Date: Mon Apr 16 10:35:28 2012
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Micro-Star International Co., Ltd. Device [1462:7750]
 Advanced Micro Devices [AMD] nee ATI Barts XT [ATI Radeon HD 6800 Series] [1002:6738] (prog-if 00 [VGA controller])
   Subsystem: Giga-byte Technology Device [1458:21fa]
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120301)
MachineType: MSI MS-7750
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-23-generic root=/dev/mapper/ssd-ubuntu--precise ro quiet splash
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/25/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V4.0
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: Z68A-G43 (G3) (MS-7750)
dmi.board.vendor: MSI
dmi.board.version: 1.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MSI
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV4.0:bd08/25/2011:svnMSI:pnMS-7750:pvr1.0:rvnMSI:rnZ68A-G43(G3)(MS-7750):rvr1.0:cvnMSI:ct3:cvr1.0:
dmi.product.name: MS-7750
dmi.product.version: 1.0
dmi.sys.vendor: MSI
version.compiz: compiz 1:0.9.7.6-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

[Bryce Harrington (bryce)]

We've seen this (or something akin) with the binary drivers. We speculated that perhaps having the driver provide some sort of "all ready" signal that upstart can listen for would help. Short of that, for a workaround might test adding some sleeps in front of lightdm.

[Bryce Harrington (bryce)]

Meanwhile, can you post the output of sudo lshw?

[Bryce Harrington (bryce)]

Also, please attach your /var/log/udev from after reproducing the bug.

[Bryce Harrington (bryce)]

A workaround is to add some sleep to /etc/init/lightdm.conf:

    sleep 10
    exec lightdm

[Bryce Harrington (bryce)]

<slangasek> bryceh: line 4396 of the udev log shows drm card0 coming up at 1.901920 after boot; the udev doesn't start on the root filesystem until 2.244658 according to BootDmesg.txt
<slangasek> bryceh: so the drm device *was* there for coldplugging, which makes this a kernel bug
<slangasek> fundamentally, there is still a race in how we're handling video at boot... but as my earlier surprise indicates, I think it's incredibly unlikely we'll hit it in practice

[Bryce Harrington (bryce)]

From the X log, it is finding the dri card device file ok:

[ 2.446] drmOpenDevice: node name is /dev/dri/card0
[ 2.446] drmOpenDevice: open result is 9, (OK)
[ 2.497] drmOpenByBusid: Searching for BusID pci:0000:00:02.0
[ 2.497] drmOpenDevice: node name is /dev/dri/card0
[ 2.497] drmOpenDevice: open result is 9, (OK)
[ 2.497] drmOpenByBusid: drmOpenMinor returns 9

But then it runs into an interface version error:

[ 2.497] drmOpenByBusid: Interface 1.4 failed, trying 1.1

Then it tries opening card1-15, then finally gives up, goes back to 0, and acts confused:

[ 2.547] drmOpenDevice: node name is /dev/dri/card14
[ 2.551] drmOpenByBusid: drmOpenMinor returns -1
[ 2.551] drmOpenDevice: node name is /dev/dri/card15
[ 2.555] drmOpenByBusid: drmOpenMinor returns -1
[ 2.555] drmOpenDevice: node name is /dev/dri/card0
[ 2.555] drmOpenDevice: open result is 9, (OK)
[ 2.555] drmOpenDevice: node name is /dev/dri/card0
[ 2.555] drmOpenDevice: open result is 9, (OK)
[ 2.555] drmGetBusid returned ''
[ 2.555] (EE) intel(0): [drm] failed to set drm interface version.
[ 2.555] (EE) intel(0): Failed to become DRM master.

[Bryce Harrington (bryce)]

The code that does the kernel module loading is in libdrm; reassigning.

Probably best to forward this upstream for advice before we start hacking loops into libdrm...

[Tomas Vanderka (tomas-vanderka)]

Putting "sleep 1" in /etc/init/lightdm.conf was enough.

When i look at dmesg it says
[ 2.263168] [drm] Initialized drm 1.1.0 20060810
[ 2.766592] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

so i guess xorg tries to use it at [ 2.497] in some partially initialized state or something

[Bryce Harrington (bryce)]

<apw> slangasek, we know that the drm driver can be opened by splash before its ready. we had to add an 'EAGAIN' failure there
<apw> slangasek, we may or may not cope with that in userspace
<apw> commit 6d74feca6235b463ade4ecddd1dfdb73d30a2ff7
<apw> Author: Andy Whitcroft <email address hidden>
<apw> Date: Thu Jul 29 16:48:21 2010 +0100
<apw> UBUNTU: SAUCE: drm -- stop early access to drm devices
<apw> slangasek, ^^
<apw> bryceh, its a race, we need to know the minors to tell the load method, but till its run we can't actually safely open them
<apw> which is why we have to tell you to hang fire a sec
<apw> though any open can return EAGAIN and you really should damn well listen :)
<slangasek> upstart should not open the drm device at all - it's up to whatever wants to use it to handle this
<slangasek> (assuming the kernel really can't defer announcing it until it's initialized)
<apw> right, we presumably run plymouth or X and its crapping self cause the open failed
<bryceh> ok, so then _X_ should block and retry on the device until it gets something working?
<slangasek> yes
<apw> that'd be helpful if it could
<bryceh> hum
<apw> as EAGAIN really means, ooops could you try that again please
<apw> bryceh, well it should only do it for open == -1 and errno == EAGAIN

[Tomas Vanderka (tomas-vanderka)]

udev log and corresponding dmesg and xorg log

In this case it got to a state when lightdm/X thought it was doing fine, but i got black screen with blinking cursor + mouse pointer

[Tomas Vanderka (tomas-vanderka)]

I looked at the code and it seems it fails somewhere in kernel drm_setversion ioctl after being called from libdrm drmSetInterfaceVersion.
I guess it's because drm driver load didn't finish yet. And there are no usefull return values in the code involved so there's no way to know libdrm should try again.

[Tomas Vanderka (tomas-vanderka)]

Maybe related to #927684 #899725

[Andy Whitcroft (apw)]

Ok it is clear something odd going on with the drm ioctls. As there is little information in the X logs, I have put some debug in the kernel to try and help us understand this. If those of you who can reproduce this issue could try out the following kernels and report back. When you have successfully reproduced this please report back here including the output of 'dmesg':

    http://people.canonical.com/~apw/lp982889-precise/

Thanks in advanced.

[Tomas Vanderka (tomas-vanderka)]

So I tried a few things with drm.debug=1 kernel param

When I reproduce the problem, something (plymouth?) does drm stuff before xorg, and xorg then gets EACCESS error from drm_setversion ioctl (nr=0x07) and dmesg looks like this

Apr 21 02:25:35 kujoniq kernel: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.2.0-24-generic root=/dev/mapper/ssd-ubuntu--precise ro quiet drm.debug=1
Apr 21 02:25:35 kujoniq kernel: [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.2.0-24-generic root=/dev/mapper/ssd-ubuntu--precise ro quiet drm.debug=1
Apr 21 02:25:35 kujoniq kernel: [ 2.487567] [drm] Initialized drm 1.1.0 20060810
Apr 21 02:25:35 kujoniq kernel: [ 2.497942] [drm:drm_pci_init],
Apr 21 02:25:35 kujoniq kernel: [ 2.497952] [drm:drm_get_pci_dev],
Apr 21 02:25:35 kujoniq kernel: [ 2.497977] [drm:drm_get_minor],
Apr 21 02:25:35 kujoniq kernel: [ 2.498099] [drm:drm_get_minor], new minor assigned 64
Apr 21 02:25:35 kujoniq kernel: [ 2.498101] [drm:drm_get_minor],
Apr 21 02:25:35 kujoniq kernel: [ 2.498161] [drm:drm_get_minor], new minor assigned 0
Apr 21 02:25:35 kujoniq kernel: [ 2.552305] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Apr 21 02:25:35 kujoniq kernel: [ 2.552306] [drm] Driver supports precise vblank timestamp query.
Apr 21 02:25:35 kujoniq kernel: [ 2.552830] [drm:drm_sysfs_connector_add], adding "VGA-1" to sysfs
Apr 21 02:25:35 kujoniq kernel: [ 2.552960] [drm:drm_sysfs_hotplug_event], generating hotplug event
Apr 21 02:25:35 kujoniq kernel: [ 2.567174] [drm:drm_sysfs_connector_add], adding "HDMI-A-1" to sysfs
Apr 21 02:25:35 kujoniq kernel: [ 2.567194] [drm:drm_sysfs_hotplug_event], generating hotplug event
Apr 21 02:25:35 kujoniq kernel: [ 2.567201] [drm:drm_sysfs_connector_add], adding "DP-1" to sysfs
Apr 21 02:25:35 kujoniq kernel: [ 2.567235] [drm:drm_sysfs_hotplug_event], generating hotplug event
Apr 21 02:25:35 kujoniq kernel: [ 2.676194] [drm:drm_irq_install], irq=51
Apr 21 02:25:35 kujoniq kernel: [ 2.783104] fbcon: inteldrmfb (fb0) is primary device
Apr 21 02:25:35 kujoniq kernel: [ 2.783492] [drm:drm_vblank_get], enabling vblank on crtc 0, ret: -22
Apr 21 02:25:36 kujoniq kernel: [ 2.951148] [drm:drm_calc_timestamping_constants], crtc 3: hwmode: htotal 2080, vtotal 1235, vdisplay 1200
Apr 21 02:25:36 kujoniq kernel: [ 2.951151] [drm:drm_calc_timestamping_constants], crtc 3: clock 154000 kHz framedur 16679910 linedur 13506, pixeldur 6
Apr 21 02:25:36 kujoniq kernel: [ 2.957757] fb0: inteldrmfb frame buffer device
Apr 21 02:25:36 kujoniq kernel: [ 2.957757] drm: registered panic notifier
Apr 21 02:25:36 kujoniq kernel: [ 2.957806] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Apr 21 02:25:36 kujoniq kernel: [ 2.997507] [drm:drm_stub_open],
Apr 21 02:25:36 kujoniq kernel: [ 2.997510] [drm:drm_open_helper], pid = 286, minor = 0
Apr 21 02:25:36 kujoniq kernel: [ 2.997514] [drm:drm_setup],
Apr 21 02:25:36 kujoniq kernel: [ 2.997517] [drm:drm_ioctl], pid=286, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1
Apr 21 02:25:36 kujoniq kernel: [ 2.997520] [drm:drm_ioctl], pid=286, cmd=0xc0406400, nr=0x00, dev...

[Tomas Vanderka (tomas-vanderka)]

Everything starts fine if nothing touches drm before X or it somehow finishes correctly before X tries to start i guess ...

Apr 21 02:28:24 kujoniq kernel: [ 2.802193] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Apr 21 02:28:24 kujoniq kernel: [ 2.826851] [drm:drm_stub_open],
Apr 21 02:28:24 kujoniq kernel: [ 2.826854] [drm:drm_open_helper], pid = 1317, minor = 0
Apr 21 02:28:24 kujoniq kernel: [ 2.826857] [drm:drm_setup],
Apr 21 02:28:24 kujoniq kernel: [ 2.826865] [drm:drm_ioctl], pid=1317, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1
Apr 21 02:28:24 kujoniq kernel: [ 2.826869] [drm:drm_ioctl], pid=1317, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1
Apr 21 02:28:24 kujoniq kernel: [ 2.826873] [drm:drm_release], open_count = 1
Apr 21 02:28:24 kujoniq kernel: [ 2.826875] [drm:drm_release], pid = 1317, device = 0xe200, open_count = 1
Apr 21 02:28:24 kujoniq kernel: [ 2.826878] [drm:drm_lastclose],
Apr 21 02:28:24 kujoniq kernel: [ 2.826890] [drm:drm_lastclose], driver lastclose completed
Apr 21 02:28:24 kujoniq kernel: [ 2.826892] [drm:drm_lastclose], lastclose completed
Apr 21 02:28:24 kujoniq kernel: [ 2.826905] [drm:drm_stub_open],
Apr 21 02:28:24 kujoniq kernel: [ 2.826906] [drm:drm_open_helper], pid = 1317, minor = 0
Apr 21 02:28:24 kujoniq kernel: [ 2.826908] [drm:drm_setup],
Apr 21 02:28:24 kujoniq kernel: [ 2.826917] [drm:drm_ioctl], pid=1317, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1
Apr 21 02:28:24 kujoniq kernel: [ 2.826919] APW: drm_setversion called
Apr 21 02:28:24 kujoniq kernel: [ 2.826921] APW: drm_setversion returned 0
Apr 21 02:28:24 kujoniq kernel: [ 2.826922] [drm:drm_ioctl], pid=1317, cmd=0xc0106401, nr=0x01, dev 0xe200, auth=1
Apr 21 02:28:24 kujoniq kernel: [ 2.826924] [drm:drm_ioctl], pid=1317, cmd=0xc0106401, nr=0x01, dev 0xe200, auth=1
Apr 21 02:28:24 kujoniq kernel: [ 2.826934] [drm:drm_ioctl], pid=1317, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1
Apr 21 02:28:24 kujoniq kernel: [ 2.826935] APW: drm_setversion called
Apr 21 02:28:24 kujoniq kernel: [ 2.826937] APW: drm_setversion returned 0
Apr 21 02:28:24 kujoniq kernel: [ 2.826939] [drm:drm_ioctl], pid=1317, cmd=0xc0106446, nr=0x46, dev 0xe200, auth=1
Apr 21 02:28:24 kujoniq kernel: [ 2.826989] [drm:drm_ioctl], pid=1317, cmd=0x80106463, nr=0x63, dev 0xe200, auth=1

[Tomas Vanderka (tomas-vanderka)]

After disabling plymouth-splash I can't reproduce this anymore.

It's a race between plymouth and xorg. Plymouth holds DRM master (drm_setmaster_ioctl) while xorg tries to start (drm_setversion) and fails with EACCESS because it needs DRM_MASTER for that.

It works fine if
1. plymouth never starts
2. plymouth calls drm_dropmaster_ioctl before X starts

And another thing is the Xorg.log timestamps can't really be trusted.

[Bryce Harrington (bryce)]

Tomas, did you ever get a chance to test the kernel apw posted in comment #17?

http://people.canonical.com/~apw/lp982889-precise/

[Tomas Vanderka (tomas-vanderka)]

Yes, dmesg output when X fails to start with that kernel is in comment #18
#19 is when it starts fine

But when X failed to start it never even got to your debug code cause it failed in drm_ioctl with EACCESS as can be seen from drm debug output.

This is where it tries to call drm_set_version and fails with EACCESS

Apr 21 02:25:36 kujoniq kernel: [ 3.134782] [drm:drm_ioctl], pid=1207, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1
Apr 21 02:25:36 kujoniq kernel: [ 3.134784] [drm:drm_ioctl], ret = fffffff3
Apr 21 02:25:36 kujoniq kernel: [ 3.134790] [drm:drm_ioctl], pid=1207, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1
Apr 21 02:25:36 kujoniq kernel: [ 3.134792] [drm:drm_ioctl], ret = fffffff3

So it's not really a drm problem. Xorg tries to start too soon while plymouth-splash is still doing stuff with drm. After i disabled plymouth-splash i never reproduced this again.

[Bryce Harrington (bryce)]

bug #966868 may be a dupe of this issue

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[ben (roboben)]

Can confirm this bug on recent ubuntu 12.10. The workaround from Bryce Harrington (comment #5) fixed the problem for me. thanks!

[Justyn Butler (justyn)]

I had this bug on 12.04 and now have it on 12.10.
64-bit Thinkpad X220, Core i7 (2nd gen) and Intel 320 SSD, with external monitor.

Bryce's workaround in comment #5 seems to have "fixed" it.

[Bryce Harrington (bryce)]

Bug #1037518 is a dupe.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Eddie B (fasteddieb216)]

I hope this info helps... I also had this problem (and another possibly related problem) until I replaced my new Radeon HD 6450 video card with an old GeForce 7900 GS card. You can see more details of my problem here:
https://answers.launchpad.net/ubuntu/+source/apt/+question/221246

I would much rather use the Radeon card if possible.

[Bryce Harrington (bryce)]

Similar patch, for xorg-server.

[Franck (alci)]

Maybe this is related ??? http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=735dc0d1e29329ff34ec97f66e130cce481c9607

[Chris Wilson (ickle)]

No, the race here is in the global_mutex used for serialising setting up, tearing down and opening the device. My preferred workaround is exactly what Bryce implemented.

[Bryce Harrington (bryce)]

I've packaged the patch in the following PPA:

   https://launchpad.net/~bryce/+archive/lp982889

Since I've so far not reproduced the bug on my own hw, I need someone else who does see this problem to install and run the ppa and verify it fixes the issue.

Potentially we may need to adjust the countdown timer or the error code, but I think this should work.

[Bryce Harrington (bryce)]

Oh, and if you do run the PPA, I'd like to see your Xorg.0.log, regardless of whether it worked or not, so I can verify the error code being passed up.

[Franck (alci)]

I have just install xserver-common from the PPA, but it did not solve the issue here.

Here is my Xorg.0.log on failure.

[Adam Bruce (brucey-99-deactivatedaccount)]

I have added the PPA and installed the update

First restart went to low graphics mode

I then went to recovery mode to fix the errors, restarting after that booted successfully

Restarting again boots to low graphics mode

I go to recovery mode again to fix the errors, restarting after that boots successfully

This repeats everytime

I have attached /var/log/Xorg.0.log

[Bryce Harrington (bryce)]

Thanks for the logs.

Unfortunately neither of these match the OP's sequence of events, and thus does not hit the problematic drm loading race that the original reporter was seeing. So, not surprising that this patch does nothing for your cases. I'd like to see someone who has Thomas' bug to test this. Specifically, if on startup you see in /var/log/Xorg.0.log a sequence of messages like this:

[ 2.555] drmOpenDevice: open result is 9, (OK)
[ 2.555] drmGetBusid returned ''
[ 2.555] (EE) intel(0): [drm] failed to set drm interface version.
[ 2.555] (EE) intel(0): Failed to become DRM master.
[ 2.555] (II) intel(0): Creating default Display subsectio

Then it's worth testing the patch in the PPA, and I think it will fix that case (or at least give us more specific data).

@Adam, I'd want to see the Xorg.0.log from the first boot, when you get dumped into low graphics mode. And maybe Xorg.0.log.old. The log you posted appears to be from a successful session so that doesn't illuminate why the failed session failed.

@Franck, it's possible your bug (#1129220) is distinct and was incorrectly duped here, but it does seem that your issue belongs with this general "class" of problems. However I think a different kind of fix will be needed in your case.

[Adam Bruce (brucey-99-deactivatedaccount)]

Sorry, please see attached. I see no mention of drm like you said

But it does seem to have done something as I could never boot before without either that xorg config file or the sleep delay

[Simon Baconnais (smon)]

Same problem here. A sleep 10 workarounnd solved it, but can't we have a fix ?

[Timo Aaltonen (tjaalton)]

Ok I have the necessary changes tested locally, and they seem to work when plymouth is started from the initrd too.

[Timo Aaltonen (tjaalton)]

for the record, plymouth and lightdm updates available on raring-proposed for testing

[Kamal Mostafa (kamalmostafa)]

I have verified that these new package versions from raring-proposed do fix the problem. Thanks!:

  lightdm (1.6.0-0ubuntu2.1)
  plymouth (0.8.8-0ubuntu6.1)

[Adam Conrad (adconrad)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lightdm - 1.6.0-0ubuntu2.1

---------------
lightdm (1.6.0-0ubuntu2.1) raring-proposed; urgency=low

  * lightdm.upstart: Add a start condition on plymouth-ready, and
    drop conditions already handled by plymouth-splash (LP: #982889).
  * control: Depend on the new plymouth version that provides plymouth-ready.
 -- Timo Aaltonen <email address hidden> Tue, 23 Apr 2013 12:10:28 +0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package plymouth - 0.8.8-0ubuntu6.1

---------------
plymouth (0.8.8-0ubuntu6.1) raring-proposed; urgency=low

  * plymouth-ready.conf: Send an event to indicate plymouth is up. Needed
    to inform login managers that they can start without racing with
    plymouth-splash. (LP: #982889)
 -- Timo Aaltonen <email address hidden> Fri, 19 Apr 2013 21:55:18 +0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package lightdm - 1.6.0-0ubuntu2.1

---------------
lightdm (1.6.0-0ubuntu2.1) raring-proposed; urgency=low

  * lightdm.upstart: Add a start condition on plymouth-ready, and
    drop conditions already handled by plymouth-splash (LP: #982889).
  * control: Depend on the new plymouth version that provides plymouth-ready.
 -- Timo Aaltonen <email address hidden> Tue, 23 Apr 2013 12:10:28 +0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package plymouth - 0.8.8-0ubuntu6.1

---------------
plymouth (0.8.8-0ubuntu6.1) raring-proposed; urgency=low

  * plymouth-ready.conf: Send an event to indicate plymouth is up. Needed
    to inform login managers that they can start without racing with
    plymouth-splash. (LP: #982889)
 -- Timo Aaltonen <email address hidden> Fri, 19 Apr 2013 21:55:18 +0300

[Brian Murray (brian-murray)]

Hello Tomas, or anyone else affected,

Accepted plymouth into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/plymouth/0.8.2-2ubuntu31.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Tomas, or anyone else affected,

Accepted lightdm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lightdm/1.2.3-0ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Miklos Juhasz (mjuhasz)]

The proposed version of lightdm/plymouth did not fix the issue for me. Lightdm sometimes fails to start, see Xorg log attached.
For now I had to put back the "and stopped udevtrigger" workaround into /etc/init/lightdm.conf. With that lightdm never failed to start for me.

[Steve Langasek (vorlon)]

Miklos, please confirm the version numbers of both lightdm and plymouth that you have installed, and please verify that all of the upstart job files for both of these packages are the unmodified versions from the package. If you already had a modified /etc/init/lightdm.conf on your system, perhaps you didn't get the new version correctly installed?

[Miklos Juhasz (mjuhasz)]

I reinstalled the proposed plymouth/lightdm packages, confirmed that I have the unmodified files from both packages.
I rebooted my desktop 30 times in a row, not a single failure. If I happen to experience the issue again I'll report back.

[Miklos Juhasz (mjuhasz)]

After all the proposed packages work fine here.
I've installed them on 2 laptops and a desktop (all suffering from this issue ) and been using them for a week. I started up these hosts several times a day and for the sake of testing I also rebooted them a couple of times every day and each time lightdm started as expected.
I also installed the packages on 2 other laptops (not suffering from this bug) and I did not spot any regression.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm - 3.6.1-0ubuntu6

---------------
gdm (3.6.1-0ubuntu6) saucy; urgency=low

  * Merge changes from lightdm to fix plymouth race (LP: #982889)
    - lightdm.upstart: Add a start condition on plymouth-ready, and
      drop conditions already handled by plymouth-splash.
    - control: Depend on the new plymouth version that provides
      plymouth-ready.
 -- Tim Lunn <email address hidden> Mon, 27 May 2013 12:41:07 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package plymouth - 0.8.2-2ubuntu31.1

---------------
plymouth (0.8.2-2ubuntu31.1) precise-proposed; urgency=low

  * plymouth-ready.conf: Send an event to indicate plymouth is up. Needed
    to inform login managers that they can start without racing with
    plymouth-splash. (LP: #982889)
 -- Timo Aaltonen <email address hidden> Fri, 03 May 2013 10:49:34 +0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package lightdm - 1.2.3-0ubuntu2.1

---------------
lightdm (1.2.3-0ubuntu2.1) precise-proposed; urgency=low

  * lightdm.upstart: Add a start condition on plymouth-ready, and
    drop conditions already handled by plymouth-splash (LP: #982889).
  * control: Depend on the new plymouth version that provides plymouth-ready.
 -- Timo Aaltonen <email address hidden> Fri, 03 May 2013 11:30:33 +0300

[William Pietri (william-launchpad-net)]

Hi! I suspect this fix may be causing a problem for me. I'm using an up to date 12.04.2 LTS setup that worked fine until now.

My symptom is that upon reboot, I end up with a black screen. By hitting Control-Alt-F1, I can get things working properly with "sudo service start lightdm". Looking at the logs, everything seems fine, except that /var/log/upstart/plymouth-ready-startup.log says "status: Unknown job: plymouth-splash".

Running "initctl check-config -w" gets me similar comments:
  setvtrgb
    start on: unknown job plymouth-splash
  plymouth-ready
    start-on: unknown job plymouth splash

I'm glad to debug further, but I can't quite figure out how this is supposed to work; the correct relationship between events is opaque to me.

[Steve Langasek (vorlon)]

William, you have a broken upstart config on your system. The /etc/init/plymouth-splash.conf system file has apparently been removed, by you, another admin, or a filesystem error. To restore it, you should run reinstall the plymouth package with the '--force-confmiss' option.

[William Pietri (william-launchpad-net)]

Thanks, Steve. The box was set up by a vendor (Emperor Linux), so perhaps they did something custom with the splash screens when I got it 18 months ago.

Aesthetically, making something vital (UI startup) depend on something decorative (splash screens) seems odd. Perhaps future versions of this can be made more robust.

In case somebody else with a similar problem finds this bug report, I verified the problem by using debsums

  % sudo debsums -a plymouth
  [most package items ok]
  debsums: missing file /etc/init/plymouth-log.conf (from plymouth package)
  debsums: missing file /etc/init/plymouth-upstart-bridge.conf (from plymouth package)
  /etc/init/plymouth.conf OK
  debsums: missing file /etc/init/plymouth-stop.conf (from plymouth package)
  /etc/init/plymouth-ready.conf OK
  debsums: missing file /etc/init/plymouth-splash.conf (from plymouth package)

And the precise command I used to fix the problem was:
  % sudo apt-get --reinstall -o Dpkg::Options::=--force-confmiss install plymouth

That put back the missing files.

I also did "sudo debsums -s" to make sure nothing else important was missing.

[Steve Langasek (vorlon)]

On Wed, Jun 05, 2013 at 05:39:07PM -0000, William Pietri wrote:
> Aesthetically, making something vital (UI startup) depend on something
> decorative (splash screens) seems odd. Perhaps future versions of this
> can be made more robust.

To clarify, plymouth is not "merely decorative". It is the boot-time
interface used for interacting with the user regarding any boot problems; so
it's always present, and it needs to hand off control of the console
reliably to lightdm, which means that the lightdm job can't start until it
knows for sure plymouth has started up.

[Johann Gail (johann-gail)]

Either this fix isn't complete or I have a similar problem.

On my fast hardware (a Clevo W370ET with SSD and a quad core i7) I observe the same effects. Even after updating to latest versions I get the fault. I'm running raring (XUbuntu 13.04).

I observe at 50% of booting a black screen with a blinking cursor and a mousepointer. I can switch to a terminal console and by entering the command "sudo service lightdm restart" I get a running graphical session.

Also the workaround at comment #5, inserting a sleep 1 in lightdm.conf does help. But I doesn't like the idea of solving a race condition by inserting some sleep. Especially on a fast booting ssd notebook.

Should I open a new bug report or should I continue tis one?

[Brian Murray (brian-murray)]

Hello Tomas, or anyone else affected,

Accepted gdm into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gdm/3.6.1-0ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[the foodmonkey (foodmonkey)]

ok - the fix might have been releaased but can someone please let those idiots at intel open technologies know about the fix - i used theirrepos to install the latest intel graphics stack - which then results i a distro upgrade and whammo - had to put the "sleep 10" workaround into /etc/init/lightdm.conf so it wouldn't boot into low graphics mode - seems like the boys from intel are using an old baseline for their kernel mods

[Steve Langasek (vorlon)]

Hello Tomas, or anyone else affected,

Accepted gdm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gdm/3.0.4-0ubuntu15.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Philippe Coval (rzr)]

Wondering why this bug has not been forwarded upstream ?

https://bugs.freedesktop.org/show_bug.cgi?id=42972

does not mention about :

     setversion 1.4 failed

nor https://bugzilla.redhat.com/show_bug.cgi?id=855677

Also I feel the patch worth to be forwarded/upstreamed too :

https://launchpadlibrarian.net/131169748/0001-If-drm-device-couldn-t-be-opened-keep-trying-for-a-s.patch

[Timo Aaltonen (tjaalton)]

because it's not the same bug

[Philippe Coval (rzr)]

Well I forwarded the patch to that closed bug anyway since look like userspace race too ...

Next step would be to open a new one and update that patch (see TODO ) to see if upstream want to integrate this sleep workaround or give hints to fix this elsewhere ...

[Franz Hsieh (franz-hsieh)]

We have the same problem on the platfrom runs with Ubuntu 12.04.2 with quantal backported.

I reviewed the raring patch from https://launchpad.net/ubuntu/+source/xorg-server/2:1.13.2-0ubuntu3 and tried to backport it to 12.04.2.
It looks work fine on our platfrom.

[Steve Langasek (vorlon)]

Maarten, is this something you could have a look at?

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm - 3.0.4-0ubuntu15.2

---------------
gdm (3.0.4-0ubuntu15.2) precise; urgency=low

  * Merge changes from lightdm to fix plymouth race (LP: #982889)
    - lightdm.upstart: Add a start condition on plymouth-ready, and
      drop conditions already handled by plymouth-splash.
    - control: Depend on the new plymouth version that provides plymouth-ready.
 -- Tim Lunn <email address hidden> Thu, 23 May 2013 17:45:44 +1000

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm - 3.6.1-0ubuntu4.1

---------------
gdm (3.6.1-0ubuntu4.1) raring; urgency=low

  * Merge changes from lightdm to fix plymouth race (LP: #982889)
    - lightdm.upstart: Add a start condition on plymouth-ready, and
      drop conditions already handled by plymouth-splash.
    - control: Depend on the new plymouth version that provides plymouth-ready.
 -- Tim Lunn <email address hidden> Thu, 23 May 2013 17:45:44 +1000

[Mathew Hodson (mathew-hodson)]

The gdm oackages in raring and precise-proposed have been released so removing the verification-needed tag.

[Rolf Leggewie (r0lf)]

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".

[Rolf Leggewie (r0lf)]

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[gna (nagy-gergely)]

I know rather old thing, but this got irritating me now. one bit of info:

This shows that plymouth-ready is after lightdm...

/var/lib/plymouth/boot-duration
0.978:avahi-daemon
0.979:statd
0.979:udev-finish
0.993:rc-sysinit
0.993:rc
0.993:tty4
0.993:tty5
0.993:acpid
0.993:anacron
0.993:tty2
0.993:tty3
0.993:dmesg
0.993:tty6
0.993:plymouth-stop
0.993:cron
0.993:atd
0.993:irqbalance
0.993:whoopsie
0.993:libvirt-bin
0.994:apport
0.995:qemu-kvm
0.998:lightdm
0.999:plymouth-ready

[Stu (stu-axon)]

Just confirming that on 15.04 I get the symptoms mentioned in

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1115177

Where Nouveau won't load, which is apparently because of this bug

[ 27074.122] (II) [drm] nouveau interface version: 1.2.1
[ 27074.122] (II) Loading sub module "dri2"
[ 27074.122] (II) LoadModule: "dri2"
[ 27074.122] (II) Module "dri2" already built-in
[ 27074.122] (EE) NOUVEAU(0): [drm] failed to set drm interface version.
[ 27074.122] (EE) NOUVEAU(0): [drm] error opening the drm
[ 27074.122] (EE) NOUVEAU(0): 904:
[ 27074.122] (II) UnloadModule: "nouveau"
[ 27074.122] (EE) Screen(s) found, but none have a usable configuration.
[ 27074.122] (EE)
Fatal server error:
[ 27074.122] (EE) no screens found(EE)
[ 27074.122] (EE)