X startup fails with "failed to get resources" error after update to 3.5.0-18

Bug #1088271 reported by Courtney Rosenthal
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fedora
Won't Fix
Undecided
linux (Ubuntu)
Fix Released
High
Unassigned

Bug Description

The system was working correctly at 3.5.0-17. After upgrade to 3.5.0-18 the system lost screen display on boot. Booting with "nomodeset" had no effect.

I could log in remotely and see lightdm was NOT running, and from Xorg.0.log that X failed to start.

  [ 480.158] (==) intel(0): video overlay key set to 0x101fe
  [ 480.158] (EE) intel(0): failed to get resources: Invalid argument
  [ 480.158] (II) UnloadModule: "intel"
  [ 480.158] (EE) Screen(s) found, but none have a usable configuration.
  [ 480.158]
  Fatal server error:
  [ 480.158] no screens found
  [ 480.158] (EE)

The system is a ZBOXSD-ID13-U: Intel Atom D525 CPU with Intel GMA 3150 video (i915 driver)

I'll attach two logfiles: xorg-3.5.0-19.log (shows the failure) and xorg-3.5.0-17.log (shows successful startup)

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: xorg 1:7.7+1ubuntu4
ProcVersionSignature: Ubuntu 3.5.0-19.30-generic 3.5.7
Uname: Linux 3.5.0-19-generic x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Sun Dec 9 16:23:27 2012
InstallationDate: Installed on 2012-07-10 (152 days ago)
InstallationMedia: Xubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MarkForUpload: True
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to quantal on 2012-10-22 (48 days ago)

Revision history for this message
Courtney Rosenthal (courtneyr) wrote :
Revision history for this message
Courtney Rosenthal (courtneyr) wrote :

Adding another log, generated when booting same system with 3.5.0-17

bugbot (bugbot)
tags: added: xubuntu
Revision history for this message
In , Milan (milan-redhat-bugs) wrote :

Created attachment 667712
/var/log obtained in failsafe graphics mode with F18 beta LiveCD

LiveCD for both F18 beta and nightly build from 2012-12-17 fail to build on my machine with an Ironlake Mobile GPU (see below). If I choose the normal boot mode, Plymouth is not visible: the screen goes grey, then blanks and never returns. If I choose failsafe graphics mode (xdriver=vesa nomodeset), I am able to see the boot process, but X fails to start: on F18 beta, I am able to go to a console; with the nightly build, the machine hangs when X starts, and the fan does not stop (probably CPU use).

I am attaching the logs I could get with F18 beta in failsafe graphics mode.

Please ask for any information/debugging you may need.

The card model is:
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])

The most interesting part of Xorg.0.log is:
[ 13.212] (II) VESA: driver for VESA chipsets: vesa
[ 13.212] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 13.212] (II) FBDEV: driver for framebuffer: fbdev
[ 13.212] (++) using VT number 1

[ 13.214] (II) intel(0): using device path '/dev/dri/card0'
[ 13.218] (WW) Falling back to old probe method for vesa
[ 13.218] (WW) Falling back to old probe method for modesetting
[ 13.218] (WW) Falling back to old probe method for fbdev
[ 13.218] (II) Loading sub module "fbdevhw"
[ 13.218] (II) LoadModule: "fbdevhw"
[ 13.218] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
[ 13.229] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 13.229] compiled for 1.13.0, module version = 0.0.2
[ 13.229] ABI class: X.Org Video Driver, version 13.0
[ 13.229] (EE) open /dev/fb0: No such file or directory
[ 13.235] (II) intel(0): Creating default Display subsection in Screen section
 "Default Screen Section" for depth/fbbpp 24/32
[ 13.235] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[ 13.235] (==) intel(0): RGB weight 888
[ 13.235] (==) intel(0): Default visual is TrueColor
[ 13.236] (--) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale
[ 13.236] (**) intel(0): Relaxed fencing enabled
[ 13.236] (**) intel(0): Wait on SwapBuffers? enabled
[ 13.236] (**) intel(0): Triple buffering? enabled
[ 13.236] (**) intel(0): Framebuffer tiled
[ 13.236] (**) intel(0): Pixmaps tiled
[ 13.236] (**) intel(0): 3D buffers tiled
[ 13.236] (**) intel(0): SwapBuffers wait enabled
[ 13.236] (==) intel(0): video overlay key set to 0x101fe
[ 13.236] (EE) intel(0): failed to get resources: Invalid argument
[ 13.236] (II) UnloadModule: "intel"
[ 13.236] (EE) Screen(s) found, but none have a usable configuration.
[ 13.236]
Fatal server error:
[ 13.236] no screens found

