Ubuntu

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

Reported by Tomas Vanderka on 2012-04-16
750
This bug affects 91 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
High
James M. Leddy
Precise
High
James M. Leddy
gdm (Ubuntu)
Undecided
Tim
Precise
Undecided
Unassigned
Raring
Undecided
Unassigned
Saucy
Undecided
Tim
kde-workspace (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Unassigned
Raring
Undecided
Unassigned
Saucy
Undecided
Unassigned
lightdm (Ubuntu)
Critical
Timo Aaltonen
Precise
High
Timo Aaltonen
Raring
Critical
Timo Aaltonen
Saucy
Undecided
Unassigned
plymouth (Ubuntu)
Critical
Timo Aaltonen
Precise
High
Timo Aaltonen
Raring
Critical
Timo Aaltonen
Saucy
Undecided
Unassigned
xorg-server-lts-quantal (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Maarten Lankhorst
Raring
Undecided
Unassigned
Saucy
Undecided
Unassigned

Bug Description

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

Tomas Vanderka (tomas-vanderka) wrote :
affects: ubuntu → xorg (Ubuntu)
Bryce Harrington (bryce) on 2012-04-16
affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Bryce Harrington (bryce) wrote :

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.

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Bryce Harrington (bryce) on 2012-04-16
summary: - xorg fails to start after boot on core i5
+ X trying to start faster than drm driver is ready

Meanwhile, can you post the output of sudo lshw?

Changed in xserver-xorg-video-intel (Ubuntu):
status: Triaged → Incomplete
Bryce Harrington (bryce) wrote :

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

Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → New
status: New → Incomplete
Bryce Harrington (bryce) wrote :

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

    sleep 10
    exec lightdm

Bryce Harrington (bryce) wrote :

<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) wrote :

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) wrote :

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...

affects: xserver-xorg-video-intel (Ubuntu) → libdrm (Ubuntu)
Changed in libdrm (Ubuntu):
status: Incomplete → Triaged
Tomas Vanderka (tomas-vanderka) wrote :

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) wrote :

<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

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

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.

Maybe related to #927684 #899725

Andy Whitcroft (apw) wrote :

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.

Andy Whitcroft (apw) on 2012-04-20
Changed in linux (Ubuntu):
assignee: nobody → Andy Whitcroft (apw)
status: New → Incomplete
Download full text (12.2 KiB)

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...

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

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.

Changed in linux (Ubuntu):
importance: Undecided → Medium
Bryce Harrington (bryce) wrote :

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

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

Changed in libdrm (Ubuntu):
status: Triaged → Incomplete

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) wrote :

bug #966868 may be a dupe of this issue

summary: - X trying to start faster than drm driver is ready
+ X trying to start before plymouth has finished using the drm driver
Launchpad Janitor (janitor) wrote :

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

Changed in xorg-server (Ubuntu):
status: New → Confirmed
ben (ben-nerdlabor) wrote :

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) wrote :

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.

Timo Aaltonen (tjaalton) on 2013-01-14
tags: added: quantal
Bryce Harrington (bryce) on 2013-02-04
Changed in xorg-server (Ubuntu):
assignee: nobody → Bryce Harrington (bryce)
tags: added: raring
Bryce Harrington (bryce) wrote :

Bug #1037518 is a dupe.

Changed in xorg-server (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Critical
Changed in linux (Ubuntu):
status: Incomplete → New
Changed in libdrm (Ubuntu):
status: Incomplete → Triaged
assignee: nobody → Bryce Harrington (bryce)
importance: Medium → Critical

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Eddie B (fasteddieb216) wrote :

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) wrote :
tags: added: patch
Bryce Harrington (bryce) wrote :

Similar patch, for xorg-server.

