[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot

Bug #1066883 reported by Para Siva on 2012-10-15
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
lightdm (Ubuntu)
High
Unassigned
Quantal
High
Unassigned
Raring
Undecided
Unassigned
Saucy
High
Unassigned
linux (Ubuntu)
High
Andy Whitcroft
Quantal
High
Andy Whitcroft
Raring
Undecided
Unassigned
Saucy
High
Andy Whitcroft

Bug Description

Fatal server error: Can not run in framebuffer mode error occurs on the 2nd reboot onwards on a mac with external display.
The first reboot after a fresh installation is working fine and from the second attempt the desktop fails to start on the standard graphics mode and 'Your screen, graphics card, and input device settings could not be detected correctly....' error message is displayed.

The logs attached are directly from the first reboot.

A tar file will be added with the logs after the failure.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: xorg 1:7.7+1ubuntu4
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.6.1-0ubuntu3
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CurrentDmesg:

Date: Mon Oct 15 14:37:01 2012
DistUpgraded: Fresh install
DistroCodename: quantal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Apple Inc. Device [106b:00e6]
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64+mac (20121014)
MachineType: Apple Inc. Macmini5,1
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-17-generic root=UUID=f5eb805b-ed9d-43f3-a316-9b906251e9d5 ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/20/2011
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MM51.88Z.0077.B0F.1110201309
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-8ED6AF5B48C039E1
dmi.board.vendor: Apple Inc.
dmi.board.version: Macmini5,1
dmi.chassis.type: 16
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-8ED6AF5B48C039E1
dmi.modalias: dmi:bvnAppleInc.:bvrMM51.88Z.0077.B0F.1110201309:bd10/20/2011:svnAppleInc.:pnMacmini5,1:pvr1.0:rvnAppleInc.:rnMac-8ED6AF5B48C039E1:rvrMacmini5,1:cvnAppleInc.:ct16:cvrMac-8ED6AF5B48C039E1:
dmi.product.name: Macmini5,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
version.compiz: compiz 1:0.9.8.4-0ubuntu2
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.39-0ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.0-0ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.0-0ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.13.0-0ubuntu6
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.99.99~git20120913.8637f772-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.20.9-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.2-0ubuntu3

Para Siva (psivaa) wrote :
description: updated
Para Siva (psivaa) wrote :

The above logs were taken from the first boot, hence does not have the error information. The attached tar contains the log after the failure

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/1066883

tags: added: iso-testing
Para Siva (psivaa) wrote :

Reproducible with 20121015.2 as well, after entire disk fresh installation

Jean-Baptiste Lallement (jibel) wrote :

Similar to bug 1066228

Changed in xorg (Ubuntu Quantal):
importance: Undecided → High
Changed in linux (Ubuntu Quantal):
importance: Undecided → High
Brad Figg (brad-figg) on 2012-10-16
Changed in linux (Ubuntu):
status: New → Confirmed
Para Siva (psivaa) wrote :

When attempted with plymouth-splash disabled I am able to bring up the desktop in the standard graphics mode. When plymouth-splash was re-enabled, the issue is reproducible with mainline kernel 3.5.5.

Para Siva (psivaa) wrote :

Was able to reproduce with 3.5.4 mainline kernel version as well

Para Siva (psivaa) wrote :

Occurs with 3.5.3 mainline kernel as well with plymouth-splash enabled

Andy Whitcroft (apw) on 2012-10-16
summary: - Fatal server error: Can not run in framebuffer mode on reboot
+ [Macmini 5,1] Fatal server error: Can not run in framebuffer mode on
+ reboot
Para Siva (psivaa) wrote :

A fresh install with quantal desktop - amd+mac 20121011 also has the same issue. First boot after the installation went well but the subsequent ones do not boot in standard graphics mode.

Para Siva (psivaa) wrote :

When tried with 20120724.2 amd+mac quantal desktop, this issue was not reproducible (with ~10 reboots). Hence looking at bug 1066228 it appears be a regression that occurred between alpha3 and beta 1.

Para Siva (psivaa) wrote :

So here is the list of test runs,

20120724.2 -> worked
20120918.1->worked
20121001 -> worked
20121011 -> FAILED

The kernel was updated to the latest on top of a working 20121001 and it still worked

Andy Whitcroft (apw) wrote :

@psivaa -- when updating the kernel there on 20121001 can you confirm that multiple boots were good. Also on the latest image (known bad) does it work for the next boot if you remove /var/lib/ureadahead/pack before reboot?

Para Siva (psivaa) wrote :

@apw
Rebooted many times (more than 20) after updating the kernel to the latest on a known (20121001) good image, it worked ok, no failures could be observed.

Removing /var/lib/ureadahead/pack from the known bad image seem to solve the issue.

When it was made sure the file is removed before the reboot, the next reboot did not have this issue, the desktop came up on the standard gfx mode. When the file was present the next reboot failed, not so deterministically every time, but most of the times.

Changed in xorg (Ubuntu Quantal):
assignee: nobody → Canonical X.org (canonical-x)
Andy Whitcroft (apw) wrote :

@psivaa -- ok cool so that confirms it is most likely an initialisation race. Could we get dmesg from a good boot (ie without the pack) and the next bad boot (with the pack), and attach them to this bug please. Do make sure they are clearly labelled :)