Revision history for this message
In , Milan (milan-redhat-bugs) wrote :

FWIW, a report against Ubuntu 12.04 has the very same X log, and says it was working with Linux kernel 3.5.0-17, but fails with 3.5.0-18. Of course F18 has much more recent kernels.

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1088271

Revision history for this message
In , Milan (milan-redhat-bugs) wrote :

OK, acpi_backlight=vendor fixes the problem in normal boot mode. This is bug 771110 striking again.

Still, I think there's a separate problem with failsafe graphics mode.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

there are later updates to the kernel, do they have the same bug?

affects: xorg (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
assignee: nobody → Timo Aaltonen (tjaalton)
status: New → Incomplete
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

also, does adding 'acpi_backlight=vendor' as a boot argument help?

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

3.5.0-18 added this:
47f80be7fc108d4 drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13

which matches your hw.

Changed in linux (Ubuntu):
assignee: Timo Aaltonen (tjaalton) → nobody
importance: Undecided → High
status: Incomplete → Triaged
tags: added: regression-release
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

the commit has actually been reverted upstream already, but didn't get pushed to stable (yet):

commit 48e858340dae43189a4e55647f6eac736766f828
Author: Daniel Vetter <email address hidden>
Date: Mon Jan 7 10:27:13 2013 +0100

    Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13"

    This reverts commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364.

    The bogus lvds output is actually a lvds->hdmi bridge, which we don't
    really support. But unconditionally disabling it breaks some existing
    setups.

    Reported-by: John Tapsell <email address hidden>
    References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/17237
    Signed-off-by: Daniel Vetter <email address hidden>

Revision history for this message
Courtney Rosenthal (courtneyr) wrote :

The behavior is present in 3.5.0-21.

Booting with acpi_backlight=vendor has no effect.

Is there something else I should try, or just wait for the next kernel update to be pushed?

Revision history for this message
Luis Henriques (henrix) wrote :

I've uploaded a Quantal test kernel that includes the commit referred by Timo in comment #6. Here's the URL:

http://people.canonical.com/~henrix/lp1088271/

Chip: could you please test this kernel and let me know if it solved your problem? Thanks.

Revision history for this message
Courtney Rosenthal (courtneyr) wrote :

SUCCESS! System boots normally with the test kernel packages.

Revision history for this message
Luis Henriques (henrix) wrote :

Great, thanks for testing. I've requested upstream to include the fix in next stable releases so it should hit Quantal in the next SRU cycle.

Revision history for this message
Courtney Rosenthal (courtneyr) wrote :

Any idea if this is going to be available for 12.10?

As of 3.5.0-23, the video is still failing.

Revision history for this message
Luis Henriques (henrix) wrote :

The fix for this bug is now in the Quantal kernel in -proposed pocket. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

Revision history for this message
Harald Rudell (harald-rudell) wrote :

I have this problem, too, on 915GM/GMA900, and it is still a problem.
It has not worked since the beginning of kms which was mid-2011.

Symptom: X does not start, in /var/log/Xorg.0.log: (EE) intel(0): failed to get resources: Invalid argument

I have the latest quantal-proposed kernel, dated 130207:
linux-image-extra-3.5.0-24-generic

X video driver: "intel" module version = 2.20.9

kernel kms active

hardware: lspci -k -nn -s 0:2
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04)
 Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
 Kernel modules: intelfb, i915
00:02.1 Display controller [0380]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792] (rev 04)
 Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]

I have been using the "fbdev" driver ever since.

Revision history for this message
Harald Rudell (harald-rudell) wrote :

I got it working with my card and 3.5.0-24.

After re-enabling kms, I had forgot to run 'sudo update-initramfs -u'
the boot somehow was in kms color mode either way, but the X driver would not work.

Apparently 'intel(0): failed to get resources: Invalid argument' means to say: kernel-space modesetting not present.

Revision history for this message
Julian Wiedmann (jwiedmann) wrote :

Chip,
the referenced patch landed in quantal-updates with 3.5.0-24.36. Please test and close this bug if it's fixed.

Revision history for this message
Courtney Rosenthal (courtneyr) wrote :

I confirmed the fix on 3.5.0-25.38.

Thank you.

Changed in linux (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Changed in fedora:
importance: Unknown → Undecided
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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