X trying to start before plymouth has finished using the drm driver
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OEM Priority Project |
High
|
James M. Leddy | |||
Precise |
High
|
James M. Leddy | |||
gdm (Ubuntu) |
Medium
|
Tim Lunn | |||
Precise |
Medium
|
Unassigned | |||
Raring |
Medium
|
Unassigned | |||
Saucy |
Medium
|
Tim Lunn | |||
lightdm (Ubuntu) |
Critical
|
Timo Aaltonen | |||
Precise |
High
|
Timo Aaltonen | |||
Raring |
Critical
|
Timo Aaltonen | |||
Saucy |
High
|
Unassigned | |||
plymouth (Ubuntu) |
Critical
|
Timo Aaltonen | |||
Precise |
High
|
Timo Aaltonen | |||
Raring |
Critical
|
Timo Aaltonen | |||
Saucy |
High
|
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
ProcVersionSign
Uname: Linux 3.2.0-23-generic x86_64
.tmp.unity.
ApportVersion: 2.0.1-0ubuntu3
Architecture: amd64
CompizPlugins: [core,composite
CompositorRunning: compiz
Date: Mon Apr 16 10:35:28 2012
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
ExtraDebuggingI
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=
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.
dmi.board.name: Z68A-G43 (G3) (MS-7750)
dmi.board.vendor: MSI
dmi.board.version: 1.0
dmi.chassis.
dmi.chassis.type: 3
dmi.chassis.vendor: MSI
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: MS-7750
dmi.product.
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.
version.
version.
version.
version.
version.
version.
version.
Related branches
- Martin Pitt: Approve on 2013-05-27
-
Diff: 64 lines (+14/-4)4 files modifieddebian/changelog (+9/-0)
debian/control (+2/-1)
debian/control.in (+1/-0)
debian/gdm.upstart (+2/-3)
- Martin Pitt: Approve on 2013-06-24
- Dmitry Shachnev: Needs Information on 2013-06-08
-
Diff: 64 lines (+14/-4)4 files modifieddebian/changelog (+9/-0)
debian/control (+2/-1)
debian/control.in (+1/-0)
debian/gdm.upstart (+2/-3)
- Ubuntu branches: Pending requested 2013-05-29
-
Diff: 43 lines (+12/-3)3 files modifieddebian/changelog (+9/-0)
debian/control.in (+1/-0)
debian/gdm.upstart (+2/-3)
Tomas Vanderka (tomas-vanderka) wrote : | #1 |
affects: | ubuntu → xorg (Ubuntu) |
affects: | xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu) |
Bryce Harrington (bryce) wrote : | #2 |
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Medium |
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 : | #4 |
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 : | #5 |
A workaround is to add some sleep to /etc/init/
sleep 10
exec lightdm
Bryce Harrington (bryce) wrote : | #6 |
<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 : | #7 |
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 : | #8 |
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 : | #9 |
Putting "sleep 1" in /etc/init/
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
Tomas Vanderka (tomas-vanderka) wrote : | #10 |
Bryce Harrington (bryce) wrote : | #11 |
<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 6d74feca6235b46
<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) wrote : | #12 |
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) wrote : | #13 |
Tomas Vanderka (tomas-vanderka) wrote : | #14 |
Tomas Vanderka (tomas-vanderka) wrote : | #15 |
I looked at the code and it seems it fails somewhere in kernel drm_setversion ioctl after being called from libdrm drmSetInterface
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) wrote : | #16 |
Maybe related to #927684 #899725
Andy Whitcroft (apw) wrote : | #17 |
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://
Thanks in advanced.
Changed in linux (Ubuntu): | |
assignee: | nobody → Andy Whitcroft (apw) |
status: | New → Incomplete |
Tomas Vanderka (tomas-vanderka) wrote : | #18 |
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=
Apr 21 02:25:35 kujoniq kernel: [ 0.000000] Kernel command line: BOOT_IMAGE=
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_
Apr 21 02:25:35 kujoniq kernel: [ 2.497977] [drm:drm_
Apr 21 02:25:35 kujoniq kernel: [ 2.498099] [drm:drm_
Apr 21 02:25:35 kujoniq kernel: [ 2.498101] [drm:drm_
Apr 21 02:25:35 kujoniq kernel: [ 2.498161] [drm:drm_
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_
Apr 21 02:25:35 kujoniq kernel: [ 2.552960] [drm:drm_
Apr 21 02:25:35 kujoniq kernel: [ 2.567174] [drm:drm_
Apr 21 02:25:35 kujoniq kernel: [ 2.567194] [drm:drm_
Apr 21 02:25:35 kujoniq kernel: [ 2.567201] [drm:drm_
Apr 21 02:25:35 kujoniq kernel: [ 2.567235] [drm:drm_
Apr 21 02:25:35 kujoniq kernel: [ 2.676194] [drm:drm_
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_
Apr 21 02:25:36 kujoniq kernel: [ 2.951148] [drm:drm_
Apr 21 02:25:36 kujoniq kernel: [ 2.951151] [drm:drm_
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_
Apr 21 02:25:36 kujoniq kernel: [ 2.997510] [drm:drm_
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) wrote : | #19 |
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_
Apr 21 02:28:24 kujoniq kernel: [ 2.826854] [drm:drm_
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_
Apr 21 02:28:24 kujoniq kernel: [ 2.826890] [drm:drm_
Apr 21 02:28:24 kujoniq kernel: [ 2.826892] [drm:drm_
Apr 21 02:28:24 kujoniq kernel: [ 2.826905] [drm:drm_
Apr 21 02:28:24 kujoniq kernel: [ 2.826906] [drm:drm_
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) wrote : | #20 |
After disabling plymouth-splash I can't reproduce this anymore.
It's a race between plymouth and xorg. Plymouth holds DRM master (drm_setmaster_
It works fine if
1. plymouth never starts
2. plymouth calls drm_dropmaster_
And another thing is the Xorg.log timestamps can't really be trusted.
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
Bryce Harrington (bryce) wrote : | #21 |
Tomas, did you ever get a chance to test the kernel apw posted in comment #17?
Changed in libdrm (Ubuntu): | |
status: | Triaged → Incomplete |
Tomas Vanderka (tomas-vanderka) wrote : | #22 |
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 : | #23 |
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 : | #24 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in xorg-server (Ubuntu): | |
status: | New → Confirmed |
ben (roboben) wrote : | #25 |
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 : | #26 |
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.
tags: | added: quantal |
Changed in xorg-server (Ubuntu): | |
assignee: | nobody → Bryce Harrington (bryce) |
tags: | added: raring |
Bryce Harrington (bryce) wrote : | #27 |
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 : | #29 |
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:/
I would much rather use the Radeon card if possible.
Bryce Harrington (bryce) wrote : | #30 |
tags: | added: patch |
Bryce Harrington (bryce) wrote : | #31 |
Similar patch, for xorg-server.
Changed in xorg-server (Ubuntu): | |
status: | Triaged → In Progress |
Franck (alci) wrote : | #32 |
Chris Wilson (ickle) wrote : | #33 |
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 : | #34 |
I've packaged the patch in the following PPA:
https:/
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 : | #35 |
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 : | #36 |
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.
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 : | #38 |
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.
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
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 |
Changed in lightdm (Ubuntu): | |
importance: | Undecided → Critical |
Changed in lightdm (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in oem-priority: | |
importance: | Undecided → Critical |
Changed in oem-priority: | |
status: | New → In Progress |
tags: | added: iso-testing |
Changed in oem-priority: | |
assignee: | nobody → James M. Leddy (jm-leddy) |
importance: | Critical → High |
Same problem here. A sleep 10 workarounnd solved it, but can't we have a fix ?
no longer affects: | libdrm (Ubuntu) |
Timo Aaltonen (tjaalton) wrote : | #124 |
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 : | #125 |
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 |
tags: | added: verification-needed |
Kamal Mostafa (kamalmostafa) wrote : | #126 |
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 : | #128 |
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 : | #129 |
This bug was fixed in the package plymouth - 0.8.8-0ubuntu6.1
---------------
plymouth (0.8.8-0ubuntu6.1) raring-proposed; urgency=low
* plymouth-
to inform login managers that they can start without racing with
plymouth-
-- 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 : | #130 |
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 : | #131 |
This bug was fixed in the package plymouth - 0.8.8-0ubuntu6.1
---------------
plymouth (0.8.8-0ubuntu6.1) raring-proposed; urgency=low
* plymouth-
to inform login managers that they can start without racing with
plymouth-
-- Timo Aaltonen <email address hidden> Fri, 19 Apr 2013 21:55:18 +0300
Changed in plymouth (Ubuntu Saucy): | |
status: | New → Fix Released |
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://
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
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 : | #133 |
Hello Tomas, or anyone else affected,
Accepted lightdm into precise-proposed. The package will build now and be available at http://
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
Miklos Juhasz (mjuhasz) wrote : | #134 |
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/
tags: |
added: verification-failed removed: verification-needed |
Steve Langasek (vorlon) wrote : | #135 |
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/
Miklos Juhasz (mjuhasz) wrote : | #136 |
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.
tags: |
added: verification-needed removed: verification-failed |
Changed in gdm (Ubuntu Saucy): | |
assignee: | nobody → Tim (darkxst) |
Miklos Juhasz (mjuhasz) wrote : | #137 |
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.
tags: |
added: verification-done removed: verification-needed |
Changed in gdm (Ubuntu Saucy): | |
status: | New → Fix Committed |
Launchpad Janitor (janitor) wrote : | #138 |
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-
-- 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 : | #139 |
This bug was fixed in the package plymouth - 0.8.2-2ubuntu31.1
---------------
plymouth (0.8.2-2ubuntu31.1) precise-proposed; urgency=low
* plymouth-
to inform login managers that they can start without racing with
plymouth-
-- 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 : | #140 |
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/
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 : | #142 |
William, you have a broken upstart config on your system. The /etc/init/
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/
debsums: missing file /etc/init/
/etc/
debsums: missing file /etc/init/
/etc/
debsums: missing file /etc/init/
And the precise command I used to fix the problem was:
% sudo apt-get --reinstall -o Dpkg::Options:
That put back the missing files.
I also did "sudo debsums -s" to make sure nothing else important was missing.
Steve Langasek (vorlon) wrote : Re: [Bug 982889] Re: X trying to start before plymouth has finished using the drm driver | #144 |
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 : | #145 |
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://
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
Changed in gdm (Ubuntu Raring): | |
status: | New → Fix Committed |
tags: | removed: verification-done |
tags: | added: verification-needed |
the foodmonkey (foodmonkey) wrote : | #147 |
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/
tags: | added: saucy |
Steve Langasek (vorlon) wrote : | #148 |
Hello Tomas, or anyone else affected,
Accepted gdm into precise-proposed. The package will build now and be available at http://
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
Changed in gdm (Ubuntu Precise): | |
status: | New → Fix Committed |
Philippe Coval (rzr) wrote : | #149 |
Wondering why this bug has not been forwarded upstream ?
https:/
does not mention about :
setversion 1.4 failed
nor https:/
Also I feel the patch worth to be forwarded/
Timo Aaltonen (tjaalton) wrote : | #150 |
because it's not the same bug
Philippe Coval (rzr) wrote : | #151 |
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 : | #152 |
We have the same problem on the platfrom runs with Ubuntu 12.04.2 with quantal backported.
I reviewed the raring patch from https:/
It looks work fine on our platfrom.
Steve Langasek (vorlon) wrote : | #153 |
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 : | #154 |
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 : | #155 |
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 |
Mathew Hodson (mhodson) wrote : | #156 |
The gdm oackages in raring and precise-proposed have been released so removing the verification-needed tag.
tags: | removed: verification-needed |
Rolf Leggewie (r0lf) wrote : | #157 |
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".
Changed in kde-workspace (Ubuntu Raring): | |
status: | New → Won't Fix |
Rolf Leggewie (r0lf) wrote : | #158 |
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".
Changed in kde-workspace (Ubuntu Saucy): | |
status: | New → Won't Fix |
Launchpad Janitor (janitor) wrote : | #159 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in kde-workspace (Ubuntu Precise): | |
status: | New → Confirmed |
Changed in kde-workspace (Ubuntu): | |
status: | New → Confirmed |
gna (nagy-gergely) wrote : | #161 |
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/
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-
Stu (stu-axon) wrote : | #162 |
Just confirming that on 15.04 I get the symptoms mentioned in
https:/
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)
Changed in xorg-server-lts-quantal (Ubuntu Precise): | |
assignee: | Maarten Lankhorst (mlankhorst) → nobody |
milestone: | ubuntu-12.04.4 → none |
status: | Triaged → Won't Fix |
no longer affects: | xorg-server-lts-quantal (Ubuntu Saucy) |
no longer affects: | xorg-server-lts-quantal (Ubuntu Raring) |
no longer affects: | xorg-server-lts-quantal (Ubuntu Precise) |
no longer affects: | xorg-server-lts-quantal (Ubuntu) |
no longer affects: | kde-workspace (Ubuntu Saucy) |
no longer affects: | kde-workspace (Ubuntu Raring) |
no longer affects: | kde-workspace (Ubuntu Precise) |
no longer affects: | kde-workspace (Ubuntu) |
Changed in lightdm (Ubuntu Saucy): | |
importance: | Undecided → High |
Changed in plymouth (Ubuntu Saucy): | |
importance: | Undecided → High |
Changed in gdm (Ubuntu): | |
importance: | Undecided → High |
Changed in gdm (Ubuntu Precise): | |
importance: | Undecided → Medium |
Changed in gdm (Ubuntu): | |
importance: | High → Medium |
Changed in gdm (Ubuntu Raring): | |
importance: | Undecided → Medium |
Changed in gdm (Ubuntu Saucy): | |
importance: | Undecided → Medium |
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.