Thanks.

Para Siva (psivaa) wrote :
Para Siva (psivaa) wrote :
Para Siva (psivaa) wrote :

Failure was observed in the second boot

Bryce Harrington (bryce) wrote :

This looks to me more like a plymouth issue holding on to the framebuffer too long, rather than an X issue. apw's probably the right guy to look into this so will unassign X from it; feel free to re-add us if there's something for us to do.

affects: xorg (Ubuntu Quantal) → plymouth (Ubuntu Quantal)
Changed in plymouth (Ubuntu Quantal):
assignee: Canonical X.org (canonical-x) → nobody
Changed in linux (Ubuntu Quantal):
assignee: nobody → Andy Whitcroft (apw)
Steve Langasek (vorlon) wrote :

lightdm is responsible for killing plymouth before starting X, so this can't be a plymouth bug. It may be a bug in the drm layer being triggered by plymouth.

If booting with plymouth-splash intact, after triggering the bug, is it possible to switch to a console and run 'sudo service lightdm restart'? Does X then start up correctly?

It may be useful to get the dmesg output of a failed boot with --verbose added to the kernel commandline, to get information about the ordering of the upstart jobs on boot.

Para Siva (psivaa) wrote :

If booting with plymouth-splash intact, after triggering the bug, is it possible to switch to a console and run 'sudo service lightdm restart'? Does X then start up correctly?
 >>> Yes it was possible to switch to console and Yes X does start correctly

dmesg output of a failed boot with --verbose added to the kernel commandline
>>> attached -- file named 'failed_dmesg_with_verbose'

Steve Langasek (vorlon) wrote :

dmesg shows the below output. plymouth is clearly being stopped by lightdm (not by /etc/init/plymouth-stop.conf), so we're not hitting a race in the plymouth jobs. But after stopping plymouth, lightdm hits the problem with the X server and exits.

I think this is clearly a problem with either the kernel or with lightdm.