Changed in xorg-server (Ubuntu):
status: Triaged → In Progress
Chris Wilson (ickle) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Adam Bruce (brucey-99) wrote :
Changed in xorg-server (Ubuntu):
status: In Progress → Fix Released
Changed in plymouth (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Invalid
Changed in libdrm (Ubuntu):
status: Triaged → Invalid
Changed in lightdm (Ubuntu):
status: New → Confirmed
assignee: nobody → Maarten Lankhorst (mlankhorst)
Changed in plymouth (Ubuntu):
assignee: nobody → Maarten Lankhorst (mlankhorst)
Changed in lightdm (Ubuntu):
status: Confirmed → Invalid
status: Invalid → Confirmed
75 comments hidden view all 155 comments
Franck (alci) wrote :

Just a question: what if the no-splash is passed as a boot option ? Or if plymouth is removed ?

On Wed, Mar 27, 2013 at 07:14:39AM -0000, Franck wrote:
> Just a question: what if the no-splash is passed as a boot option ?

That only controls whether you have a graphical splash, not whether the
plymouth-splash job runs.

> Or if plymouth is removed ?

That is absolutely unsupported.

Changed in lightdm (Ubuntu):
importance: Undecided → Critical
Robert Hooker (sarvatt) on 2013-03-27
Changed in lightdm (Ubuntu):
status: Confirmed → Triaged
Steve Magoun (smagoun) on 2013-04-01
Changed in oem-priority:
importance: Undecided → Critical
Steve Magoun (smagoun) on 2013-04-02
Changed in oem-priority:
status: New → In Progress
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/982889

tags: added: iso-testing
Robert Hooker (sarvatt) wrote :

plymouth:debug log from a failed boot from tjaalton

Timo Aaltonen (tjaalton) wrote :

So, the proposed change from #115 doesn't work if plymouth is started from the initramfs, like when cryptsetup is used. In such a case no 'started plymouth-splash' is ever emitted, so something else needs to be used:

00:34 < tjaalton> slangasek: heh, yeah. I was wondering if there was some more generic event to abuse here
00:36 < slangasek> tjaalton: not really, we need to create one - either by fixing it in upstart, or by adding a
                   secondary job that's 'start on startup or started plymouth-splash', checks for plymouth-splash
                   running already, and emits an appropriate common event
00:36 < tjaalton> slangasek: right, that could work
00:36 < tjaalton> as an interim solution
00:37 < slangasek> tjaalton: and by 'checks for plymouth splash running', I mean checking the output of 'status
                   plymouth-splash'

fixing upstart means "synthesizing 'started' events for jobs started from initramfs", but in the meantime the other approach could be used.

manatorg (manatorg) wrote :

Hi,

had the same problem.

 /etc/init/lightdm.conf:
   ...
    sleep 2
    exec lightdm
    ...

sleep 2 was enough to solve the problem for me.

i am using intel graphics an a l520 with a ssd (msata)

James M. Leddy (jm-leddy) wrote :

Moving to High prio in oem-priority since we have a workaround.

Changed in oem-priority:
assignee: nobody → James M. Leddy (jm-leddy)
importance: Critical → High
Simon Baconnais (smon) wrote :

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

Timo Aaltonen (tjaalton) on 2013-04-19
no longer affects: libdrm (Ubuntu)
Timo Aaltonen (tjaalton) wrote :

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

no longer affects: xorg-server (Ubuntu)
no longer affects: linux (Ubuntu)
Changed in plymouth (Ubuntu Raring):
assignee: Maarten Lankhorst (mlankhorst) → Timo Aaltonen (tjaalton)
importance: Undecided → Critical
status: Confirmed → In Progress
Changed in lightdm (Ubuntu Raring):
assignee: Maarten Lankhorst (mlankhorst) → Timo Aaltonen (tjaalton)
status: Triaged → In Progress
Timo Aaltonen (tjaalton) wrote :

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

Changed in lightdm (Ubuntu Raring):
status: In Progress → Fix Committed
Changed in plymouth (Ubuntu Raring):
status: In Progress → Fix Committed
Robert Hooker (sarvatt) on 2013-04-24
tags: added: verification-needed
Kamal Mostafa (kamalmostafa) wrote :

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)

tags: added: verification-done
removed: verification-needed

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) wrote :

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

Changed in lightdm (Ubuntu Raring):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in plymouth (Ubuntu Raring):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Saucy):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in plymouth (Ubuntu Saucy):
status: New → Fix Released
Timo Aaltonen (tjaalton) on 2013-05-02
Changed in lightdm (Ubuntu Precise):
assignee: nobody → Timo Aaltonen (tjaalton)
importance: Undecided → High
status: New → Triaged
Changed in plymouth (Ubuntu Precise):
assignee: nobody → Timo Aaltonen (tjaalton)
importance: Undecided → High
status: New → Triaged

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!

Changed in plymouth (Ubuntu Precise):
status: Triaged → Fix Committed
tags: removed: verification-done
tags: added: verification-needed
Changed in lightdm (Ubuntu Precise):
status: Triaged → Fix Committed
Brian Murray (brian-murray) wrote :

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) wrote :

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.

tags: added: verification-failed
removed: verification-needed
Steve Langasek (vorlon) wrote :

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) wrote :

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.

Steve Langasek (vorlon) on 2013-05-20
tags: added: verification-needed
removed: verification-failed
Tim (darkxst) on 2013-05-23
Changed in gdm (Ubuntu Saucy):
assignee: nobody → Tim (darkxst)
Miklos Juhasz (mjuhasz) wrote :

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.

Steve Langasek (vorlon) on 2013-05-26
tags: added: verification-done
removed: verification-needed
Martin Pitt (pitti) on 2013-05-27
Changed in gdm (Ubuntu Saucy):
status: New → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in gdm (Ubuntu Saucy):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in plymouth (Ubuntu Precise):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Precise):
status: Fix Committed → Fix Released
Changed in oem-priority:
status: In Progress → Fix Released

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) wrote :

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.

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.

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) wrote :

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?

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!

Changed in gdm (Ubuntu Raring):
status: New → Fix Committed
tags: removed: verification-done
tags: added: verification-needed
the foodmonkey (foodmonkey) wrote :

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

tags: added: saucy
Steve Langasek (vorlon) wrote :

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!

Changed in gdm (Ubuntu Precise):
status: New → Fix Committed
Philippe Coval (rzr) wrote :

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) wrote :

because it's not the same bug

Philippe Coval (rzr) wrote :

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) wrote :

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) wrote :

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

Changed in xorg-server-lts-quantal (Ubuntu Raring):
status: New → Invalid
Changed in xorg-server-lts-quantal (Ubuntu Saucy):
status: New → Invalid
Changed in xorg-server-lts-quantal (Ubuntu Precise):
assignee: nobody → Maarten Lankhorst (mlankhorst)
milestone: none → ubuntu-12.04.4
status: New → Triaged
Launchpad Janitor (janitor) wrote :

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

Changed in gdm (Ubuntu Precise):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in gdm (Ubuntu Raring):
status: Fix Committed → Fix Released
Displaying first 40 and last 40 comments. View all 155 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.