[ 15.801383] init: lightdm goal changed from stop to start
[ 15.801430] init: lightdm state changed from waiting to starting
[ 15.801559] init: plymouth-splash goal changed from stop to start
[ 15.801605] init: plymouth-splash state changed from waiting to starting
[...]
[ 15.803513] init: plymouth-stop goal changed from stop to start
[ 15.803563] init: plymouth-stop state changed from waiting to starting
[...]
[ 15.806338] init: plymouth-stop state changed from starting to pre-start
[ 15.806828] init: plymouth-stop pre-start process (1133)
[...]
[ 15.809173] init: plymouth-stop pre-start process (1133) exited normally
[ 15.809314] init: plymouth-stop state changed from pre-start to spawned
[ 15.809398] init: plymouth-stop state changed from spawned to post-start
[ 15.809477] init: plymouth-stop state changed from post-start to running
[...]
[ 15.811474] init: lightdm state changed from starting to pre-start
[ 15.811752] init: lightdm state changed from pre-start to spawned
[ 15.812406] init: lightdm main process (1136)
[ 15.812499] init: lightdm state changed from spawned to post-start
[ 15.812818] init: lightdm state changed from post-start to running
[...]
[ 15.817462] init: plymouth-splash state changed from starting to pre-start
[ 15.817511] init: plymouth-splash state changed from pre-start to spawned
[ 15.820635] init: plymouth-splash main process (1146)
[ 15.820690] init: plymouth-splash state changed from spawned to post-start
[ 15.820908] init: plymouth-splash state changed from post-start to running
[...]
[ 16.573039] init: plymouth-splash main process (1146) exited normally
[ 16.573104] init: plymouth-splash goal changed from start to stop
[ 16.573184] init: plymouth-splash state changed from running to stopping
[ 16.573242] init: Handling stopping event
[ 16.573332] init: plymouth-splash state changed from stopping to killed
[ 16.573382] init: plymouth-splash state changed from killed to post-stop
[ 16.573430] init: plymouth-splash state changed from post-stop to waiting
[ 16.573537] init: Handling stopped event
[ 16.591136] init: plymouth main process (259) exited normally
[ 16.591194] init: plymouth goal changed from start to stop
[ 16.591264] init: plymouth state changed from running to stopping
[...]
[ 17.610321] init: lightdm main process (1136) terminated with status 1
[ 17.610429] init: lightdm goal changed from start to stop
[ 17.610490] init: lightdm state changed from running to stopping
[...]
[ 16.591619] init: plymouth state changed from stopping to killed
[ 16.591669] init: plymouth state changed from killed to post-stop
[ 16.591721] init: plymouth state changed from post-stop to waiting

affects: plymouth (Ubuntu Quantal) → lightdm (Ubuntu Quantal)
tags: added: needs-upstream-testing regression-potential
Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu Quantal):
status: New → Confirmed
Changed in lightdm (Ubuntu Raring):
status: New → Confirmed
Changed in lightdm (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu Raring):
status: New → Confirmed
tags: added: bios-outdated-b10

Parameswaran Sivatharman, as per http://support.apple.com/kb/HT1237 an update is available for your BIOS (MM51.0077.B10). If you update to this following https://help.ubuntu.com/community/BiosUpdate , does it change anything? If it doesn't, could you please both specify what happened, and just provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Thank you for your understanding.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete

This bug was nominated against a series that is no longer supported, ie saucy. The bug task representing the saucy nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu Saucy):
status: Confirmed → Won't Fix
Joseph Salisbury (jsalisbury) wrote :

This bug was nominated against a series that is no longer supported, ie quantal. The bug task representing the quantal nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu Quantal):
status: Confirmed → Won't Fix
Joseph Salisbury (jsalisbury) wrote :

This bug was nominated against a series that is no longer supported, ie raring. The bug task representing the raring nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu Raring):
status: Confirmed → Won't Fix
Rolf Leggewie (r0lf) wrote :

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

Changed in lightdm (Ubuntu Quantal):
status: Confirmed → Won't Fix
Rolf Leggewie (r0lf) wrote :

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 lightdm (Ubuntu Raring):
status: Confirmed → Won't Fix
Rolf Leggewie (r0lf) wrote :

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 lightdm (Ubuntu Saucy):
status: Confirmed → Won't Fix
Robert Ancell (robert-ancell) wrote :

Closing assumed fixed.

Changed in lightdm (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers